Ich hab mich heute mal daran gemacht und versucht auf meinem System Ressourcen einzusparen. Als mögliche Ansatzpunkten boten sich
- Spamassassin
- amavisd-new
- Apache2
- MySQL
- vmware
- sysctl
Wichtig: Bei den hier gezeigten Optimierungen muss jeder für sich selbst entscheiden ob dies für ihn Sinnvoll ist. Ich übernehme keinerlei Haftung für etwaige Schäden!!
Spamassassin
Die Anzahl der eMails die auf meinem Server auflaufen ist relativ überschaubar. Selbst wenn mal mehrere eMails gleichzeitig reinkommen, ist es nicht weiter schlimm wenn diese ein paar Minuten in der queue liegen. Da spamassassin doch schon einiges an RAM verbraucht (5 child Prozesse) habe ich mich dazu entschieden die Anzahl der child Prozesse auf einen zu reduzieren. Dazu habe ich in der /etc/default/spamassassin unter options die Anzahl der child Porzesse vorgegeben
/etc/default/spamassassin
OPTIONS="-s /var/lib/spamassassin/spamd.log --create-prefs --max-children 1
Die Einsparung sieht danch wiefolgt aus:
USER PID %CPU %MEM VSZ RSS
root 24164 0.8 0.4 86776 4180 (5 child Prozesse)
root 2783 77.3 5.4 62028 54616 (1 child Prozess)
Es ist nicht die Welt, aber warten wir erstmal ab…
Amavisd-new
Da amavisd-new auch schon einiges verbraucht habe ich auch hier die Anzahl der Prozesse reduziert.
USER PID %CPU %MEM VSZ RSS
amavis 4296 26.1 9.4 105636 93944 (master)(0/5 Prozessen)
amavis 4563 0.0 9.3 106548 92896 (child) (1/5 Prozessen)
amavis 4564 0.0 9.3 106548 92920 (child) (2/5 Prozessen)
amavis 4565 0.0 9.3 106548 92880 (child) (3/5 Prozessen)
amavis 4566 0.0 9.3 106548 92880 (child) (4/5 Prozessen)
amavis 4567 0.0 9.3 106548 92876 (child) (5/5 Prozessen)
amavis 4877 44.7 9.4 105636 93948 (master)(0/5 Prozessen)
amavis 5131 0.0 9.3 106548 92892 (child) (1/1 Prozessen)
Dazu muss in der Datei /etc/amavis/conf.d/50-user die Variable $max_servers gesetzt werden.
/etc/amavis/conf.d/50-user
$max_servers = 1;
Apache2
Um die Ressourcen des Apache2 zu limiterien, kann man die Anzahl der max. Clients reduzieren. Ein guter Mittelwert kann errechnet werden, indem man den RAM-Verbrauch des Apaches ermittelt und anschließend errechnet wieviele Prozesse vom apach2 laufe können bis der noch freie RAM verbraucht ist.
RSS=`ps -aylC apache2 |grep "apache2" |awk '{print $8'} |sort -n |tail -n 1`
RSS=`expr $RSS / 1024`
/etc/init.d/apache2 stop
MEM=`free -m |head -n 2 |tail -n 1 |awk '{free=($4); print free}'`
/etc/init.d/apache2 start
echo "MaxClients sollte bei" `expr $MEM / $RSS` "liegen"
Der so errechnete Wert kann anschließen in der /etc/apache2/apache2.conf unter MaxClients eingetragen werden. Anschießend den Apache2 einmal neustarten.
MySQL
Wenn MySQL benutzt wird aber die Anfragen an die vorhandenen Datenbanken reltiv gering ist, kann man hier auch nich etwas RAM einsparen. Dazu können in der /etc/mysql/my.cnf folgende Werte abgeändert werden.
query_cache_size = 16M
query_cache_size = 1M
key_buffer = 16M
key_buffer = 2M
USER PID %CPU %MEM VSZ RSS
mysql 23340 0.2 0.9 130192 9388 (vorher)
mysql 9917 2.7 1.7 98596 17824 (hinterher)
VMWare
Wenn der VMWare Server auf einer Maschine installiert ist läuft auch immer die Management Oberfläche mit die einem den Webzugriff ermöglicht sowie die Administration mittels vmrun. Da man diese jedoch nicht immer benötigt kann man diese auch beenden. Wird in einem bash script später dann doch mal die vmrun benötigt, kann man den Dienst später immer noch nachstarten.
/etc/init.d/vmware-mgmt stop
Der Ressourcenverbrauch der Management Oberfläche sieht wiefolgt aus:
USER PID %CPU %MEM VSZ RSS
root 2558 0.9 1.0 245668 10300
Des weiteren ist es Sinnvoll, die Priorität von Maschinen heunter zu setzten, damit der Host selbst noch genügend Ressourcen zur Verfügung hat.
ps -e |grep vmware | awk '{print $1}' > /tmp/vmware_process_list.tmp
for i in `cat /tmp/vmware_process_list.tmp `; do renice -19 $i; done
sysctl
In der /etc/sysctl.conf können noch Kernel spezifische Parameter definiert werden. Aus meiner Sicht Sinnvoll sind folgende.
vm.swappiness = 0
vm.overcommit_memory = 1
#The lower amount of memory (in percent) where a
#writeout of dirty data to disk is allowed to stop.
#This should be quite a bit lower than the above
#dirty_ratio to allow the kernel to write out
#chunksx of dirty data in one go.
vm.dirty_background_ratio = 5
#The maximum amount of memory (in percent) to be
#used to store dirty data before the process
#that generates the data will be forced to write
#it out. Setting this to a high value should not
#be a problem as writeouts will also occur if
#the system is low on memory.
vm.dirty_ratio = 10
#How old "dirty" data should be before the
#kernel considers it old enough to be written
#to disk. It is in general a good idea to set
#this to the same value as
#dirty_writeback_centisecs above.
vm.dirty_expire_centisecs = 1000
dev.rtc.max-user-freq = 1024