Brief scheduled maintenance on Saturday, August 11

Between 11:00 PM and 11:59 PM Pacific time on Saturday August 11, all Tiger Technologies Web hosting servers will be restarted. As a result, customer Web sites, as well as the Tiger Technologies Web site, will be unavailable for approximately five minutes. E-mail service will not be affected.

This brief maintenance is necessary for two reasons. First, we’re upgrading the operating system “Linux kernel” to a newer version for security reasons. Secondly, we’re adding more memory to our hosting servers, so that each server will have 4 GB of RAM instead of the current 2 GB.

Adding more memory will allow each server to handle a higher peak load. Although 2 GB of RAM is almost always far more than sufficient (our servers tend to use only about 700 MB of RAM under normal conditions), we’ve analyzed the cause of a problem that occurred on one Web server about a month ago, and determined that the issue probably would not have happened if the server had more RAM. A sudden extremely high load caused it to start “swapping” memory to disk a little. That slowed down the server, which increased the load even more, and so on in a horrible spiral of worsening performance.

(As an aside, we spend a lot of time trying to learn from past problems, even if they only happened once. We think the fact that we’ve been in the hosting business for nearly 8 years is a valuable asset to our customers. While I’d never say we’ve “seen it all”, we’ve certainly seen plenty of odd things that “shouldn’t ever happen”, then taken steps to make sure that our customers aren’t affected if they happen again.)

Anyway, doubling the memory on each server will increase the normal free RAM from 1.3 GB to 3.3 GB, which allows us to make sure the servers never try to swap memory to disk.

The extra RAM will also speed up our servers a little even under normal load, because the Linux operating system automatically uses free memory to cache frequently accessed files like MySQL databases. That difference will be fairly small, though.

We apologize for the inconvenience this short maintenance causes, especially since it comes on the heels of our MySQL database maintenance last week. (Combining these two scheduled maintenance tasks wouldn’t have reduced the total downtime, since they’re unrelated. In fact, combining two unrelated maintenance tasks increases the chance that a mistake will be made or something will go wrong, so we intentionally avoid doing that.)

An update from after the work was finished: Two servers — “lrrr” and “farnsworth” — were only updated to 3 GB instead of 4 GB due an unforeseen compatibility issue. This is still more than sufficient to solve the problem we were concerned about, but for consistency we’ll update those two servers to 4 GB in the future when they need restarting for another reason, such as a future kernel upgrade.