• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Linux-Befehle laufen zu lange

A

apollo

Newbie
Hallo Linux-Club,

ich weiß leider nicht, ob ich in diesem Forum richtig bin. Ich schildere einfach mein Problem:

Seit etwa zwei Tagen brauchen bestimmte (aber bei weitem nicht alle) Linux-Befehle elend lange, bis sie abgearbeitet sind. Zum Beispiel ist das bei grep oder vi der Fall. Der vi ist übrigens extrem übel. Gebe ich z.B. "vi /etc/hosts" dauert es ca. 3 Sekunden, bis die Anzeige kommt. Die hosts hat übrigens 1870 Byte. Noch schimmer ist, wenn man mit einem einfachen ":q" den vi wieder verlassen will. Das dauert dann gestoppte 11 Sekunden. Während dieser Zeit ist der vi bei der top-Anzeige mit 99% Prozessor-Leistung auf Platz 1. Noch ein Beispiel ist der grep:
Code: 
time ps -f > /dev/null
    0.05s real     0.02s user     0.03s system
time ps -f | grep kernel
user   4368  3101  0 15:18 pts/7    00:00:00 grep kernel
    0.90s real     0.34s user     0.60s system
Ich habe schon folgendes Nachgesehen:
- die Prozessoren langweilen sich (ca. 98% idle)
- die gemounteten Filesysteme arbeiten OK. Der copy einer Testdatei erfolgt zügig
- der Hauptspeicher ist zu zwei dritteln leer. Der swap-Bereich ist sogar ganz leer

Hat irgendjemand irgendwelche Ideen? Reboot hilft nicht ...

Vielen Dank im Voraus!
 
A

Anonymous

Gast
Leider sind die Ursachen für solche Fehler sehr schwer zu finden, das können ganz banale Dinge sein, die scheinbare gar nichts mir diesen Befehlen zu tun zu haben scheinen und sich trotzdem der Art auswirken können. Wenn du nach ausgiebigem googlen immer noch nichts gefunden hast. Ich würde etwas so vorgehen:
  • Zu erst einmal überlegen, ob was am System verändert wurde, evtl irgendwelche Patche installiert oder irgendwas umkonfiguriert.
  • Als nächste würde mir mal einfallen nach Dateiänderungen der letzten Tage in allen bin lib modules und etc Verzeichnissen zu suchen.
  • Nächster Schritt den ich machen würde, die Quersummen vergleichen, dazu bräuchtest du allerdings ein Reverenzsystem.
  • Wenn dann noch kein Ansatzpunkt gefunden ist, dann ist zu überlegen ob es sich lohnt den Fehler zu suchen, oder ob man evtl. auf ein Recover zurückgreifen kann.
  • danach Zauberwort strace. Leider überhaupt nicht so ganz einfach zu erklären.
    Wenn du gar nicht weißt was strace ist dann zum Einstieg http://www.linuxeinsteiger.info/anleitungen/admin/admin7.php
  • Da die Fehler sich bei dir mit relativ einfachen Programmen rekonstruieren lassen, würde ich aus einem 2 Terminal strace -p PID ( PID der Bash in der zB das grep oder der vi gestartet wird)beginnen.
  • Wenn dort keine Auffälligkeiten dann mit -tt versuchen ob man etwas an den Zeitstempeln (eventuell mit einem 2. System vergleichen) findet.
  • Wenn dort auch noch nichts auffälliges dann mit -f auch noch in die Subprozesse hinein.
  • Nach einer Woche ergebnisslosen Suchens würde ich mir langsam Gedanken machen, das System neu zu installieren und meine privaten Daten und Dateien dabei zu übernehmen.

nicht allzusehr ermutigend, aber eventuell hilft es ja weiter.

robi
 
OP
A

apollo

Newbie
Hallo robi,

vielen Dank für deine ausführliche Antwort. Dein Vorschlag mit dem "strace" war gut! Ich habe folgendes gemacht:
Code: 
strace vi 2> strace_vi.log
Zwischendurch musste ich natürlich ":q" eingeben.
Strace hat ca. 900 MB Daten erzeugt. Auffällig sind folgende Einträge:
  • mremap(0x401fc000, 262144, 266240, MREMAP_MAYMOVE) = 0x401fc000
    mremap(0x401fc000, 266240, 270336, MREMAP_MAYMOVE) = 0x401fc000
    mremap(0x401fc000, 270336, 274432, MREMAP_MAYMOVE) = 0x401fc000
    mremap(0x401fc000, 274432, 278528, MREMAP_MAYMOVE) = 0x401fc000
    [...]
    mremap(0x401fc000, 2145378304, 2145382400, MREMAP_MAYMOVE) = 0x401fc000
    mremap(0x401fc000, 2145382400, 2145386496, MREMAP_MAYMOVE) = -1 ENOMEM (Cannot allocate memory)
Dieser Block ist genau 525765 Zeilen lang und wiederholt sich 25 mal. Insgesamt ist mein trace über 13 Millionen Zeilen lang, und nur 1165 fangen nicht mit "mremap" an.

Mein Verdacht - ohne genau bescheid zu wissen: Hauptspeicher kaputt. Was meint ihr?

Auf jeden Fall schon mal ein "Dankeschön"!
 
OP
A

apollo

Newbie
Im Falle des grep scheint die Sache nicht so ganz klar zu sein.
Code: 
time ( strace -f -tt echo test | grep t ) 2> strace_grep.log
    0.93s real     0.37s user     0.57s system
time echo test | grep t
    0.88s real     0.38s user     0.50s system
strace_grep.log enthält:
  • 09:46:28.050251 execve("/bin/echo", ["echo", "test"], [/* 91 vars */]) = 0
    09:46:28.050711 uname({sys="Linux", node="host", ...}) = 0
    09:46:28.051147 brk(0) = 0x804a678
    [...]
    09:46:28.061121 write(1, "test\n", 5) = 5
    09:46:28.061212 munmap(0x4001f000, 4096) = 0
    09:46:28.061300 exit_group(0) = ?
Zwischen der ersten und der letzten Zeile liegen also rund 0.01 Sekunden. Warum braucht der ganze Befehl aber fast 1 Sekunde? Rätsel über Rätsel ...
 
A

Anonymous

Gast
was das genau zu bedeuten hat weiss ich auch nicht,
Habe den Befehl mal auf einem SUSE 7.2 mit 2.4.18-64GB-SMB Kernel gestartet und bekam nur 256 Zeilen und die besagte mremap Zeilen waren nicht dabei ???

na mindestens hast du eine Anhaltspunkt wo du weitersuchen könntest, irgendwas bei der Speicherverwaltung scheint jedenfalls total daneben zu liegen.

robi
 
OP
A

apollo

Newbie
Was ich gerade feststellte: Der Befehl "date" ist auch noch so ein Kandidat:
Code: 
host(user)~> time date
Don Mär  3 10:46:12 CET 2005
    0.89s real     0.36s user     0.53s system
host(user)~> strace date 2> strace_date.log
host(user)~> grep -c ^mremap strace_date.log
525855
 
OP
A

apollo

Newbie
Hallo nochmal!

Anscheinend lag es an der Glibc. Diese wurde ersetzt (nicht von mir) und jetzt sieht alles wieder in Ordnung aus

Vielen Dank für die schnelle Hilfe!
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben