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

Rechner extrem lahm

Treito schrieb:
Code:
/dev/sdb:
 Timing cached reads:   3492 MB in  2.00 seconds = 1745.73 MB/sec
 Timing buffered disk reads: 320 MB in  3.02 seconds = 106.03 MB/sec
Vollkommen normale Werte (bzw. recht gute, ca. 2x schneller als der Rechner vor mir).
 
Nein,

das sind gute Werte (Windoof-Platte):
Code:
/dev/sda:
 Timing cached reads:   3466 MB in  2.00 seconds = 1732.45 MB/sec
 Timing buffered disk reads: 358 MB in  3.00 seconds = 119.25 MB/sec
Okay, es geht mittlerweile schneller, aber das langt vollkommen. Was nützt mir die schnelle Platte, wenn Linux zickt?

Auf der root-Partition sind im Übrigen noch 51 GB frei, bevor die Frage wieder auftaucht.
 
Der Rechner wird schon wieder langsamer, ist ja auch irgendwo kein Wunder:

Code:
free -m
             total       used       free     shared    buffers     cached
Mem:          3958       3842        115          0          9        400
-/+ buffers/cache:       3432        525
Swap:         6142        913       5229
 
Vorschläge zur weiteren Problemeingrenzung hast Du hier direkt vor Augen, wenn auch etwas verstreut. Schaue Dir vor allem mal ein paar logfiles an - ein solches Verhalten wird normalerweise in irgend einer Form vom System protokolliert. Die Ausgaben von 'top' etc. musst Du übrigens nicht in eine Datei umleiten, Du kannst sie auch einfach mal eine Weile lang beobachten.
 
gropiuskalle schrieb:
Die Ausgaben von 'top' etc. musst Du übrigens nicht in eine Datei umleiten, Du kannst sie auch einfach mal eine Weile lang beobachten.

Das ist ja das Problem! Die Kiste wird irgendwann sowas von lahm, dass sich das vielleicht mal alle 5 Minuten aktualisiert, wenn ich es überhaupt schaffe, das Fenster in den Vordergrund zu holen, denn auf Maus oder Tastatur reagiert er dann auch fast nicht mehr...

Das wären die Fehlermeldungen aus dem Log:
May 7 08:46:51 linux-7nvz sudo: sven : TTY=pts/3 ; PWD=/home/sven ; USER=root ; COMMAND=/bin/mount /media/Transfer
May 7 08:47:04 linux-7nvz kernel: [ 425.475031] CIFS VFS: rsize 32768 too large, using MaxBufSize
May 7 08:47:51 linux-7nvz kernel: [ 472.278444] CIFS VFS: Autodisabling the use of server inode numbers on \\192.168.243.34\Share. This server doesn't seem to support them properly. Hardlinks will not be recognized on this mount. Consider mounting with the "noserverino" option to silence this message.
May 7 08:48:40 linux-7nvz dhclient: XMT: Solicit on eth0, interval 131630ms.
May 7 08:50:51 linux-7nvz dhclient: XMT: Solicit on eth0, interval 121440ms.
May 7 08:52:53 linux-7nvz dhclient: XMT: Solicit on eth0, interval 110850ms.
May 7 08:54:44 linux-7nvz dhclient: XMT: Solicit on eth0, interval 115330ms.
May 7 08:56:39 linux-7nvz dhclient: XMT: Solicit on eth0, interval 120470ms.
May 7 08:58:40 linux-7nvz dhclient: XMT: Solicit on eth0, interval 108500ms.
May 7 09:00:28 linux-7nvz dhclient: XMT: Solicit on eth0, interval 130220ms.
May 7 09:02:39 linux-7nvz dhclient: XMT: Solicit on eth0, interval 124510ms.
May 7 09:04:43 linux-7nvz dhclient: XMT: Solicit on eth0, interval 112590ms.
May 7 09:06:36 linux-7nvz dhclient: XMT: Solicit on eth0, interval 112270ms.
May 7 09:08:28 linux-7nvz dhclient: XMT: Solicit on eth0, interval 127530ms.
 
Ich habe in der Testphase eines Rechners immer xosview im Autostart. Das kleine Fenster schieb ich irgendwo an den Rand, wo es nicht stört und möglichst immer sichtbar ist. Es zeigt mir auf einen Blick plakativ an, was gerade im Rechner abgeht. Zum Beispiel auch, wann wieviel Speicher belegt wird. Durch Abgleich mit meiner vorherigen Aktion habe ich bisher immer rausbekommen, welches Programm dran schuld war. Nur bei KDE selbst musste ich doch manchmal suchen. Allerdings verrät sich KDE, wenn viel Speicher schon nach dem Start des Desktops verbraten wird.

Scheinbar "stehender Rechner" wird oft verursacht durch CPU-Last von 100%. Bei Dir riecht es danach. Bei mir gab es dafür zwei Ursachen: der x-init-Prozess mit der grafischen Oberfläche oder auch python-hp-systray. Wenn ich bei xosview sah, da stimmt was nicht, kam sofort htop zum Einsatz, das klärt dann genauer auf. Aber ich gebe zu, dass man dann doch mal sehr viel Geduld haben muss, bis htop startet. Es kann hilfreich sein, es vorher schon zu starten.

Hartmut
 
python-hp-systray?! Och nöööööööö, aber wieso dann nur bei manchen Rechnern?!

Nachtrag: Eine Sache ist mir auch noch aufgefallen: Der Grafikkartenlüfter rödelt deutlich mehr rum, als unter W7!
 
Hallo,

Ein weiters Tool welches Du (ständig) laufel lassen könntest ist "ksysguard"

Entweder vom KMenü > System > Monitor > System Monitor (= "ksysguard")

oder diekt von "/usr/bin/ksysguard"

Da siehst Du die laufenden Prozesse (mit CPU und Memory Auslastung) -- sowohl tabularisch (erstes Tab) wie auch grafisch (zweites Tab).

Gruss,
Roland
 
RME schrieb:
Ein weiters Tool welches Du (ständig) laufel lassen könntest ist "ksysguard"
Wenn die Ressourcen so kanpp werden dass die Ausgabe von top nicht aktuell sind dann hilft es wohl wenig statt dessen irgendein ressourcenlastigeres zu verwenden.

Wobei ich das der Meinung bin dass top das richtige Tool wäre - auch wenn das Update nicht klappt dürften die oben angezeigten Anwendungen die Problemfälle sein.
 

Jägerschlürfer

Moderator
Teammitglied
ich denke du solltest, bevor dein Rechner langsam wird, mal die ganzen Dienste der Reihe nach beenden, die du nicht benötigst. Sprich wie in dem log zu sehen ist, cifs vfs,...
Nicht, dass es ein Dienst ist, der deinen Rechner so ausbremst.
 
Pulseaudio war schon mal Bremse 1.
Was ist eigentlich mit den Fehlermeldungen bzgl. eth0?
Wie kann ich herausfinden, warum er so extrem viel in der swap-Datei auslagert?
 
Jägerschlürfer schrieb:
ich denke du solltest, bevor dein Rechner langsam wird, mal die ganzen Dienste der Reihe nach beenden, die du nicht benötigst. Sprich wie in dem log zu sehen ist, cifs vfs,...
Nicht, dass es ein Dienst ist, der deinen Rechner so ausbremst.

Zu spät! Da ich ein anderes Problem habe (Drucker), wollte ich eben bei Gimp was testen. Beim 1. Mal habe ich das pdf aus Versehen mit 100dpi importiert. Dann wollte ich es mit 300dpi noch mal neu importieren und was war?! Rien ne vas plus! Nichts geht mehr!

Also wie bekomme ich das nun raus? htop lief, aber keine Chance, das zu öffnen!
 
Aber wie finde ich heraus, was er warum und wieviel in der swap auslagert?
Mit dem Deaktivieren hoffe ich ja, dass sich irgendein Programm beschwert, dass es zu wenig Speicher hat. Hieß es früher auch nicht mal, dass man ab 4GB Arbeitsspeicher keine swap benötigt?
 
Danke, da werde ich mal einen Blick drauf werfen.
Interessant wäre ja wirklich eine Auswertung dessen wenn nichts mehr geht, wer nutzt die CPU/ HDD so intensiv?
Kann es irgendwie am Chipsatz liegen? Oder dass ich eine AM3-CPU "nur" mit DDR2 verwende?
 
Ich werde langsam das Gefühl nicht los, dass es doch irgendwie mit der Platte zusammenhängt. So quasi intensive Schreibzugriffe und Rechner tot.
 
Ich habe die Diskussion nur überflogen, hatte aber auch ein Performance-Problem, mit 11.4 und kde 4.6.x. Es läuft alles viel schneller, seit ich für meinen »Hauptuser« den Ordner ~/.kde4 umbenannt habe. KDE hat den Ordner neu angelegt und seither geht's flotter.

Rüberkopiert nach dem ersten kurzen Start habe ich kwallet oder meine kmail-Einstellungen.

Je nach den von Dir verwendeten Programmen müssen noch andere Dateien mit umziehen, also vorher genau überlegen.

Gruß,
Alexander
 
Hallo,

das wird mir nicht helfen - die Installation war frisch und somit auch alle Einstellungen.

Gruß,

Sven
 
Oben