Blogs/20070211 vserver und semaphores
Hallo zusammen,
da bin ich mal wieder.
Ich hatte in den letzen Tagen stark damit zu kämpfen, dass die ein Linux Server nur eine bestimmte Anzahl an Semaphores bereitstellt.
Diese Semaphores werden wenn ich das richtig verstanden hab, dazu eingesetzt, dass zB einzelne Apacheprozesse untereinander zur Laufzeit kommunizieren können.
Wie alles begann:
Ich hatte 15 vServer auf einem Server installiert. Jedoch wollte plötzlich beim 16ten der apache nicht mehr starten.
Folgende Fehler traten auf:
cat /var/log/apache2/error.log
[emerg] (28)No space left on device: Couldn't create accept lock (/var/lock/apache2/accept.lock.10486) (5)
das einzigst komische war, dass sowohl genug RAM als auch genug Festplattenspeicherplatz zur Verfügung standen. Wobei es kann ja sein, dass verschiedene Limits eventuell erreicht wurden:
cat /proc/virtual/7016/limit
Limit current min/max soft/hard hits PROC: 8 0/ 13 -1/ -1 0 VM: 38185 0/ 75589 1024000/ 1024000 0 VML: 0 0/ 0 -1/ -1 0 RSS: 2388 0/ 4336 128000/ 256000 0 ANON: 2796 0/ 3029 -1/ -1 0 FILES: 248 0/ 268 -1/ -1 0 OFD: 149 0/ 165 -1/ -1 0 LOCKS: 2 0/ 2 -1/ -1 0 SOCK: 88 0/ 88 -1/ -1 0 MSGQ: 0 0/ 0 -1/ -1 0 SHM: 0 0/ 0 -1/ -1 0 SEMA: 0 0/ 0 -1/ -1 0 SEMS: 0 0/ 0 -1/ -1 0 DENT: 191 0/ 232 -1/ -1 0
Auch das war nicht der Fall langsam wurde ich ratlos, also wand ich mich an die linux-vserver Mailingliste. Diese halfen mir dann auf die Sprünge, dass es an den Semaphoren liegen kann. Wer mehr über Semaphoren wissen will (http://de.wikipedia.org/wiki/Semaphor_%28Informatik%29).
Tja nun war das Problem da wie krieg ich raus welche Werte und Limits die Semaphoren denn nun haben?
Nach langem suchen kam ich dann in das Verzeichnis /proc/sys/kernel.
Dort gab es dann endlich was mit shm* und sem.
Nun war nur noch die Frage was steht denn momentan wo im Speicher. Glücklicherweise wurde mir da aus dem #vserver auf otfc.net das entscheidende Tool zur Hand gegeben: ipcs
ipcs -h
ipcs provides information on ipc facilities for which you have read access.
Resource Specification:
-m : shared_mem
-q : messages
-s : semaphores
-a : all (default)
Output Format:
-t : time
-p : pid
-c : creator
-l : limits
-u : summary
-i id [-s -q -m] : details on resource identified by id
usage : ipcs -asmq -tclup
ipcs [-s -m -q] -i id
ipcs -h for help.
Ich führte erst einmal in dem guest dieses command aus, jedoch war wie zu erwarten der output leer, dh keine Semaphors waren in Benutzung. Auf dem Hauptsystem brachte mich ipcs auch nicht weiter, denn es zeigte die Benutzen Semaphores der Gäste leider nicht an.
Deshalb schaute ich mir zuerst einmal die gesetzten Limits an:
ipcs -l
ipcs -l ------ Shared Memory Limits -------- max number of segments = 4096 max seg size (kbytes) = 32768 max total shared memory (pages) = 2097152 min seg size (bytes) = 1 ------ Semaphore Limits -------- max number of arrays = 128 max semaphores per array = 250 max semaphores system wide = 32000 max ops per semop call = 32 semaphore max value = 32767 ------ Messages: Limits -------- max queues system wide = 16 max size of message (bytes) = 8192 default max size of queue (bytes) = 16384
Ahja da waren Sie ja nun endlich die gesetzten Limits. Durch wikipedia war ja klar, dass die semaphoren in arrays arbeiten und diese sind standardmäßig auf 128 begrenzt.
Nun musste ich nur noch herausbekommen, wie viele denn momentan tatsächlich in Benutzung sind:
ipcs -su
------ Semaphore Status -------- used arrays = 121 allocated semaphores = 121
Kein Wunder, dass sich da kein weiterer Apache mehr starten lassen hat, denn auf einem anderen guest war zu sehen, dass dieser mit apache2 10 semaphores benötigt.
Also eigentlich hätte schon vserver #13 keine Apaches mehr starten dürfen, aber eventuell variiert das auch noch viele gebraucht werden, da ist noch einiges an Studium meinerseits von Nöten.
Nun machte ich mich auf die Suche wo ich denn das Semaphore Limit erhöhen könne. Die Lösung liegt in /proc/sys/kernel/sem
cat /proc/sys/kernel/sem
250 32000 32 128
Da sind unsere 128 schon wieder also setzen wir diese eben direkt neu:
echo 250 32000 32 256 > /proc/sys/kernel/sem
Und siehe da der Apache hat sich direkt starten lassen und läuft schön stabil.
Die einzigste Frage die ich mir momentan noch stell ist, ob die Zahl nicht doch zu hoch ist und das System gefährden kann. Ich habe 256 gewählt, da dies die nächste 2er Potenz zu 128 ist.
Ich denke irgendwann werde ich auch noch einen schönen Wert in finden.
Das ganze kann man danach noch statisch machen, damit es beim nächsten reboot nicht verloren geht:
vi /etc/sysctl.conf
und folgendes einfügen:
kernel.sem = 250 32000 100 256
Somit hat man auch nach dem nächsten Bootvorgang keinerlei Probleme mehr damit, dass die Apaches in den vServern nicht starten.
--crypt 11:53, 11. Feb 2007 (CET)
