rootninja

Lets get a running start… Make sure KeepAlive is set to ‘On’, HostnameLookups is ‘Off’ and comment out most of the modules loaded in your default Fedora, Ubuntu, Suse, other bloated distribution’s choice for default modules. Most of them you won’t need or want to have available. You’ll probably need rewrite and php, but depending on what kind of site you’re running, you might not need all those auth modules, etc.  If you’re hosting some apps that handle their own authentication and permissions and you dont want to allow directory browsing, statistics generation, ldap authentication, or apache statistics then by all means get rid of all those modules! In Fedora you’ll find they throw in the kitchen sink to start you off.

Putting your apache on a diet and then restarting might be all the oomph you need, but you’ll probably see only a slight difference. Also, don’t just look at the memory usage right after a restart. Until your servers are actually called upon for battle, they’re just going to allocate the minimum requirements, so you might have a bunch of httpd’s running using say 10 meg each, but once they’re stressed, you might see them jump to to 20-30 meg and not let go. You’re probably going to get the most mileage out of tuning the number of servers running, maximum clients, minimum and maximum spare’s, etc. If you’re not expecting a lot of traffic and your memory is limited, you probably shouldn’t run a boat load of servers. Keep your MaxClients low so you don’t spawn so many that you start swapping right from the word go.

Your site, your traffic, and the type of content being loaded is going to affect your optimal settings. So just dive in and play around with the numbers.  Stress test your site and let it run a little while. If it gets better, then you’re probably pushing the numbers in the right direction! I’m sorry if you were looking for a “type 123 at prompt xyz” type of tutorial here. What’s working for me with 128 meg of memory is probably a little slim for the next guy.

I just hate to see people jump ship from apache to something like lighty just because they hear apache is bloated or experience that from their distribution’s default setup. Switching to another web server may just give yourself more headaches in the long run because you’re probably going to have to tweak lighty to work with the apps you’d like to run — apps that are already set up to work with apache right out of the box.

Linux apache, bloat, diet, lighttpd, lighty, memory, modules, requirements, server, tune, web

I don’t understand why some people think this is a complicated thing to set up, so here goes my approach which I think is the easiest method.  Perhaps you’re behind a very restrictive corporate firewall or you want to conserve bandwidth when you’re setting up several machines.  You can set up your own repositories on one machine in your network and have it download the packages and updates in the off-hours.  Whenever a client machine on your network wants updates, they’ll get them much faster and you’ll save bandwidth too.

Step-by-step:

Install createrepo on the machine you want to be your update server.

[user@hostname ~]$ sudo yum install createrepo

Now you’ll create a few crons to create and maintain your mirror.  Let’s start with the one that does the grunt work of downloading the packages.  I’ll go ahead and set a bandwidth limit and log my mirroring.  I don’t care about debug stuff so i’ll exclude that and any iso’s that may get dumped in there too.

#!/bin/sh
# GET THE LATEST PACKAGES
/usr/bin/rsync -aq –bwlimit=500 –stats –log-file=/var/log/rsync/i386.rsync.1.log rsync://your-favorite-linux-mirror/linux/updates/9/i386.newkey/ –exclude=debug/ –exclude=*.iso /opt/yum/updates/8/i386/
/usr/bin/rsync -aq –bwlimit=500 –stats –log-file=/var/log/rsync/x86_64.rsync.1.log rsync://your-favorite-linux-mirror/linux/updates/9/x86_64.newkey/ –exclude=debug/ –exclude=*.iso /opt/yum/updates/8/x86_64/

Create a cron to update your repo as new rpms get mirrored.

#!/bin/sh
# CREATE/MAINTAIN MY LOCAL REPOSITORY
/usr/bin/createrepo –update /opt/yum/base/8/i386
/usr/bin/createrepo –update /opt/yum/base/8/x86_64

Create another cron to rotate your logs, saving the last week’s worth.

#!/bin/sh
# ROTATE THE LOGS
rm -f /var/log/rsync/yum-rsync-log7.tar.gz
mv -f /var/log/rsync/yum-rsync-log6.tar.gz /var/log/rsync/yum-rsync-log7.tar.gz
mv -f /var/log/rsync/yum-rsync-log5.tar.gz /var/log/rsync/yum-rsync-log6.tar.gz
mv -f /var/log/rsync/yum-rsync-log4.tar.gz /var/log/rsync/yum-rsync-log5.tar.gz
mv -f /var/log/rsync/yum-rsync-log3.tar.gz /var/log/rsync/yum-rsync-log4.tar.gz
mv -f /var/log/rsync/yum-rsync-log2.tar.gz /var/log/rsync/yum-rsync-log3.tar.gz
mv -f /var/log/rsync/yum-rsync-log1.tar.gz /var/log/rsync/yum-rsync-log2.tar.gz
mv -f /var/log/rsync/yum-rsync-log.tar.gz /var/log/rsync/yum-rsync-log1.tar.gz
tar -czf /tmp/yum-rsync-log.tar.gz /var/log/rsync/*.log
rm -rf /var/log/rsync/*.log
mv -f /tmp/yum-rsync-log.tar.gz /var/log/rsync/

On your client machines, move or delete the existing repo definitions and create a new one that points to your local repositories.  Assuming your server machine’s IP address is 192.168.1.2 and you’re using Fedora your new repo definitions would look something like this:

[fairfield-base]
name=My_Local_Repo - base - Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://192.168.1.2/yum/base/$releasever/$basearch
enabled=1
gpgcheck=1

[fairfield-updates]
name=My_Local_Repo - updates - Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://192.168.1.2/yum/updates/$releasever/$basearch
enabled=1
gpgcheck=1

Wait until your cron fills your repositories or download a few packages and run your createrepo.  From now on your updates will execute much faster.  And if you want to build new machines, you can point your kickstart to get packages from your local mirror instead of just your cdrom so you can build machines that are fully up to date right out of the box.  Try updating on your clients.  You should notice it takes ten times longer to install the updates than it does to download them.

[user@hostname ~]$ sudo yum update

Linux Linux, packages, repo, rpm, rsync, server, updates, yum