FirstServed Tech Blog - FirstServed and the Art of Server Tuning

A frequent problem we have is the clutter of MySQL databases created by shared webhosting customers. In order to maintain a well performing MySQL server we now and then have to optimize the MySQL tables. Doing this by hand, or waiting until the user does this is no option, therefore, we run this command, through a cron job:

First, we create a user named mysql_optimizer (with a strong password) and give it select and insert priveleges on the databases. You do not want your root user to be used in a cronjob!

mysql> GRANT SELECT, INSERT ON *.* TO ‘mysql_optimizer’@'localhost’ identified by ‘strong password’;
mysql> flush privileges;
mysql> exit;

Second thing is setting up the crontab, this time a weekly simple schedule:

> crontab -e
# MySQL weekly optimisation
0 0 * * 0 /usr/bin/mysqlcheck -Aos --optimize -u mysql_optimizer -pstrongpassword > /dev/null 2>&1

That’s it!

Here is a quick and dirty iptables based NAT solution for linux servers:

iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
iptables -A FORWARD -i eth0 -o eth1 -m state --state RELATED,ESTABLISHED -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 --source 192.168.0.1 -j ACCEPT
iptables -A FORWARD -i eth1 -o eth0 -j REJECT

Here we will provide internet access to the host 192.168.0.1 behind eth1 over our own internet connection on eth0.
The ip of eth0 can be dynamic. The host 192.168.0.1 will be using the ip of eth0 on the internet.

We only accept traffic from the ip 192.168.0.1, the rest is rejected.

Oh, and don’t forget to enable ipv4 forwarding in the kernel!
Add:

net.ipv4.ip_forward = 1

to /etc/sysctl.conf and run:

sysctl -p /etc/sysctl.conf

Or just run:

echo 1 > /proc/sys/net/ipv4/ip_forward

Your Milage May Vary…

When working in a clustered environment you might encounter situations where you need to sort merged access_logs from 2 different servers for one website. In this case the timestamps may not be ordered corretly due to time offsets in the individual servers or delays in the logging proces. The ordered data is needed since some statistics processing engines expect correctly sorted data.

The sorting can easily be done by the following command:

sort -t ' ' -k 4.9,4.12n -k 4.5,4.7M -k 4.2,4.3n -k 4.14,4.15n -k 4.17,4.18n -k 4.20,4.21n access_log.1 > access_log.1.sorted

Adjust, change and implement to match your own personal preference!

If the good old and trustworthy CentOs image you are using is suddenly being VERY slow when performing a "yum upgrade" command, try this rule to speed things back up a bit:

yum clean all

Most likely yum is using some old cached information.

We encountered this problem when upgrading from CentOS 5.0 to 5.3.

You want to use DRBD for mirroring your disks over the network, and put LVM on top of your DRBD disk for flexible disk management?  Try it like this:

1. Setting up DRDB
2. Setting up LVM

However, LVM is rather greedy when it comes to hogging block level devices at boot time.  So, after restarting, it will happily discover your scsi disk, md device, or whatever, and DRBD will spawn some nasty output like:

Starting DRBD resources: [ d0 d1 ioctl(,SET_DISK_CONFIG,) failed:
Invalid argument
Lower device is already mounted.

cmd /sbin/drbdsetup /dev/drbd1 disk /dev/md3 internal -1 failed!

The solution is to edit your lvm.conf to filter out the block devices you've assigned as DRBD devices.  Try modifying your LCM configuration like this ( found in /etc/lvm/lvm.conf on Fedora and Red Hat distros ):

# By default we accept every block device:
# Comment this out:
# filter = [ "a/.*/" ]

# Filter out your DRBD block devices, accept the rest:
filter = [ "r/md3", "a/.*/" ]

After this, rescan your LVM configuration by executing:

pvscan
vgscan
vgchange -a y

And finally start your DRBD daemon:

/etc/init.d drbd start