A server that is set up well on day one does not stay healthy on its own. Logs pile up. Caches grow. Temporary files outlive their purpose. Settings that made sense at launch, such as which tool actually runs PHP, or how much memory each worker gets, stop matching reality as traffic grows. None of this is dramatic enough to set off an alarm by itself. It is the kind of slow decay you cannot see until it suddenly becomes a problem, usually at the worst possible time. Here is the routine we follow to stay ahead of it.

dd if=/dev/zero of=/tmp/test1.img bs=1G count=1 oflag=dsync
dd if=/tmp/test1.img of=/dev/null bs=1G count=1 iflag=dsync
rm /tmp/test1.img

A simple free space check tells you how much room is left. It does not tell you whether the disk is still fast enough for your work, which is a different and easy to miss kind of problem, especially on shared or remote storage that can quietly slow down. We run an actual read and write test like this on a schedule, not only when something already feels slow.

It is common for an application to build up years of cached files, session data, and temporary files in folders nobody is clearly responsible for cleaning. A cleanup job needs an actual cutoff date, not a vague idea of deleting old stuff.

find /var/www/app/tmp/cache -type f -not -newermt "2019-01-01"
find /var/www/app/tmp/cache -type f -not -newermt "2019-01-01" -delete

We always run the first command, the dry run, before the second one that actually deletes anything. We also choose the cutoff date on purpose. For financial data, that is often the end of the last closed accounting period, not an arbitrary number of days. We check actual folder and table sizes first too, since the biggest space users are rarely the ones you would guess from memory.

A server set up early to run PHP directly inside the web server is a fair choice for low traffic, but it ties PHP to the web server's own way of handling many requests at once, which does not grow on its own. If traffic has grown since launch, it is worth checking whether a separate worker pool for PHP, one that can be sized, watched, and restarted on its own, fits the current load better than whatever was chosen on day one.

Settings for how much memory the code cache gets, and how many workers handle requests at once, are usually set once, based on a guess about size and traffic at the time. Both guesses age badly. A codebase that has grown by forty percent since launch may be pushing cached code out of memory under the old limit. Traffic that has doubled may be queueing behind a worker count that has not changed since day one. We recheck these settings against actual numbers on a regular basis, not only when the server was first set up.

The actual risk this guards against is not any single forgotten task. It is depending on someone simply remembering to do all of this on their own, with nothing forcing it. A short, dated checklist, disk speed check, cache cleanup with a clear cutoff, a review of PHP and worker settings, and a test that backups actually restore, run on a fixed schedule, turns "we should probably check the server sometime" into something we actually do and can prove we did.

Maybeach Tech runs and maintains production servers so this routine happens on schedule, not only after something breaks. Get in touch and tell us about your current maintenance habits.