Does anyone know what this error means? How can it overflow memory when i didnt overflow it?
Error:
Whoops\Exception\ErrorException thrown with message “Allowed memory size of 134217728 bytes exhausted (tried to allocate 9830401 bytes)”
Stacktrace:
#0 Whoops\Exception\ErrorException in /web/htdocs1/design_reklamacz/home/www/maregs/vendor/gregwar/image/Gre gwar/Image/Adapter/GD.php:85
According to the stack trace, the error is with your GD library. The “tried to allocate” statement simply means that was how much it was trying to allocate when it failed. It doesn’t mean that’s the total amount of memory consumed at the time of the crash. You definitely exceeded the limit. You’ll want to dig more into that library. Maybe you just tried to process an exceptionally large image.
Ok thank you… But i don’t have image larger than 3 mb so it is very weird error
I’d start at the library’s GitHub page and see if there are any issues about this.
Well maybe it’s not probelm with the GD library afterall. Because when I delete all the images, the memory usage is whopping 90 mb even for bare page. So there is something else eating memory. Any idea how can I find out what it is?
Maybe I should add that this happens only after clearing cache … otherwise it is using 2mb
Memory usage for image resizing is a lot more than the image size itself. try this caulculator
Pages with lots of media can peak at high memory even if the images are not bit (just tried a page we test and got 68MB on the debug bar) at the first load, then get as low as 4MB on the next refreshes, once assets are cached, that’s normal. It’s not normal if you don’t have any image on the other hand. Maybe some plugin doing something?
Well you guys are right after all… I made mistake cause I haven’t deleted every image. The problem was one image that had only 3mb on disk (but resolution was close to 6000x4000, so I found out that HugoAvila was right) . I tried deleting images one by one and then found out this. Now everything works as it should. Thanks.
This is likely not just a single large image, but the process Gregwar applies (really GD applies) when manipulating (resizing etc) many of them: It does not handle memory well, in that it does not clear the memory cache consequently, and so a significant amount of memory will be used whereas not all of it would actually be needed.
There are issues on the GitHub repo where solutions to solving this exists, but none are as of yet implemented. Ideally a move away from GD would solve this, as alternative approaches using Imagick or GMagick avoids the problem more gracefully. It remains the case, though, that with any large portion of images you are currently better off resizing them yourself than letting the server do it.
Imagick and other solutions are definitely superior, unfortunately they are not widely supported by hosting providers. Even then, the current image manipulation library we use doesn’t support anything but GD. There is an issue open to look into this, but it’s a lot of work, and for it to be feasible in Grav 1.X it would need to be backwards compatible.