[wp-trac] [WordPress Trac] #58202: php-fpm7.4: time limit exceeded `Operation canceled' @ fatal/cache.c/GetImagePixelCache/1868.
WordPress Trac
noreply at wordpress.org
Tue Jun 27 08:25:10 UTC 2023
#58202: php-fpm7.4: time limit exceeded `Operation canceled' @
fatal/cache.c/GetImagePixelCache/1868.
--------------------------+-----------------------
Reporter: dsar | Owner: antpb
Type: defect (bug) | Status: assigned
Priority: normal | Milestone: 6.2.3
Component: Media | Version: 6.2
Severity: normal | Resolution:
Keywords: | Focuses:
--------------------------+-----------------------
Comment (by matt_fw):
We were affected by this issue. We solved it by creating a separate PHP-
FPM pool for `async-upload.php`, directing traffic to it, and setting its
`pm.max_requests = 1` and `pm.max_servers = 4`. The important part is
`pm.max_requests = 1` to reset ImageMagick's cache timer on each request.
However, after reading through the ImageMagick resource handling code (
https://github.com/ImageMagick/ImageMagick/blob/a531d28e31309676ce8168c3b6dbbb5374b78790/MagickCore/resource.c#L1496
) I think it's enough to call `Imagick::setResourceLimit(
Imagick::RESOURCETYPE_TIME, $limit );` on each request, even if the
already set value is the same. In WP 6.2.2 the call is executed only when
`max_execution_time < imagick_timeout`, but that happens only on the first
call to `Imagick::set_imagick_time_limit()` within each PHP-FPM process.
Calling `Imagick::setResourceLimit( Imagick::RESOURCETYPE_TIME, $limit );`
resets ImageMagick `cache_epoch = 0` (see
https://github.com/ImageMagick/ImageMagick/blob/a531d28e31309676ce8168c3b6dbbb5374b78790/MagickCore/cache.c#L4847)
and effectively makes ImageMagick's cache act as if it was request-based.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/58202#comment:15>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list