PHP Session Cleaner

In response to Debians security efforts to stop session stealing on shared-hosting servers, and after a few requests from concerned sysadmins, I've developed an application to clean the PHP session directory as an alternative to the cron job route.

From the README.Debian file and following up bug reports #321460 and #267720:

Session files are stored in /var/lib/php5. For security purposes, this directory is unreadable by non-root users. This means that php5 running from apache, for example, will not be able to clean up stale session files. Instead, we have a cron job run every 30 mins that cleans up stale session files; /etc/cron.d/php5. You may need to modify how often this runs, if you've modified session.gc_maxlifetime in your php.ini; otherwise, it may be too lax or overly aggressive in cleaning out stale session files.

The application is called `Sescle`, e.g. the php session cleaner, it monitors the PHP session directory using the Linux inotify interface and removes files if they haven't been modified for longer than the session.gc_maxlifetime duration.

The latest beta release is 0.1 and is available for download at: http://www.midnight-labs.org/sescle/php-sescle-0.1.tar.gz

More information can be found at the Sescle homepage, or by subscribing to the Sescle freshmeat project.

Skip to Page:  1 … 7 8

Golden Rules for MySQL Performance Tuning

I don't know how many times I've lectured people on the do's and dont's or given advice on forums, but the most common thing I see people doing is "over-tuning" first without considering the real impact it will have on the system.

Lets take the worst case scenario:

My MySQL instance is running slow; I keep adding memory to it, but it just gets slower!

In this case the inexperienced server owner kept adding more and more to the per-thread buffers thinking that alone will decrease the amount of time queries take to run... how wrong could he have been!

What was actually happening, with 512mb of per-thread buffers, is that a new client would connect and half of his apache processes would be swapped out, the query would finish and the apache processes would swap back in to handle another client.

Among other things he had an opened table limit of 1000, a query cache of 256mb, a key buffer of 256mb, a thread cache of 400 and a maximum number of clients at 1000.

So the golden rules to start off with are:

  1. Set a maximum memory guideline for MySQL
  2. Estimate the average number of concurrent clients you will have connected.
  3. Know how much memory your table keys take up.
  4. Conservatively give the query cache memory.

Once you know what all of these are you can then go on and set appropriate values, and as always leave a day between big modifications and actively monitor the performance of your MySQL instance in the meantime.

Performance tuning is never a one-off thing, it's a constant cycle of analysing requirements, constraints and real usage then adjusting accordingly.

More information can be found in the "Solving Memory Bottlenecks" section of the High Performance MySQL book.

A useful script `myvars` by Chris Croome of MKDoc.org mentioned on the Server Tuning document.

Maximum Memory

On a dedicated server handling MySQL, the web server and various other things you really need to split the memory allocated to each evenly. I'm going to be using 25% (1gb) because thats generally what has worked for me in the past, but with any initial estimate you should always monitor the machine for a week in advance to see how much memory you really have to play with.

For a server with MySQL only - it's fairly easy to go with 90% of the available memory because there's little else competing for resources.

Average Concurrent Connections

There are many different ways to obtain this magic number, but a couple of suggestion are:

  • Frequently login and check with MyTop or via the command-line.
  • Graph it with MySQL Administrator or hook it into your network monitoring software (Nagios)
  • Use web tracking software like Google Analytics to make an informed guess.

Whichever number you come up with, it is an integral part of tuning your server for the average load throughout the day. Never take a conservative estimate, and always consider daily load spikes into account.

Key Buffer Memory

When using MyISAM tables the storage engine provides an easy way to judge how much memory will be used for the key buffer by totaling up the space used by the .MYI files.

You can get the total by using a command like:

find /var/lib/mysql -name '*.MYI' | xargs du -hcs

Query Cache

The simplist thing to do is: start with 4mb and increase it as it gets used.

Skip to Page:  1 … 7 8

About

Harry is a professional developer and sysadmin from London, UK.

He's an atheist, employed at PixelMags LLC, a socialist and has a pragmatic outlook on life, love and religion.

Bookmarks

I'm constantly finding interesting stuff, here are some of the things I've bookmarked recently:

HarryR on Faves.com