Last modified: 2013-10-25 09:53:34 UTC
https://www.mediawiki.org/wiki/Manual:$wgMaxShellMemory On almost all my new MW installations I noticed the problem, that ImageMagick generation of thumbnail view for example in Special:ListFiles fatally fails for GIF images. This is known for insiders (see https://www.mediawiki.org/wiki/Manual:$wgMaxShellMemory If generating thumbnails with ImageMagick fails with a web server error log message like "Memory allocation failed" or "/bin/ulimit4.sh: Segmentation fault /usr/bin/convert ...", the $wgMaxShellMemory value may need to be increased. ) I suggest to increase the standard value to for example to 512000
It takes more than 100mb of memory to scale a gif image?! (unless i have my math wrong)
(In reply to comment #1) > It takes more than 100mb of memory to scale a gif image?! (unless i have my > math wrong) /** * Maximum amount of virtual memory available to shell processes under linux, in KB. */ $wgMaxShellMemory = 102400; Nope, you're right, 100MB apparently
(In reply to comment #1) > It takes more than 100mb of memory to scale a gif image?! (unless i have my > math wrong) I have see on many contemporay installations (SLES-11), that 102400 KB was not sufficient for many GIFs. Conversion of JPG and PNG images did not fail. Another problem (of too low shell memory) is, that you barely see any substantial error message. The Thumb nails are simply not generated. I suggest to increase the value. Perhaps someone else has made similar experiences, then it's a good moment to discuss it now here. I won't be pushing to a higher value, I am just proposing this.
Oh right, gif images are going to be bigger because they're animated so multiply everything by number of frames... Still, the $wgMaxAnimatedGifArea = 1.25e7; default should stop it from going over the limit (According to comment, that's about 50 mb in totally uncompressed form with 24bit colour, so I would imagine a gif image using only 255 colours should fit comfortably in that, [but i say that without knowing how imagemagick really works or what image magick actually does when scaling an image]) >Another problem (of too low shell memory) is, that you barely see any >substantial error message. The Thumb nails are simply not generated. Unless one has fancy thumbnailing configuration set up (like Wikimedia does) you should see the very cryptic and fairly useless error message about Memory allocation failed or delegate failed, etc. Are you saying you don't get those error messages? (Yes, ideally we would detect this error condition better and present something more human readable. However, this is probably a very difficult error to programmaticly catch from the mediawiki side) >I suggest to increase the value. Perhaps someone else has made similar >experiences, then it's a good moment to discuss it now here. I won't be pushing >to a higher value, I am just proposing this. My earlier comment (comment 1) was not meant to imply that we should keep it the same (or change it for that matter), only that 100mb seemed quite a large number already, and we shouldn't change it without first understanding why the limit is being reached.
I compiled the current version of imagemagick (6.8.6-10) on ubuntu with default values and it subsequently failed to resize a 250KB png due to insufficient memory (with stock settings). Setting $wgMaxShellMemory to 517000 (random value; don't know how high was actually needed) resolved this. So this very much is an issue, and that issue is two-fold: for one, the default MaxShellMemory may no longer be sufficient for normal use, especially since imagemagick, the usual image handler, appears as though it now requires more memory than it used to, and two, that as folks have said, in a base install these errors have no handling to point to the setting that would allow it that memory.
(In reply to comment #4) > [but i say that without knowing how imagemagick really works or what > image magick actually does when scaling an image]) Depending on the weather when it was being built, ImageMagick can internally use 64-bit precision for pixel values (16 bit for each channel). This increases the estimate a bit. I think this is enough justification to, say, triple the value to have some margin left, and I'm going to submit a patch to do that. Real world testing of $wgMaxShellMemory = 307200 would be appreciated.
Change 91501 had a related patch set uploaded by Bartosz Dziewoński: Triple default $wgMaxShellMemory (raise to 300 MB) https://gerrit.wikimedia.org/r/91501
(In reply to comment #6) > (In reply to comment #4) > > [but i say that without knowing how imagemagick really works or what > > image magick actually does when scaling an image]) > > Depending on the weather when it was being built, ImageMagick can internally > use 64-bit precision for pixel values (16 bit for each channel). This > increases > the estimate a bit. > > I think this is enough justification to, say, triple the value to have some > margin left, and I'm going to submit a patch to do that. Real world testing > of > $wgMaxShellMemory = 307200 would be appreciated. I imagine this makes sense. Presumably web servers have more memory now compared to back in the day when this setting was introduced.
Change 91501 merged by jenkins-bot: Triple default $wgMaxShellMemory (raise to 300 MB) https://gerrit.wikimedia.org/r/91501
Change 91833 had a related patch set uploaded by Bartosz Dziewoński: Triple default $wgMaxShellMemory (raise to 300 MB) https://gerrit.wikimedia.org/r/91833
Change 91833 merged by jenkins-bot: Triple default $wgMaxShellMemory (raise to 300 MB) https://gerrit.wikimedia.org/r/91833
Merged by Aaron, backported to 1.22, updated docs at mw.org. I'm going to close this and hope 300 MB will be enough for a few more years ;)
