[gelöst] Alle 10 Sek. verzögerte Ausgabe

Anfänger

21.11.2006, 17:28

Hallo alle miteinander,

seit dem letzten größeren Update vor ca. 2 Wochen habe ich folgendes Problem:
periodisch - im 10-Sekunden-Takt - nimmt meine Kubuntu-Installation (Dapper Drake) Maus- und Tastatureingaben nur verzögert an. Wenn ich z.B. mit der Maus im Browser-Fenster scrolle, dann setzt für ein, zwei Sekunden der Scroll-Vorgang aus und danach abrupt wieder ein, sodass jedesmal der Fensterinhalt springt. Genauso nervt mich die verzögerte Tastatureingabe: teilweise habe ich bereits zwei Worte geschrieben, bevor die Ausgabe im Fenster erscheint. Weil ich beim Schreiben auf den Monitor schaue, komme ich bei der verzögerten Ausgabe aus dem Takt und verschreibe ich mich regelmäßig...
Vielleicht stelle ich mich auch nur an - aber bis vor zwei Wochen lief Kubuntu monatelang ohne diese Schwierigkeiten und ich möchte diesen Zustand gern wieder herstellen. Außerdem finde ich es generell blöd, wenn der Computer Dinge macht, die ich nicht verstehe. :böse:

Eine Vermutung ist, dass ein Prozess (Logging/Journaling) auf die Festplatten (drei Stück SATA eingebaut) zugreift und vielleicht den Bus blockiert. Allerdings sollte SATA doch autonom laufen, also entkoppelt von PS2 oder USB, oder irre ich mich da? :keineahnung:

Eine andere Vermutung ist, dass irgendein Prozess periodisch Hot-Plug-Geräte sucht und dabei PS2- und USB-Geräte blockiert.

Ich poste mal die Datei /var/log/kern.log mit den Festplatten-Schreibzugriffen:

Quellcode

Nov 21 15:57:03 neo4linux kernel: [4312199.774000] kjournald(2204): WRITE block 12731088 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.774000] kjournald(2204): WRITE block 12788672 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.774000] kjournald(2204): WRITE block 9764976 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105120 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105128 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105136 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105144 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105152 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105160 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105168 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105176 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105184 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105192 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105200 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105208 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105216 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105224 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105232 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.775000] kjournald(2204): WRITE block 105240 on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.801000] syslogd(5628): dirtied inode 780567 (syslog) on sdc2
Nov 21 15:57:03 neo4linux last message repeated 2 times
Nov 21 15:57:03 neo4linux kernel: [4312199.801000] syslogd(5628): dirtied inode 781234 (kern.log) on sdc2
Nov 21 15:57:03 neo4linux last message repeated 2 times
Nov 21 15:57:03 neo4linux kernel: [4312199.801000] syslogd(5628): dirtied inode 781055 (debug) on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.801000] syslogd(5628): dirtied inode 781055 (debug) on sdc2
Nov 21 15:57:03 neo4linux kernel: [4312199.802000] syslogd(5628): dirtied inode 781055 (debug) on sdc2
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 82608632 on sdc6
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 4888 on sdc6
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 4896 on sdc6
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 4904 on sdc6
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 25584 on sdc5
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 25592 on sdc5
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 25600 on sdc5
Nov 21 15:57:07 neo4linux kernel: [4312203.581000] pdflush(168): WRITE block 25608 on sdc5
Nov 21 15:57:07 neo4linux kernel: [4312203.681000] reiserfs/0(3874): WRITE block 110887928 on sdc6
Nov 21 15:57:07 neo4linux kernel: [4312203.681000] reiserfs/0(3874): WRITE block 262176 on sdc5
Nov 21 15:57:07 neo4linux kernel: [4312203.681000] reiserfs/0(3874): WRITE block 262184 on sdc5
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 12994944 on sdc2
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 12830320 on sdc2
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 12830472 on sdc2
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 13140264 on sdc2
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 12878104 on sdc2
Nov 21 15:57:08 neo4linux kernel: [4312204.780000] kjournald(2204): WRITE block 12879256 on sdc2

Hier ist noch die Kopie von Top:

Quellcode

Tasks:  96 total,   2 running,  94 sleeping,   0 stopped,   0 zombie
Cpu(s):  7.6% us,  0.7% sy,  0.0% ni, 91.7% id,  0.0% wa,  0.0% hi,  0.0% si
Mem:   1036096k total,   798464k used,   237632k free,   123320k buffers
Swap:  1060272k total,        0k used,  1060272k free,   472080k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 5073 user      15   0 35460  19m  14m S  5.3  2.0   6:29.13 kicker
 4553 root      15   0  174m  26m 3964 S  1.3  2.6  22:43.00 Xorg
 7022 user      16   0 34064  17m  12m R  0.3  1.7   0:02.58 konsole
 7130 user      16   0  2200 1116  856 R  0.3  0.1   0:00.42 top
    1 root      16   0  1564  528  460 S  0.0  0.1   0:01.10 init
    2 root      34  19     0    0    0 S  0.0  0.0   0:00.00 ksoftirqd/0
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.00 watchdog/0
    4 root      10  -5     0    0    0 S  0.0  0.0   0:00.18 events/0
    5 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khelper
    6 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kthread
    8 root      10  -5     0    0    0 S  0.0  0.0   0:00.29 kblockd/0
    9 root      20  -5     0    0    0 S  0.0  0.0   0:00.00 kacpid
  167 root      20   0     0    0    0 S  0.0  0.0   0:00.00 pdflush
  168 root      15   0     0    0    0 S  0.0  0.0   0:00.53 pdflush
  170 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 aio/0
  169 root      25   0     0    0    0 S  0.0  0.0   0:00.00 kswapd0
  765 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 kseriod
 1793 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 ata/0
 1794 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 ata_hotplug/0
 1797 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_0
 1798 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_1
 1804 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_2
 1805 root      11  -5     0    0    0 S  0.0  0.0   0:00.00 scsi_eh_3
 1984 root      10  -5     0    0    0 S  0.0  0.0   0:00.00 khubd
 2204 root      15   0     0    0    0 S  0.0  0.0   0:00.09 kjournald
 2457 root      12  -4  2440  928  368 S  0.0  0.1   0:00.26 udevd
 3319 root      20   0     0    0    0 S  0.0  0.0   0:00.00 shpchpd_event
 3870 root      16   0     0    0    0 S  0.0  0.0   0:00.00 kjournald
 3874 root      10  -5     0    0    0 S  0.0  0.0   0:00.02 reiserfs/0
 3881 root      15   0     0    0    0 S  0.0  0.0   0:00.00 kjournald
 3882 root      15   0     0    0    0 S  0.0  0.0   0:00.00 kjournald
 4406 root      16   0  2156 1192  644 S  0.0  0.1   0:00.00 acpid
 4519 root      16   0  1684  496  412 S  0.0  0.0   0:00.21 dd
 4521 klog      15   0  2424 1352  388 S  0.0  0.1   0:00.10 klogd
 4533 root      16   0  2744  628  504 S  0.0  0.1   0:00.00 kdm
 4554 root      17   0  3676 1356 1088 S  0.0  0.1   0:00.00 kdm
 4561 hplip     15   0 12872  916  696 S  0.0  0.1   0:00.00 hpiod
 4564 hplip     15   0  9408 4676 1104 S  0.0  0.5   0:00.01 python
 4637 messageb  16   0  2196  832  672 S  0.0  0.1   0:00.22 dbus-daemon
 4652 haldaemo  16   0  6940 5516 1536 S  0.0  0.5   0:01.50 hald
 4653 root      16   0  2720  984  836 S  0.0  0.1   0:00.04 hald-runner
 4659 haldaemo  17   0  2004  792  696 S  0.0  0.1   0:00.00 hald-addon-acpi
 4713 haldaemo  15   0  2004  792  692 S  0.0  0.1   0:00.02 hald-addon-keyb
 4720 haldaemo  17   0  2008  900  792 S  0.0  0.1   0:00.96 hald-addon-stor
 4721 haldaemo  16   0  2008  904  792 S  0.0  0.1   0:01.40 hald-addon-stor
 4773 root      21   5  1556  264  192 S  0.0  0.0   0:00.34 powernowd
 4812 root      19   0  1968  708  616 S  0.0  0.1   0:00.00 hcid
 4818 root      20   0  1616  456  384 S  0.0  0.0   0:00.00 sdpd
 4827 root      10 -10     0    0    0 S  0.0  0.0   0:00.00 krfcommd
 4840 root      16   0  1624  296  232 S  0.0  0.0   0:00.00 mdadm
 4874 daemon    16   0  1804  400  296 S  0.0  0.0   0:00.00 atd
 4887 root      16   0  2116  840  684 S  0.0  0.1   0:00.00 cron

In den Systemeinstellungen werden folgende Dienste als aktiviert ausgegeben (siehe auch Top):
atd, cron, cupsys, dbus, kdm, klogd, mdadm, sysklogd

Ich bin erst seit ca. 6 Monaten Linux-User und stoße hier an die Grenzen meines Wissens. Bisher konnte ich alles "Lebensnotwendige" in den Foren lesen; nur zu diesem Problem habe ich nichts Hilfreiches gefunden, was mich weiterbringen könnte.
Ich würde mich freuen, wenn jemand eine Idee hat, wie dieses nervige Problem zu lösen ist.
Vielleicht hast Du ja dasselbe Problem schon gelöst und kannst hier dazu ein paar Tipps posten.
Danke!

Gruß,
Lordofacid

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

2

21.11.2006, 18:16

Konnte leider den obigen Beitrag nicht mehr editieren.

Jetzt bin ich wirklich genervt: habe eben zum ersten Mal wieder Kaffeine gestartet und alle 10 Sekunden friert das Bild ein! http://www.linux-web.de/images/linuxblue/smilies/boesert.gif
Scheint also nicht nur etwas mit dem PS2- oder USB-Anschlüssen zu tun zu haben. Muss ein generelles Problem sein. Nun bin ich vollends ratlos. http://www.linux-web.de/images/linuxblue…es/verwirrt.gif
Was kann das sein nur sein?
Vielen Dank für Deine Hilfe im Voraus!

Gruß,
lordofacid

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

3

21.11.2006, 21:24

das logging des kjournald blockiert doch dein system total, da wird ja jeder block-schreibzugriff mitgeloggt. das das system da nicht aus dem knick kommt ist doch vollkommen klar.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

4

21.11.2006, 22:25

Danke für die Antwort.
/sdc2 (Root-Partition) ist mit ext3 formatiert. Vielleicht sollte ich das Aktualisierungsintervall (20 Sek.?) etwas erhöhen - werd's morgen ausprobieren, weil ich nicht rebooten möchte. Das Journaling möchte ich aber nicht komplett deaktivieren.

Allerdings verstehe ich nicht, warum ich bis vor zwei Wochen noch keine Probleme mit der Verzögerung hatte. Gut, der Kernel ist aktualisiert worden, daran wird es wahrscheinlich liegen. Leider weiß ich nicht, was sich geändert hat. Da fehlt's mir dann halt doch an Wissen.

Gibt es eine Möglichkeit (außer das Commit-Intervall zu verlängern), die die Schreibzugriffe verringert?

Gruß,
Michael

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

5

22.11.2006, 11:36

Keine Veränderung

Habe, wie gestern geschrieben, das Commit-Intervall auf 60 Sek. in der fstab erhöht. Außerdem habe ich die zwei ext3-Partitionen meiner Suse-Distro auskommentiert, so dass nur noch die Kubuntu Boot- und Root-Partition gemountet werden und daher auch nur noch zwei kjournal-Daemonen gestartet werden.

Aber: keine Veränderung! Stoisch alle 10 Sekunden wird das System blockiert. Jetzt bin ich komplett ratlos...
Anscheinend liegt der Fehler anderswo - bloß wo? Oder kann ich das Commit-Intervall nicht einfach in die fstab eingeben? Gibt es da vielleicht ein Kernel-Override, das eine höhere Priorität hat, als der fstab-Eintrag?
Hm, weiß nicht weiter...

Vorsichtshalber poste ich mal meine fstab:

Quellcode

# /etc/fstab: static file system information.
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
proc            /proc           proc    defaults        0       0
/dev/sdc2       /               ext3    defaults,commit=60,errors=remount-ro 0       1
/dev/sdc1       /boot           ext3    defaults,commit=60        0       2
/dev/sdc6       /home           reiserfs defaults        0       2
/dev/sda1       /media/sda1     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
/dev/sda5       /media/sda5     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
/dev/sda6       /media/sda6     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
/dev/sda7       /media/sda7     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
/dev/sda8       /media/sda8     ntfs    defaults,nls=utf8,umask=007,gid=46 0       1
#/dev/sdb1       /media/sdb1     ext3    defaults        0       2
#/dev/sdb2       /media/sdb2     ext3    defaults        0       2
/dev/sdb5       /media/sdb5     reiserfs defaults        0       2
/dev/sdc5       /tmp            reiserfs defaults        0       2
/dev/sdb3       none            swap    sw              0       0
/dev/sdc3       none            swap    sw              0       0
/dev/hda        /media/cdrom0   udf,iso9660 user,noauto     0       0

Wer hat eine Idee? Bin über jeden Versuch dankbar.

Gruß,
Lordofacid

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

6

22.11.2006, 12:04

RE: Keine Veränderung

also das commit intervall würde ich auf 5sekunden (standard) lassen, das ist ein guter kompromiss oder gibt es für das hohe commit einen wichtigen grund?
was mich irritiert, sind die ständigen logging-meldungen, das bremmst das system doch total aus!

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

7

22.11.2006, 12:22

Danke für Deine schnelle Antwort.
Ja, das Commit-Intervall habe ich auf 60 Sek. hochgestellt, weil ich geglaubt habe, dass dann das System seltener blockiert, weil der Logging-Zugriff seltener stattfindet - dann hätte ich den "Übeltäter" tatsächlich entlarvt. Doch das System hängt nach wie vor alle 10 Sekunden.

Was ich nicht verstehe: wenn das Standard-Commit auf 5 Sekunden eingestellt ist (wie's im kern.log angezeigt wird) und dann auch die Schreibzugriffe stattfinden, wieso friert das System dann alle 10 und nicht alle 5 Sekunden ein? Das wäre eigentlich logisch - zumindest für mich und meine bescheidenen Computerkenntnisse. :keineahnung:

Gruß,
Lordofacid

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 12:25)

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

8

22.11.2006, 13:20

So, jetzt habe ich alle unbenötigten Linux-Partition in der fstab auskommentiert - ohne Erfolg... :'(

Alle pdflush, reiserfs/0 und kjournald greifen in 5-Sekunden-Intervallen auf die Partitionen /sdc2, /sdc5 und /sdc6 zu...
...und das System hängt noch immer alle 10 Sekunden.

Jetzt sind nur halb so viele Partitionen gemountet, wie vor zwei Wochen - und da gab's noch keine Probleme.
Habe so langsam das Gefühl, an der falschen Stelle zu suchen. Deshalb ein letzter Versuch: werde gleich das System ohne Journaling starten - mal schauen, was passieren wird...

Gruß,
Lordofacid

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 13:21)

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

9

22.11.2006, 13:27

mach mal ein fscheck, in der oberen liste wurden einige dateisystemfehler gelistet. loggst du immer noch jeden schreibzugriff mit? wozu ist das logging jedes block-schreib-zugriffs gut, was sol das? das ist doch so, als wenn du einen brief schreibst und auf der rückseite des blattes nach jedem buchstaben auf schreibst "ich habe jetzt den buchstaben ... geschrieben!" da kommst du auch nicht aus dem knick.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

10

22.11.2006, 13:34

Nein, ich logge nicht jeden Schreibzugriff mit. Das kern.log ist wieder deaktiviert. Hatte ich nur zur Fehlersuche aktiviert. fscheck werde ich gleich mal laufen lassen (mit touch beim Reboot).
Bin gespannt, was es bringen wird...

Gruß,
Lordofacid

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

11

22.11.2006, 14:21

FS überprüft

Hab' alle Partitionen mit fsck von einer Live-CD aus überprüft. Alles in Ordnung - aber das System hakt noch immer. :teufel:

Jetzt bleibt mir wohl nur noch übrig, dass Journaling zu deaktivieren - mal schauen, wie das funktioniert...

Gruß,
Lordofacid

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

12

22.11.2006, 14:33

...Partitionen mit noatime gemountet - keine Veränderung. :böse:

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

13

22.11.2006, 15:16

Neuer Versuch

Bevor ich zu Kubuntu gekommen bin, hatte ich Suse 10.0 installiert. Diese Installation befindet sich noch immer auf meinem Rechner. Von dieser Distro aus poste ich jetzt. Die fstab ist fast identisch (Boot- und Root-Partition mit ext3 und die Home-Partition mit reiserfs formatiert.) mit der von Kubuntu, nur dass Suse auf /sdb und Kubuntu auf /sdc liegt. Hier bei Suse gibt es keine Probleme mit irgendwelchen Blockaden. Allerdings möchte ich doch gern bei Kubuntu bleiben, die Registrierungspolitik von Suse gefällt mir nicht...

Meiner Meinung nach hat das Journaling nichts mit den Freezes zu tun. Denn dann müssten sie auch hier auftreten. Zumindest glaube ich das.

Was kann das nur sein? :keineahnung:

Gruß,
Lordofacid

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

14

22.11.2006, 15:40

RE: Neuer Versuch

ja, auch im glaube, dass das journaling nichts mit dem einfrieren zu tun hat.
ok,
was sagt denn top so generell im load average?

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

15

22.11.2006, 15:46

Unter Suse 10.0 (zum Vergleich):
load average: 0.07, 0.14, 0.14

Kubuntu folgt gleich nach dem Reboot.

Gruß,
Lordofacid

PS.
Und hier die aktuelle Load unter Kubuntu:
load average: 1.19, 0.74, 0.30

Ist ungewöhnlich hoch. Sie liegt sonst unter 0.2...
Xorg frisst die meisten Ressourcen.

Gruß,
Lordofacid

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 15:54)

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

16

22.11.2006, 15:59

...alles zurück:
load average: 0.02, 0.35, 0.27

Pendelt sich jetzt viel niedriger ein. Die hohen Werte lagen wohl am Reboot - wahrscheinlich wurden noch einige Prozesse gestartet. Laut Desktopanzeige liegt sie jetzt zwischen 0.15 und 0.3 mit fallender Tendenz.

Gruß,
Lordofacid

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 16:00)

Zum Seitenanfang

linuxerr

Prof. Dr. Schlaumeier

Beiträge: 8 557

Wohnort: Mecklenburg, zur Entwicklungshilfe in Chemnitz/Sachsen ;-)

17

22.11.2006, 16:02

beobachte das mal eine weile, aber diese werte sind mehr als ok. jedenfalls ist die prozesskette nicht blockiert. wenn da mehrere prozesse in wartestellung gehen müssten, sollten die werte deutlich höher liegen.

Die Rechtschreibfehler in diesem Beitrag sind nicht urheberrechtlich geschützt.
Jeder der einen findet darf ihn behalten und in eigenen Werken weiterverwenden.

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

18

22.11.2006, 16:11

Ja, das meine ich auch.
Verstehe einfach nicht, welcher Prozess einen solchen Performance-Hunger haben könnte.

Gruß,
Lordofacid

PS.
Das Einzige, das ich am Computer verändert habe, ist die Grafikkarte. Eine GeForce 6600GT. Besitze ich zwar schon seit über anderthalb Jahren. War aber zwischenzeitlich wegen Lüfterschaden sechs Wochen lang in Reparatur. Stattdessen hatte ich eine alte Hercules Terminator eingebaut...
Vor der Reparatur der GeForce, hatte ich aber keine Probleme. Gut, mit der Hercules konnte ich keine hochwertigen Grafikanwendungen (z.B. Kaffeine) laufen lassen.
Könnte das vielleicht...?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 16:15)

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

19

22.11.2006, 16:22

Sorry, ist Blödsinn: habe die GeForce vor dem Update zurückbekommen. Und bis dahin funktionierte ja alles problemlos. Daran kann's also nicht liegen.

Gruß,
Lordofacid

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »lordofacid« (22.11.2006, 16:23)

Zum Seitenanfang

lordofacid

Anfänger

Beiträge: 18

20

22.11.2006, 16:44

Oh, oh, ich glaube ich hab's.
Wenn das stimmt, ist es mir unglaublich peinlich: hab' mal tuxkart installiert, um glx zu überprüfen und die Konsole gibt aus, dass keine glx extension vorhanden ist...
Das heißt also, dass ich es wohl nicht installiert habe, ich *&%*#&$.
Werd's gleich mal aktivieren.

Gruß,
Der DAU

Zum Seitenanfang