Hich CPU usage

Those do not run every 5 minutes unless there are images waiting to be optimized. And it is impossible for all of those to run on any given site, because the latter three are for Grand FlaGallery, Nextcellent, and NextGEN. Nextcellent and NextGEN can’t usually be installed on the same site, so I suspect that part is a bit of a false positive.

However, the first one can potentially cause some CPU issues if it is getting blocked. You can check the queue page by turning on EWWW’s debugging option, and then look under the Media menu for a Queue Debugging page. See what that says, and we’ll go from there.

I just uploaded a 3,56 MB png image size. The plugin resized it to 872 KB, Photoshop resized to 683,7K when saved for we.
These are the logs.
On https://xxx/wp-admin/upload.php?page=ewww-image-optimizer-dynamic-debug:
nothing appeared about it, but about other images that was not resized it did.
#0 ewww_image_optimizer() called at /wp-content/plugins/ewww-image-optimizer/image-editor.php:170
#1 _save() called at /wp-includes/class-wp-image-editor-gd.php:376
#2 save() called at /wp-content/plugins/optimize-images-resizing/inc/class-resize-image.php:106
#3 image_downsize() called
#4 call_user_func_array() called at /wp-includes/class-wp-hook.php:298
#5 apply_filters() called at /wp-includes/plugin.php:203
#6 apply_filters() called at /wp-includes/media.php:201
#7 image_downsize() called at /wp-includes/media.php:824
#8 wp_get_attachment_image_src() called at /wp-admin/async-upload.php:61

On https://xxxxx/wp-admin/upload.php?page=ewww-image-optimizer-queue-debug:
Just after the big png image was uploaded.
119241 – wp_ewwwio_media_optimize_batch_7cfe19bf086d4cabcd52050536fd2753
1482 – image/png

Another thing that called my attention was that although my max_execution_time is set to 90, plugin debug.log https://xxxx/wp-content/plugins/ewww-image-optimizer/debug.log showed max_execution_time: 600

It seems that you are right about it being a false positive, but why you told me that the first one can cause CPU issues if it is getting blocked? And how/why could it get blocked?
So does this one reallys runs every five minutes? If yes, why?
wp_ewwwio_media_optimize_cron_interval 300 5 0.083333333333333 Every 5 Minutes

According to this text https://www.ecenica.com/support/answer/fix-high-cpu-load-wordpress/ it is a good idea Disable WP-Cron and set another way for that, what do you think about that? If you agree, do you have any plugin to suggest me?

I know it is a lot of questions, but I hope to help you with that as well, supplying the maximum information about everything.

Thank you!

• This reply was modified 7 years, 9 months ago by diegpl.
• This reply was modified 7 years, 9 months ago by diegpl.

Am I taking any security risk about showing up these functions and path names here? I already was attacked once and Im really worried about that. Thank you!

Another thing I realized is that “PNG Optimization Level” is allowing to set lossy option, but it does not seem to be working alright, since it resized the image from 3,56 MB to just 3 MB. Thank you.

It seems that even after the image is resized some crons are still schedule to run with not reason anymore. I check on Debug Bar Cron and it shows a closer next event after a picture is uploaded, for the next 5 or 10 minutes. Thank you.

• This reply was modified 7 years, 9 months ago by diegpl.
• This reply was modified 7 years, 9 months ago by diegpl.

Ok, if you’re only seeing the one image on the queue, then we don’t have to worry about that. Here’s how the “background/async” mode works:

1. When you upload an image, it sends an HTTP request to admin-ajax.php, and continues processing the image normally.
2. There is a function that is triggered in the background by that HTTP request which does the actual optimization, and the Background function also schedules a 5 minute health check via wp-cron.
3. If the image is optimized fully without timing out, then it removes the wp-cron health check, and that never gets run.
4. If the image takes too long, and a 3.5MB PNG image will certainly take some time, it can timeout before all the resizes are processed. If this happens, the image remains in the queue, and the health check will run 5 minutes later.
5. If #4 happened, the health check comes in 5 minutes later and restarts the optimization. It doesn’t use any more CPU than it did the first time around, and if it finishes the uploaded image and all resizes, then the health check is UNscheduled, and never run again until you upload more images.
6. If #5 times out too, the health check repeats every 5 minutes until all images in the queue have been processed.

With what you’ve said, the risk of this process causing any excessive CPU usage on your site minimal. The only way that usually happens is when you have a bulk import process running that sucks in a few hundred images AND the background process is getting blocked, the queue starts to build and build and build to where the database query to fetch the queue is what actually consumes the most CPU.

I haven’t seen it happen in several months, which is most likely due to the fact that background mode is disabled on new installs until a valid test of the Async/Background handling happens.

So, should you disable wp-cron? No, I don’t think so. The only reason I can think of to do that is if they have high-CPU stuff going all the time, and they want to limit it to a time when less folks are visiting the site. My concern with that is if wp-cron is doing stuff in the first place, you’re just going to make the backlog get worse when it finally does run on whatever schedule you come up with.
If there isn’t a backlog, and wp-cron is creating CPU issues, then that seems like a bug to me, which is what I’m concerned about here. If the queue clears, and you still see CPU usage, and then you disable EWWW and the CPU load goes away, then we need to figure out where it is coming from.

As for the lossy PNG question, a 3MB image should not be saved as a PNG, ever. Not even if it is an infographic. If it has any photographic content, or gradients, the JPG format will make it much smaller.

I’m not familiar with that Debug Bar Cron plugin, so I installed it to see what you are seeing. The jobs that are actually scheduled are under Custom Events and Core Events. The stuff under Schedules are not actually scheduled events, they are intervals that can be used to schedule events under wp-cron. So basically, ignore anything you see there, and focus on the Custom Events. If EWWW has nothing in the queue, wait 10 minutes, and check the debug bar cron to see if EWWWW has anything in the Custom Events section. It should not, and it does not on my site, where I have 40,000 images uploaded.

If you’re worried about too much information in public, feel free to send information via https://ewww.io/contact-us/
I actually prefer that, as it’s easier to keep track of things.