RAM usage spikes

I have a site indzara.com that continues to have issues with CPU and RAM usage spikes. 503 errors happened as a result and the site has tanked in Google search traffic lately.
I have spent a lot of money with 3 different developers to attempt to fix the issue. Still no success. Installing WPMUDEV is also a part of my journey to improve my site performance and reliability.

I have SiteGround as hosting provider and am on a Cloud plan with 2 CPU cores and 4GB RAM. I am noticing that the RAM usage spikes to close to 3GB around 10:45 am PST every day. It sometimes exceeds 4GB as well.

1. How can I find out what drives this specific daily usage every day?
2. For a site like mine with 150 blog posts, 20 product pages and 25 other pages, what should be the normal CPU and RAM usage? I get around 20K visitor sessions a month now.
3. When I look in File Manager, I see 1.2 GB of files (images, excel spreadsheets) in Uploads folder. Is that too much?
The database size is about 300MB. These are after several rounds of cleanup.

Any thoughts would be appreciated. I am not a developer. If I failed to provide any necessary info, please let me know.
Thanks for your time.
Also posted it here: https://premium.wpmudev.org/forums/topic/ram-usage-spikes-leading-to-errors

  • Dimitris

    Hello there Dinesh,

    hope you're doing good today! :slight_smile:

    Please install and activate the following plugin: https://wordpress.org/plugins/wp-crontrol/
    so we can check Cron job schedules.

    Then grant temporary support access to your website via WPMUDEV Dashboard plugin, no need to share any WP admin credentials. Just navigate in WP admin area under WPMU DEV -> Support page and click on the "grant support access" button. You can find detailed information about it here: https://premium.wpmudev.org/docs/getting-started/getting-support/#chapter-5
    Please do reply back here when access is granted because we don't get any notifications about it.

    I'd also like to inform you that this may be coming from a badly coded plugin and/or theme, so it may be difficult for us to locate it, especially if hosting provider couldn't provide much info about the source of the high memory and CPU load. Maybe a staging environment and some further tests, like using alternative theme or plugins, could show to you what could cause that.

    Warm regards,
    Dimitris

  • Dinesh

    Thank you so much for your help. I have given support access. Please confirm.

    The plugin WP Crontrol has been there.

    1. I was assuming the wpo_plugin_cron_tasks is from WP Optimize Plugin and it is strange since that plugin, though installed, is inactive. So, I wasn't expecting it to run.
    I changed the frequency of this cron job to weekly instead of twice a day. I will see what happens today around 10:30 am PST.

    2. Later around 12 noon PST on Dec 29th, the spike happened again on RAM usage and it lead to 502 and 504 errors when I was on the site. When I asked Siteground below is the response.

    From host siteground:

    I have checked the logs and there was indeed another restart of the Apache. This time though I can see a definite reason for this - a very high amount of Input/Output Operations (IOps) usage on the server :

    Code:
    2018-12-29 14:03:55.707464-06 c47600 12.26 5549 767 461
    2018-12-29 14:02:56.023332-06 c47600 11.56 5381 827 448

    The limit for IOps per second on the server is 5000, so on both occasions you have exceeded those, which lead to the Apache thinking it has stalled, forcing it to restart. The IOps are essentially how many read and write actions are being done on the hard disk of your server at the same time. If you have large databases, slow applications or applications that are constantly running doing something (for example importing or exporting products, counting visitors, constantly rerunning any scripts for whatever reason) you would get such a high number.

  • Dimitris

    Hello there Dinesh,

    hope you're doing good today! :slight_smile:

    I wasn't able to locate anything that could cause that unfortunately, so you will have to make some further conflict tests in a staging environment as stated above.
    The idea of a conflict test is shown in a nice flowchart image here, even though this will require some more patience as you'll have to wait to see how the server responds. Unfortunately, this isn't something that can be held by our support staff, as it would require some extended amount of time.

    As for the hosting itself, is there any server-side caching? Cause this should dramatically increase the page speed. As stated in the Performance Report of HummingBird plugin under the "Improve server response time", you should check that:
    - OPcache is enabled in your site's PHP configuration.
    - Install and configure an object caching plugin on your site (Redis or Memcached recommended).

    About your setup in general, I noticed that you use a custom child theme for Storefront, but the parent theme hasn't been updated for quite some time. I'd strongly advised to update parent theme and make any adjustments needed in your child theme, as soon as you've got your staging site.

    Warm regards,
    Dimitris

  • Dinesh

    I am lost now, Dimitris.
    I have gone back and forth between developer and SiteGround for months now.
    Why is it so hard to find what causes the IO operations to spike. Even yesterday, WPMUDEV sent me an email that the site was down for 5 mins. It's happening approx the same time of day every day.
    any help would be appreciated. i am very close to shutting my business down, due to these site issues.

    thanks....

  • Dimitris

    Hello there Dinesh,

    hope you're doing well! :slight_smile:

    As long as the hosting provider can't find anything in their logs that could point to a specific procedure and/or source like a specific plugin, then it's extremely difficult for us to do so, as we even don't have access in the server-level they way they do. As long as the sysadmins can't assist though, then only some more tests in a staging environment could further assist to narrow this down.
    Our Uptime Monitor system just sends a header request and measures the time to load the first byte, can't troubleshoot or find the source of any downtime, it can only see a status HTTP code like "503".

    Warm regards,
    Dimitris

Thank NAME, for their help.

Let NAME know exactly why they deserved these points.

Gift a custom amount of points.