lsof ist zu langsam

[sonya*]

Hallo zusammen,

es geht um einen Apache Server, der völlig überlastet ist. Ich kann aber keinen Engpass finden. Der Average Load ist sehr unregelmäßig, mal sinkt es auf 2, mal geht es hoch auf 20. Zu diesem Zeitpunkt häufen sich dann auch Apache Prozesse und werden sehr langsam abgearbeitet. Im <top> sehe ich dann den Prozess <lsof>, der mit 66 bis 77% das System für etwa 10 Sekunden mehrmals belastet und direkt danach schnellt average load nach oben. Je stärker das System ausgelastet ist, desto länger und heftiger ist der Anstieg von load average nach dem der Prozess lsof im top auftaucht. Paralellel beobachte ich Anzahl der Benutzer auf der Seite und Seitenaufrufe in Live-Statistik und kann hier keine Abweichungen vom Normalverhalten feststellen. Wofür ist der Prozess <lsof> zuständig? Warum belastet es das System so stark?

Danke,
Sonya

PS. Wenn ich lsof an der Konsole ausführe, dann dauert es bis zu 10 Sekunden bis ich die Ausgabe erhalte. Woran kann es liegen?

[sonya*]

Hallo Matthias,

lsof hat eigentlich nichts darauf zu suchen oder sollte zumindest nicht ausgeführt werden, ohne dass Du es wirklich willst.

Bewusst will ich es nicht. Es ist ein LAMP mit ein paar Standard-PHP-Open-Source drauf und einigen Modifikationen von mir. Wenn man unbewusst lsof über php aufrufen kann, dann kann es ja sein, dass ich es gewesen bin :) In diesem Fall aber nicht explizit, sondern über irgendeinen Befehl, der es nach sich zieht.

Die Frage die Ich mir stellen würde, wer ruft da neben dir lsof auf.

Eigentlich keiner. Es ist Managed Server und ich bin hier ganz alleine drauf, im top ist auch nur 1 User zu sehen.

lsof ermittelt alle offenen fielhandles, das dauert schon seine Zeit und darf auch etwas dauern.

auch wenn ich nur eine einzelne Datei mit lsof haben will:

Code: Select all

lsof /var/log/logfile 

dauert es 4-5 Sekunden. Ist es normal?

[sonya*]

Hallo,

2. Nur weil Du glaubst, nur Du bist drauf, heisst es nicht, dass Du wirklich allein drauf ist.

Klingt irgendwie philosophisch :)

Ein managed Server also.
Ja dann würde ich doch mal den Fragen der die Kiste managed wofür bezahlst Du denn mehr?

Das frage ich mich schon länger. Leider ist Support überfordert, ich bin vertraglich noch ein paar Monaten gebunden, daher muss ich meine Probleme bis dahin alleine lösen. :(

Wirklich soviel auf dem Server los, dass er kaum antworten kann.

Ja, im Moment ist nichts los, load < 1, kaum User drauf. Und es geht etwas schneller. Mit lsof access_log kriege ich 191 Zeilen in etwa 2 Sekunden:

Code: Select all

COMMAND   PID   USER   FD   TYPE DEVICE       SIZE    NODE NAME
apache  22260 wa6402   17w   REG    8,3 2739225837 9308691 /home/wa6402/home/log/access_log
......

Die Zeilen unterscheiden sich nur in der Spalte PID und FD, ansonsten ist alles gleich. Sieht es OK aus? Ich konnte nirgendwo finden, wieviele Zeilen normal sind bei der Ausgabe.
Darüber hinaus habe ich noch sowas gemacht, ich weiß nicht, ob es Sinn macht, aber ich dachte ich könnte so sehen, was von lsof selbst im Moment offen gehalten wird:

Code: Select all

# lsof | grep lsof
lsof       8241     root  cwd       DIR        8,3       4096    8732747 /home/admin10327
lsof       8241     root  rtd       DIR        8,3       4096          2 /
lsof       8241     root  txt       REG        8,3     106324    6408342 /usr/bin/lsof
lsof       8241     root  mem       REG        0,0                     0 [heap] (stat: No such file or directory)
lsof       8241     root  mem       REG        8,3    1241392   19235849 /lib/tls/i686/cmov/libc-2.3.6.so
lsof       8241     root  mem       REG        8,3      88164   19220004 /lib/ld-2.3.6.so
lsof       8241     root    0u      CHR      136,0                     2 /dev/pts/0
lsof       8241     root    1w     FIFO        0,6             108562068 pipe
lsof       8241     root    2u      CHR      136,0                     2 /dev/pts/0
lsof       8241     root    3r      DIR        0,3          0          1 /proc
lsof       8241     root    4r      DIR        0,3          0  108562071 /proc/8241/fd
lsof       8241     root    5w     FIFO        0,6             108562074 pipe
lsof       8241     root    6r     FIFO        0,6             108562075 pipe
lsof       8243     root  cwd       DIR        8,3       4096    8732747 /home/admin10327
lsof       8243     root  rtd       DIR        8,3       4096          2 /
lsof       8243     root  txt       REG        8,3     106324    6408342 /usr/bin/lsof
lsof       8243     root  mem       REG        0,0                     0 [heap] (stat: No such file or directory)
lsof       8243     root  mem       REG        8,3    1241392   19235849 /lib/tls/i686/cmov/libc-2.3.6.so
lsof       8243     root  mem       REG        8,3      88164   19220004 /lib/ld-2.3.6.so
lsof       8243     root    4r     FIFO        0,6             108562074 pipe
lsof       8243     root    7w     FIFO        0,6             108562075 pipe

-> Trotzdem würde ich versuchen mit ps -ef |grel lsof heraus zu finden, wer ggf. den Prozess aufruft.

Code: Select all

root      4115 13833  0 22:46 pts/0    00:00:00 grep lsof

Danke für Deine Hilfe!

[sonya*]

und warum liefert lsof access_log 191 Zeilen vor allem welche...

Es sind immer die gleichen Zeilen in der nur PID und FD unterschiedlich ist. Jetzt unter Last sind es so viele Zeilen, dass ich sie nicht mal zählen kann.

Code: Select all

COMMAND   PID   USER   FD   TYPE DEVICE       SIZE    NODE NAME
apache  28672 wa6402   53w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  28672 wa6402   54w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  28672 wa6402   55w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   17w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   19w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   20w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   21w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   22w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   23w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   24w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   25w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   26w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   27w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   28w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   29w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   30w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   31w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   32w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   33w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   34w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   35w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   36w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   37w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   38w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   39w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   40w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   41w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   42w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   43w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   44w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   45w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   46w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   47w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   48w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   49w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   50w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   51w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   52w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   53w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   54w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
apache  30580 wa6402   55w   REG    8,3 3320964907 9308691 /home/wa6402/home/log/access_log
......

Wieviel Zeilen wären da normal? Oder wo kann man darüber nachlesen, was es überhaupt bedeutet? Ich wäre sehr dankbar für einen Tipp.

[Joe User]

und warum liefert lsof access_log 191 Zeilen

Mindestens eine pro Website-Zugriff...

[sonya*]

Ich frage mich nach wie vor, wer oder was lsof aufruft.
Das würde ich zumindest mal abstellen wollen.

Der Rätsel ist gelöst. Diesmal wusste Support ausnahmsweise Bescheid: "lsof prüft das System auf Schadhafte Scripte und beendet diese." Ich habe gebeten dieses Skript abzuschalten, mal sehen, ob es etwas bringt.

Danke für die Hilfe allerseits!

[suntzu]

lsof prüft das System auf Schadhafte Scripte und beendet diese.

????
OK, DAS ist mir jetzt aber neu ... Bei mir ist das eher

Code: Select all

(/home/ds)$ yum search lsof | grep ^lsof
lsof.x86_64 : A utility which lists open files on a Linux/UNIX system

bzw. auf dem Server

Code: Select all

~# aptitude search lsof
p   lsof                            - List open files

Alsof was auch immer dein Hoster da programmiert hat, der Name ist mehr als unglücklich gewählt ...

[Roger Wilco]

Alsof was auch immer dein Hoster da programmiert hat, der Name ist mehr als unglücklich gewählt ...

Ich schätze mal, dass der zitierte Mitarbeiter sich nur etwas unglücklich ausgedrückt hat. Mit lsof (bzw. einem kleinen Skript, das lsof nutzt), kann man z. B. prüfen, welche Programme einen Netzwerksocket geöffnet haben, die das evtl. nicht sollen, und diese dann beenden.

[sonya*]

Leider ist das Problem wieder zurück. Die Antwort von meinem Provider:

Code: Select all

Der Prozess prüft wohl eine Grafikfuntkion in Verbindung mit der GDlib. Was dieser genau tut ist uns aber nicht bekannt.

Leider war meine Suche im Zusammenhang mit gdlib und lsof-Prozess im top erfolglos. Weiß jemand, was es sein könnte? Ich benutze GDLib zu generieren von Grafiken. Ich verändere keine vorhandene Grafiken, sondern generiere Charts aus der Datenbank. Wenn Sie einmal generiert sind, dann werden sie auf der Festplatte als jpg abgelegt und die auch angezeigt. Nur bei einer Änderung in den Daten wird JPG gelöscht und dann eine neue Bilddatei generiert. Kann jemand Stichworte geben, wonach ich hier suchen könnte?

[Joe User]

Kann es sein, dass die Grafikerzeugung nicht sauber beendet wird und dabei ein Fielhandle offen bleibt?

Auch dann wird lsof nicht automagisch ausgeführt...

[sonya*]

Ich hatte die erneute Rückmeldung so verstanden, dass der Support wieder deren "Script zum prüfen Toter Prozesse" angeworfen hat.
Gruss Matthias

Nein, es gibt (gab) 2 unterschiedliche Gründe für das lsof im Top. Der erste stammte vom Script zum prüfen von schädlichen Prozessen auf dem Server, gehört dem Provider und wurde abgeschaltet. Der zweite stammt, wie der Provider sagt von mir und hat etwas mit GDlib zu tun.

Kann es sein, dass die Grafikerzeugung nicht sauber beendet wird und dabei ein Fielhandle offen bleibt?

Rein theoretisch ja, ich habe den Skript selbst geschrieben. Ich weiß aber nicht, was mit "Grafikerzeugung nicht sauber beendet wird" gemeint wird. GDLib erzeugt ein image ressource ($image) und den speichere ich dann erstmal im Dateisystem als Cachefile ab und dann gebe an den Browser weiter zur Ausgabe

Code: Select all

imagejpeg($image,'/pfad/cachefile',65);
imagedestroy($image);
readfile('/pfad/cachefile');

An welche Stelle wäre die Grafikerzeugung nicht sauber beendet? Alle Grafiken werden einwandfrei erzeugt und abgespeichert, wenn es nicht so wäre, hätten die Benutzer mich erschlagen :) In Google finde ich auch nichts zum Thema gdlib und open filehandle.

[sonya*]

Besteht die Möglichkeit in Linux "den Ursprung" eines Prozesses zu finden? Da ich nichts, aber rein gar nichts im Zusammenhang mit GDLib zum Thema lsof finde, gehe ich davon aus, dass der Skript "zum entfernen von schädlichen Prozessen" weiterhin auf dem Server läuft, obwohl der Provider meinte, dass er ihn abgeschaltet hat.

Kann ich irgendwie beweisen, dass der Prozess nicht von mir, sprich Apache, PHP5 (als module) oder MySQL5 stammt? Im Top sehe ich, dass der Prozess <lsof> mit Benutzer <root> ausgeführt wird, die Apache Prozesse sind mit einem anderen Benutzer unterwegs, mysql hat auch einen anderen User. Kann ich davon ausgehen, dass alle Prozesse, die mit "root" laufen, nicht von mir stammen?

[sonya*]

Wenn Dein Script lsof aufruft, warum machst Du das bzw. an welche Stelle wird das aufgerufen?

Ich selbst mache es nicht explizit. Es kann nur sein, dass meine Programmierung es irgendwie implizit verursacht. Explizit wird lsof nur vom Provider in seinem Skript zum "Überprüfen der schädlichen Prozesse" auf dem Server aufgerufen. Auf meine Bitte hin, wurde dieser Skript vom Provider abgeschaltet (sagt er). Ich habe aber keine Änderung in top-Ausgabe festgestellt.

[Joe User]

Der zweite stammt, wie der Provider sagt von mir

Richtig, zumindest wird es wohl durch Deinen User ausgeführt.

und hat etwas mit GDlib zu tun.

Falsch, GDlib nutzt lsof nicht und Du tust es offensichtlich auch nicht, sonst wüsstest Du es.

Dein Provider sollte den Server mal gründlich untersuchen, ich vermute einen erfolgreichen Einbruch...

[sonya*]

Danke Dir. Ich habe es mehrmals ausgeführt:

Code: Select all

root      1736  1735 76 15:18 ?        00:00:05 lsof -i
...
root      6466  6465 68 15:19 ?        00:00:05 lsof -i
...
root     11936 11935 44 15:20 ?        00:00:00 lsof -i
...
root     16973 16972 61 15:21 ?        00:00:06 lsof -i

Dabei ist mir aber etwas ganz Wichtiges aufgefallen. Der Prozess wird regelmäßig, 1 Mal in der Minute gestartet. Das würde bedeuten, dass entweder meine Benutzer auf dem Server einen Zwangverhalten haben und nur jede Minute etwas ausführen oder der Provider hat sein Skript doch nicht abgeschaltet, wie ich schon vermutet habe. :x

Eigentlich habe ich root-Rechte auf dem Server, kann ich es irgendwie selbst abschalten? Ich weiß, ich habe einen Managed Server, aber wenn der "Manager" es nicht schafft....

[sonya*]

Und schau Dir die öffentliche mal an:
cat /etc/crontab.

Super!!! Vielen Dank. Ich habe den Eintrag für den Skript gefunden, auskommentiert und siehe da, die load average geht konsequent runter. Und fällt auch langfristig weiter (von 9 auf jetzt 3), ohne dass die Zugriffe auf den Server nachlassen. Ich bin überglücklich.

Richtig, zumindest wird es wohl durch Deinen User ausgeführt.

Es gab da keinen, der von meinem User ausgeführt wurde, nur der vom Root. Mein Provider meinte aber zu mir, dass es da irgendeinen vom GDLib wäre.

Falsch, GDlib nutzt lsof nicht und Du tust es offensichtlich auch nicht, sonst wüsstest Du es.

Ja, nach dem ich den Auruf in Cron auskommentiert habe ist lsof komplett aus der top Ausgabe verschwunden.

Vielen lieben Dank an alle, die mitgeholfen haben. Ich hoffe, dass es sich jetzt erledigt hat.

PS. Und Finger weg von den langen Vertragslaufzeit mit "Managed Service". Wenn man guten Service bietet, dann braucht man nicht die Angst zu haben, dass Kunden gehen. Wenn der Service aber so miserable ist, wie in meinem Fall, dann wird es auf Dauer trotzdem nichts und die Kunden nach Ablauf Vertragslaufzeit mit schlechten Empfehlungen trotzdem abhauen.