Servus David, Am 20.01.2015 um 23:11 schrieb David Haller:
Hallo,
Am Mon, 19 Jan 2015, Thomas Michalka schrieb:
Am 19.01.2015 um 02:47 schrieb David Haller:
Am Sun, 18 Jan 2015, Jürgen Hochwald schrieb:
Bei dem Rechner handelt es sich um einen AMD Athlon 1200MHz mit 256Mb Speicher. Aktuell ist Suse 10.0 installiert.
Vergiss es. Und zwar nicht wg. der SuSE Version, sondern weil Webseiten heute ordentlich CPU-Wumms brauchen! BTDT. Ich hab auf meinem alten Hauptrechner teils 1min warten müssen, bis ne Webseite geladen war, und das nicht weil die Daten so langsam reinkamen, die CPU war die Minute konstant bei 100%...
[...]
Wie gesagt: moderne JS-verseuchte Seiten brauchen einfach mehr CPU-Wumms. Und auch ansonsten macht nen aktueller nicht-Atom Dualcore deutlich mehr Spaß.
Was verbraucht eigentlich den höheren Anteil am "CPU-Wumms", JS oder das reine Rendern, sprich der Aufbau der Seite im Browser-Fenster?
Nach meiner Erfahrung auf der ollen Kiste noch: eindeutig JS. Das Rendern ist selbst mit dem ollen Athlon 500 (der erste und langsamste Athlon überhaupt) nie ein (relevantes) Problem gewesen.
Jetzt auch noch mal an meiner alten Kiste probiert und bestätigt: mit NoScript und AdBlockplus sind sie meisten Seiten zwar unvollständig aber sauschnell gerendert.
[...]
Achso: und 4 GB RAM oder für KDE gern auch mehr natürlich :)
Meiner Erfahrung nach wird der KDE gern zu Unrecht verdächtigt. Wenn ich den KDE auf meiner _lahmen Uralt-Maschine_ nach dem Login frisch gestartet habe, sind erst 512 MB bis 750 MB RAM belegt, davon nicht mal nur User-Daten, sondern noch viel Cache. Selbst nach einer längeren Sitzung mit verschiedenen Programmen der KDE-Suite dauert es erheblich, bis mal Daten ausgelagert werden.
Doch doch, KDE ist ein Speicherfresser. Nur hinterfotzig unaufällig ;)
Klar, viele unauffällige, aber in der Summe schwergewichtige 'Dienstboten', die man nicht bewusst wahr nimmt ... und wohl meist auch nicht wirklich braucht.
Wenn ich dagegen einen Browser (egal, ob z.B. FF oder O) mit nur wenigen Seiten (max. 5 bis 10) in einer nicht mal langen Sitzung laufen habe, dann sind die 1 GB RAM schnell weit (> 1 GB im Swap) überfüllt.
Äh, ja, FF/Seamonkey sind auch Speicherfresser. Aber:
# ps -eo vsz,rss,cmd | { grep -i -e VSZ -e kde -e wmaker -e seamonkey ; } [irrelevante bash/sh gekürzt] VSZ RSS CMD 13740 844 xinit xterm wmaker -- [..] 50452 1220 /usr/bin/wmaker 71840 9824 /usr/bin/wmaker --for-real 130416 3504 kdeinit4: kdeinit4 Running... 168004 5448 kdeinit4: klauncher [kdeinit] --fd=8 210452 6272 kdeinit4: kded4 [kdeinit] 1398400 625956 /usr/lib64/seamonkey/seamonkey-bin # free total used free shared buffers cached Mem: 4053224 3849420 203804 0 151716 1580280 -/+ buffers/cache: 2117424 1935800 Swap: 2092756 7268 2085488 # uptime 22:18pm up 14:15, 11 users, load average: 0.17, 0.26, 0.30
Wobei 'wmaker' läuft eigentlich nur einmal ...
Wieso dann zwei Prozesse?
Achso, und hier läuft kein KDE sondern nur kaffeine ...
... dessen Speicherbedarf selber mit über 50 MB auch nicht gerade klein ist (habe nur mal die Differenz zweier free-Ausgaben vor und nach dem Start von kaffeine genommen; da bei mir der KDE-Desktop läuft, ist weniger dazugekommen als bei Dir -- wohl nur der reine Bedarf von kaffeine)
Selbst da zieht kdeinit also schon RAM ... Ich merk's aber im Vergleich, wenn ich mal statt WMaker XFCE oder KDE starte (egal ob in echt oder in ner VM)...
Werde ich demnächst mal ausprobieren. Wie kann man nach einem Logout den Speicher von allem leerfegen, was gerade beendet wurde? Ich frage, weil ich vorhin nach dem Beenden von kaffeine sogar mehr used memory hatte, als vorher (KDE braucht für das Beenden eines Prozesses scheinbar noch zusätzlich Speicher und der Code bleibt wohl erst mal im RAM-Cache, damit es beim nächsten Starten schneller geht).
[...]
Swap will man vermeiden. Swap hab ich hier nur als für wirklich unwichtiges (Stundenlang nicht angefasst) oder eben als "Bremse" falls der Speicher vollläuft so daß ich noch ne Chance habe, den Prozess abschießen bevor der OOM-Killer zuschlägt ... Wobei, ich hatte hier zuletzt auch ein paarmal den Fall, daß ich beim Kompilieren von Java massiv Speicher brauchte (ok, das lief primär in ner Vm in ner RAM-Disk (osc build ...) ;), da hab ich nochmal 4 GB "swapfile" (auf rotierendem Rost) reingehängt damit's durchlief :) Performance ging gut währenddessen :)
Dann wurde wohl nur ausgelagert, damit das neue Zeugs Platz hatte. Apropos VM: reicht meine CPU (Typ s. nächster Abs.) und 8 GB RAM eigentlich dafür? Und mit welcher VM-SW (möglichst Linux-eigen) lässt sich eine VM am einfachsten aufsetzen (oS 13.1)? Swap will ich auch vermeiden -- auch deshalb soll meine neue Maschine 16 GB RAM haben -- aber man erfährt mit SSD das erste Mal in der PC-Geschichte, dass ein Massenspeicher so schnell ist (durch Riesen-IO-Ops/sec, viel weniger die Transferrate!), dass selbst bei exorbitanter Swap-Belegung das System nicht nur 'irgendwie' bedienbar bleibt (zum Killen von Speicherfressern) sondern immer noch erträgliche Reaktionszeiten für das normale Arbeiten zeigt. Seit dem Einsatz der SSD kann man einen produktiven Arbeitstag locker zu Ende bringen, ohne dass man das System 'hätscheln' ;-) muss; das gibt einem viel zusätzliche Freiheit :-)
Auf meinem Dual-Core (Athlon 64 X2, 2,7 GHz) mit 8 GB RAM:
Athlon 64 X2 oder Athlon 64 II X2 (das ist nochmal nen guter Unterschied :) $ hwinfo | grep -e Athlon -e MHz [...] model name : AMD Athlon(tm) 64 X2 Dual Core Processor 5600+ cpu MHz : 2800.000 [...]
Der Unterschied ist laut http://www.cpubenchmark.net/cpu_list.php aber zwischen Athlon 64 X2 Dual Core 5600+ und Athlon 64 Dual Core 5600+ ^^ hier Die "II X2" sind die Typen mit den dreistelligen Zahlen dahinter (Ausnahmen, z.B. "II X2 4300e" und "II X2 B22" bestätigen die Regel). Einen "II X2 5600+" habe ich nicht gefunden.
Wenn man in einer längeren Sitzung in etlichen Browser-Fenstern bzw. sehr vielen Tabs Web-Seiten geöffnet hat, dann sehe man sich mal die Speicherauslastung an. Oder einige Office-Fenster. Sicher wird sich das je nach Nutzer unterscheiden, aber wenn ich mal mehrere Tage den Browser nicht schließe, scheint sich dessen Speicherbedarf quasi von selber ständig zu erhöhen, auch wenn kaum noch Seiten dazukommen. Schließt man dann einige Fenster mit etlichen Seiten, gibt z.B. der FF auch nicht sehr gerne Speicher wieder frei. Nicht selten füllt er dann 3 bis 5 GB.
Jo, die Browser sollte man ab und an neu starten. Bei FF/Seamonkey: installiere dir den Sessionmanager! http://sessionmanager.mozdev.org/
Habe ich. Das hilft schon enorm, aber vor allem scheint die Performance des FF-Code nicht gut mit der Anzahl der geladenen Seiten zu skalieren, weshalb man die Zahl möglichst niedrig halten sollte (was bei einer Recherche nicht immer einfach ist). Kann man eigentlich mal eben schnell alle (also global, nicht nur für die angezeigte Seite bzw. Domain) JSs mit NoScript verbieten? Eine gute Zusammenarbeit des FF mit dem WM könnte bringen, dass in Fenstern, die gerade nicht angezeigt werden, JS vom FF temporär gestoppt wird. Wenn immer nur die JSe der angezeigten Seite laufen würden, würde das eine Menge Perfomance-Gewinn des FF bringen. Gruß, Tom -- Um die Liste abzubestellen, schicken Sie eine Mail an: opensuse-de+unsubscribe@opensuse.org Um den Listen Administrator zu erreichen, schicken Sie eine Mail an: opensuse-de+owner@opensuse.org