Viewing 10 replies - 1 through 10 (of 10 total)
  • Plugin Author nosilver4u

    (@nosilver4u)

    EWWW IO can’t use up that much all by itself, unless you have hundreds of thousands of records in the ewwwio_images table, and even then that would be a stretch. Turn off scheduled optimization and see what happens. 1.5G is way too much for a wordpress site to be using unless you’re getting hammered with traffic.

    Thread Starter funsail

    (@funsail)

    I turned off scheduled optimization and after 10hrs or so usage drops to 50mb.
    I have about 6000 images in one dir (no 2013/04 etc)
    Not much traffic to speak of (30-50/day)

    Turned scheduled optimization on again, made a visit, mem jumps to 600MB and slowly climbs.

    Off again, takes hours then eventually drops.

    Started exactly with the WP4.0

    Plugin Author nosilver4u

    (@nosilver4u)

    I can understand it climbing with the scheduled optimization, but that kind of usage seems very unusual. I’ll look into it and see what I can find out.

    Plugin Author nosilver4u

    (@nosilver4u)

    I have 26,000 records in my ewwwwio_images table, and I told it to scan a folder with 20,000 images (some of which have been optimized, but many are not). My memory usage has climbed to 230M from 170 prior to optimization, and is stable during the auto-optimize. It sounds like there is something else in play here, but I’m at a loss as to what it could be. I think we need to see what happens when you have every plugin except EWWW disabled and turn on scheduled optimization to make sure some other plugin isn’t hooking into the wp_cron function improperly.

    Plugin Author nosilver4u

    (@nosilver4u)

    Update: the scan just finished, and it only optimized 1 image out of the 20,0000. So it took around 20-25 minutes to scan through 20,000 files, and never went above 240MB of memory. I’m using php-fpm, so I wonder what would happen if one were using apache with something like php-cgi. It shouldn’t be much worse, but there could be a difference. Do you know what type of php module you are using?

    I do still need you to run the above test if we want to track this down, but I’ll check and see if running php within apache makes any difference.

    Thread Starter funsail

    (@funsail)

    How do I find the type of php module ?
    I should be LiteSpeed & CloudLinux

    Plugin Author nosilver4u

    (@nosilver4u)

    I just installed Litespeed on my dev server last week, and as far as I can tell, there is only one way to run php with Litespeed, so I should be able to do some testing and see what happens with WP 4.0, and a whole pile of images going through the scan & optimize.

    Plugin Author nosilver4u

    (@nosilver4u)

    Well, still didn’t see it climb over 125M with a scan & optimize, so I’ll see if it is any different for a scheduled optimize. It does the same thing, but does not use ajax, so everything has to run in one shot, instead of one request per image, so that could have some effect on the memory usage during a long scheduled optimization.

    Plugin Author nosilver4u

    (@nosilver4u)

    Do you have a custom php.ini file you could send me via https://www.shanebishop.net/contact-me/

    If not, perhaps you can ask your webhost for a copy of your local php.ini as I’m having trouble getting the schedule optimization to keep running. It seems to stall out after a minute or two, and I don’t know enough about litespeed to figure it out apparently.

    Plugin Author nosilver4u

    (@nosilver4u)

    Ok, I finally got it to run through all 80,000 images on litespeed, and memory usage never climbed above 230M. There was something I had tweaked in either 2.0.2 or 2.1.0, and I thought that might have made a difference, but it was not noticeable at all.

    Just to make sure we’re comparing the same thing here, are we talking about memory usage for the php process running the scheduled optimization, or total server memory usage?

Viewing 10 replies - 1 through 10 (of 10 total)
  • The topic ‘Memory usage Since WP4’ is closed to new replies.