Eine Anwendung hatte am 26.07.06 einen kurzzeitigen Fehler:
CODE:
Warning: mysql_connect() [function.mysql-connect]:
#HY000Can't create a new thread (errno 11);
if you are not out of available memory, you can consult the
manual for a possible OS-dependent bug in
/var/www/scripnamen/connect.php on line 25
no connection to server
Auf dem virtuosu (o.ae.) Server sind Aussagen bezüglich Arbeitspeicher meiner Meinung nach mit Vorsicht zu geniessen. Ausserdem habe ich nicht gleich nachsehen können, was auf dem Server los ist, weil ich keine Zugriffsmöglichkeit hatte. Deshalb habe ich heute Abend ein Äberwachungstool namens
mempeak gestartet, um dem Äbeltaeter auf die Schliche zukommen.
Ab 19:46 habe ich mit screen mempeak gestartet. Ich bin gespannt, ob das was ergibt.
Weil das nun alles etwas länglich wird, folgt die Beschreibung nun im erweiterten Teil.
Doch vor der Beschreibung ein paar Worte zu den verwendeten consolentools screen und mempeak.
screen:
screen stammt aus einer Zeit, in der man noch kein Wan kannte, sondern man sich auf entfernen Rechnern vornehmlich über Modems oder angemietete Standleitungen einloggen musste.
Standard war auf Standleitungen 9600 Baud, jedenfalls in unserer Firma. Manchmal gab es auch schon mal 19200 Baud (das sind also 19000 Zeichen in der Sekunde, da kann man den Bildschirmaufbau noch verfolgen nur mal als Erinnerung ) Es verbot sich da jede Art von grafischer Oberfläche, klar, soweit?
Zudem kamen noch Leitungsunterbrechungen, vor allem dann, wenn man gerade als Administrator irgendwelche Probleme bekämpfte. Zu der Zeit wurde Screen entwickelt, welches man direkt nach dem Einloggen startete. Ein Aufruf ohne Parameter erschafft einen "screen", der über die Connection
hinaus weiter lebt. D.h. sollte die Verbindung plötzlich zusammenbrechen, egal aus welchem Grund, kann jeder Zeit, also auch Tage später, die Sitzung, (der "screen") wieder aufgenommen werden, indem man einfach screen -r aufruft. Das -r steht fuer resume. Der Witz an der Sache ist nun, das alle in dem "screen" gestarteten Prozesse weiterarbeiten und zwar auch ausgabeintensive Programme wie z.B. top, oder eben auch mempeak, zu dem ich gleich komme.
Der aufgeweckte Newbie wird nun evtl. einwerfen. "Aber es gibt doch nohup! Warum wird nicht einfach das genommen?" Der Unterschied ist erstens, das nohup keine Programme mit Bildschirmausgaben weiterlaufen lassen kann, man müsste dann mit Ausgabeumleitungen in Dateien arbeiten, die dann erst ausgewertet werden müssen. Zweitens hilft nohup nicht gegen die ungeplanten Unterbrechungen. Screen ist noch wesentlich leistungsfähiger, man kann praktisch beliebig viele "screens" damit eröffnen und verwalten, einfach mal mit man screen schauen und ausprobieren. Screen ist häufig bereits bei eine Linuxdistribution dabei, wenn nicht, einfach nachinstallieren, zur Verfügung steht es jedenfalls immer.
Geplantes aussteigen mache ich immer CTRL-a d (Detach)
mempeak
Im Unterschied zu top zeigt mempeak nicht nur die aktuellen Prozesse mit ihrem Speicherverbauch an, sondern auch vergangene Prozesse mit ihren max. Werten. Im Kopfteil sind noch allerlei Minima und Maxima aufgelistet. Um ein Problem wie dieses mysql Problem zu finden, eignet sich mempeak geradezu ideal.
mempeak hat es nicht in die Repositories der Linuxdistributionen geschafft, die letzte mir bekannte Version ist 0.26. Einfach in Google danach suchen, installieren und unter normalen Useraccount starten.
Stand 27.07.06: offensichtlich ist die Homepage nicht erreichbar, aber in diesem Verzeichnis liegt es noch rum.
Direkt nach dem Start sieht die Bildschirmausgabe auf dem virtuellen Server so aus...
Ich habe also am 26.07. gegen 19:50 screen und dann mempeak gestartet. Laufende Prozesse werden in hell dargestellt. Bereits beendete sind dunkler.
am 27.07. sieht das dann so aus. Jede Menge beendeter mysql Prozesse, enttäuschender Weise ist kein Prozess im Arbeitsspeicherverbrauch auffallend anders. Beziehungsweise glücklicherweise. Denn wenn nach 20 Stunden kein Prozess auftauchte, der Speicher frisst, sollte man eigentlich zufrieden sein. Zur Bestätigung sieht man im Kopf auch, das immer Swapspace freigewesen ist. Der eingangs beschriebene Fehler ist in den 4 Monaten, die der Server nun läuft, mir auch nur einmal aufgefallen....
Interessanter ist es, direkt danach in google zu suchen, dort sind unter den ersten 10 Treffern viele Seiten, die sich überhaupt gar nicht mit dem Thema beschäftigen. Deshalb bleibt mir als Fazit nur die Theorie, das es zu einer kurzzeitigen Spitze kam, evtuell durch mehrere Suchbots und/oder Spam Attacken gleichzeitig.
Wie dem auch sei, dank Screen kann ich mempeak noch einige Zeit weiter laufen lassen. Ich bin gespannt, ob ich noch etwas interessantes entdecken kann.
Zockertown am : einen prozess nachträglich in den nohup-status versetzen!