Hallo, Am Thu, 22 Jan 2015, Thomas Michalka schrieb:
Am 20.01.2015 um 23:11 schrieb David Haller:
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.
*hehe*
[...]
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.
Genau. Und ich hab hier z.B. einige Schwergewichte (akonadi/nepomuk/redland/bla) gar nicht erst installiert bzw. nur die jew. libbla.so ohne die die Programme nicht starten.
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 [..] Wobei 'wmaker' läuft eigentlich nur einmal ...
Wieso dann zwei Prozesse?
Das frag ich mich auch schon lange, aber bisher nicht interessiert genug da mal zu kruschteln.
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)...
Achso, nur nochmal zum Vergleich: Startzeiten (jew. via "startx" also inkl. XFree/Xorg, was beim Einloggen vom *dm ja schon laufen würde, *seltsam: ldd `which kdm` listet nichtmal qt-libs?*): WMaker KDE3 KDE4 XFCE Athlon 500 ca. 5s 30-45s ?? ?? [1] Ath II X2 250 ca. 5s 20-30s? >45s ca. 15s [2] [1] 32bit, XFree 3.3.6, von div. IDE HDDs (mehrere zwischen 80-500GB), u.U. zuletzt auch schon ne SATA HDD [2] 64bit, Xorg 7.6/1.10, erst ne 1TB SATA?, dann Samsung 830 SSD Zeiten von WMaker sind "gemessene" Obergrenzen, KDE/XFCE geschätzt.
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).
==== /usr/src/linux/Documentation/sysctl/vm.txt ==== ============================================================== drop_caches Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free. To free pagecache: echo 1 > /proc/sys/vm/drop_caches To free dentries and inodes: echo 2 > /proc/sys/vm/drop_caches To free pagecache, dentries and inodes: echo 3 > /proc/sys/vm/drop_caches As this is a non-destructive operation and dirty objects are not freeable, the user should run `sync' first. ============================================================== Ggfs. auch noch in /usr/src/linux/Documentation/cgroups/memory.txt und blkio-controller.txt reingucken. # free total used free shared buffers cached Mem: 4053224 3891980 161244 0 63760 2030224 -/+ buffers/cache: 1797996 2255228 Swap: 6287056 101228 6185828 # sync # echo 3 >/proc/sys/vm/drop_caches # free total used free shared buffers cached Mem: 4053224 1957392 2095832 0 12176 148060 -/+ buffers/cache: 1797156 2256068 Swap: 6287056 101228 6185828 Naja, nicht perfekt, aber (achso, ich hatt' grad noch das swapfile drin, wg. JDK kompilieren).
[...]
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.
Genau :) Wobei: Java hab ich "Auf Rost", nicht in ner RAM-Disk kompiliert, die VM braucht allein schon knapp 12 GB Plattenplatz bis das Teil durch ist... Normal hab ich halt ne RAM-Disk über's Verzeichnis drübergemountet, so muß ich nix an der Config drehen. Für Java also: # umount /data/build $ osc build java-1.9.0-openjdk.spec ... [..] # cd /data/build # rm -rf openSUSE... # cd; mount /data/build
Apropos VM: reicht meine CPU (Typ s. nächster Abs.) und 8 GB RAM eigentlich dafür?
RAM hab ich hier ja wie du oben siehst nur 4G + 2G Swap (+4G swapfile zur Not), und deine CPU ist IMO nicht relevant langsamer als meine. Wenn vmplayer trant, dann rödelt auch immer die HDD. Liegt also eher nicht an der CPU. Mit anderen VMs hab ich keine Erfahrungen (VBox angetestet, kein Grafiktreiber für W95, (S?)VGA ist zuwenig, ich will hauptsächlich uralt Spiele/Programme verwenden, ergo: fiel raus).
Und mit welcher VM-SW (möglichst Linux-eigen) lässt sich eine VM am einfachsten aufsetzen (oS 13.1)?
vmplayer oder virtualbox, wobei virtualbox keine Grafiktreiber für Win95 hat (und u.a. das will ich eben wirrtualisieren, s.o. ;) 'build' (und somit 'osc build') verwendet ne ausgefuchte Variante von 'chroot' bzw. OBS auf den eigentlichen Build-Servern nutzt KVM. Die "linux"-nativen sind aber AFAIR alle nicht ganz einfach zu konfigurieren, es gibt aber auch ne GUI (virt-manager, jep, s.u.), wie das funktioniert weiß ich aber nicht. Guck dir mal (die Abhängigkeiten) von 'yast2-docker' und 'yast2-vm' an ... Bzw.: http://software.opensuse.org/search?q=virt- und http://software.opensuse.org/package/virt-manager (und ob die yast2-* was taugen ;)
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 :-)
*g* Beobachte aber deinen '177 Wear_Leveling_Count' in den Smart-Daten... Ich bin schon bei minimaler Benutzung seit ~Juli 2012 hier angekommen: ID# ATTRIBUTE_NAME VALUE WORST THRESH RAW_VALUE 177 Wear_Leveling_Count 099 099 000 33 ==== http://www.samsung.com/global/business/semiconductor/minisite/SSD/us/html/wh... ==== ID # 177 Wear Leveling Count This attribute represents the number of media program and erase operations (the number of times a block has been erased). This value is directly related to the lifetime of the SSD. The raw value of this attribute shows the total count of P/E Cycles. ==== Lt. u.a. http://www.anandtech.com/show/6459/samsung-ssd-840-testing-the-endurance-of-... sollte die 830 (MLC) schon so ca. 3k Zyklen aushalten, wenn ich da erst bei 33 bin? Hossa! Klar, is noch alles im grünen Bereich, aber ich schreib halt im normal-Betrieb fast nix auf die SSD. Hm. Ich glaub fast, ich kann die SSD dann doch ein bissl mehr einspannen :) Ich dachte zuletzt eher "RAW is ca. % 'verbraucht'", obwohl ich obiges garantiert schonmal gelesen hatte. Naja, man wird nicht jünger ;)
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
Äh, 2.8 oder 2.7 GHz jetzt? Frach mal: grep 'MHz' /proc/cpuinfo (wobei auf mind. einem der Kerne auch Last anliegen sollte, damit die CPU nicht schläft ;)
[...] 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 Liste scheint mir *arg* konfus... Bin jetzt aber zu Faul die c't Benchmarks rauszusuchen.
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.
CPUMark AMD Athlon 64 X2 Dual Core 5600+ 1464 AMD Athlon II X2 250 1766 Also rein MHz mäßig '3000/2800*1464 = 1568.6'. Das "II" bringt dann also doch 12.5% extra Wumms :) Im Passmark CPUmark.
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).
Ich öffne nur sehr selten mehr als vielleicht 10 Tabs (Wikipedia graben). Teste doch mal, die Tabs auf mehrere Fenster aufzuteilen. Oder auch mehrere Instanzen (das wird dann schon wieder nervig). Aber generell: wenn sich das auf "Schließen + neu öffnen und alles ist wie vorher" ausgeht wie hier zumindest, dann wäre das für mich kein Problem, das all paar Stunden zu machen.
Kann man eigentlich mal eben schnell alle (also global, nicht nur für die angezeigte Seite bzw. Domain) JSs mit NoScript verbieten?
Nein, aber mit der JS-Checkbox von Prefbar :) Prefbar ist das _erste_ Addin was ich installiere, erst danach NoScript und AdBlock Edge. Bei Prefbar hab ich inzwischen auch einige eigene Checkboxen/Buttons um z.B. etwas in about:config mal eben umzustellen, dazu mußt du nur aus about:config/prefs.js den "Prefstring" raussuchen, z.B. für's globale JS ist das 'javascript.enabled' und kannst dann ganz einfach ne Checkbox dafür im Prefbar anlegen :) Die für JS gibt's aber schon mitgeliefert :)
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.
Prefbar hat auch eine 'JS-Tab' Checkbox, die ist aber intern im JS der Erweiterung implementiert 'prefbarSetTabJavascript(value)'. Evtl. könnte man da noch was basteln ;) HTH, -dnh -- \date\everyjob\protect\leavevmode\lower\body\insert\active\fill\eject\relax \bye -- a (La)TeXies view of sex [thanks to: R.Zierke] -- 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