Excessive I/O

Website URL


Error Message

site suspended: i/o limits

Other Information

I can see from the i/o graph there was a very high spike in i/o. This was very unusual (unprecedented) for the site, so suspension seems a little harsh, although I imagine it is probably automated. I have W3 caching installed.

I need to understand what caused this spike so I can avoid a recurrence. The only activity I can think may have caused the problem was carrying out Wordpress resize thumbnails. Would this action hammer i/o?

Likely due to this


erm… Are you suggesting that a caching plugin can generate excessive I/O after it has been installed for months? I am expecting the opposite affect…

Anything is possible…
If you accidentally set it to cache every minute.
I/O metric will shoot up

I’m not convinced I’m afraid. This is a one-off massive spike, with minimal traffic and only minor site changes. The only issue was I was trying to sort out the mobile display of images leaving a narrow strip of text up the side, I resized the medium to fill the full width on my mobile and then carried out a full resize (approx 200 images).

I am facing the same issue. I don’t have any plugin installed and don’t have any PHP code running. All I am running is a static HTML + CSS site and it gave me the same type of spike for I/O. Any suggestion or insight on what might actually happened there?

a bad plugin update can also sometimes cause this issue

1 Like

I’m sorry, but wild conjecture is of no help at all. As I stated in my original post, there had been no significant changes that could account for this extreme spike in I/O (and now I have access back, I also see a spike in RAM).

I did carry out a global thumbnail resize on that day (circa 200 images), and I need to know if this would account for the spike. If yes, then fine I know what to expect, but if not then some unknown event occurred which needs further investigation. I do not exclude some sort of server activity outwith my control, and if so then I consider account suspension extremely unfair.

That may be partially to blame for the IO limit getting hit (Assuming the images were updated via WordPress).

As for the RAM limit, there has been a recent spike in those, and it is believed to be caused by something weird going on in the data center. It’s nothing to be worried about at the moment.

1 Like

OK, so in the absence of any other likely cause, I am going to put it down to Wordpress regenerate thumbnails. The size of the I/O spike was at least double the allowed MB/s, so if this was the cause it shows that I need to be very cautious if I ever need to resize thumbnails again. Time will tell if this was the true cause. I am not thrilled that a one-off event resulted in a 24 hour suspension, a warning for a first offence might be considered more appropriate by some.

This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.