Re: instabiler Browser

Hallo Heino,

Heino Tiedemann wrote:
> Mal was neues vom Firefox.
>
> Szenario 1:
>
> Firefox hat zwei tabs offen, im Seamonkey läuft ein youtibe video -
> [...]
> Es scheint, das für jeden EINZELNEN Tab ZWEI Prozesse gestartet
> werden. Und die sind gierrig. Hier sind es - für den Momanbt sogar
> noch drei..

Es liegt mir ja fern, Firefox zu verteidigen, aber wieviele
Prozesse ein Browser pro Tab startet, ist relativ gleichgültig.
Beispielsweise ist denkbar, dass ein Prozess fürs Rendern und
einer für I/O verwendet wird, und/oder ein separater Prozess
für client-side Skripte. Sandboxing-Mechanismen (unterstützt
Firefox sowas?) benötigen i. allg. auch mindestens einen
weiteren Prozess. Diese Aufteilung auf mehrere Prozesse oder
Threads hat auch den Vorteil, dass die Arbeit auf mehrere
CPU-Kerne verteilt werden kann. Moderne Prozessoren werden
dadurch also besser ausgenutzt.

Wieviel CPU solche Prozesse verbrauchen, hängt wiederum in
erheblichem Maße vom Inhalt der jeweiligen Webseite ab, nicht
so sehr vom Browser. Eine statische Webseite benötigt nahezu
null CPU, wohingegen eine Webseite, die in erheblichem Umfang
client-seitige Skripte ausführt, die CPU schon mal an den
Anschlag bringen kann. Allein schon, wenn eine Webseite
viel Werbung enthält (animierte Banner usw.), kann dies eine
deutliche Grundlast erzeugen. Bei Videos (Youtube oder andere)
hängt es auch von zahlreichen Variablen ab, z. B.: Wie ist der
Browser diesbezüglich konfiguriert? Wie ist Xorg konfiguriert?
Kann Hardware-Beschleunigung verwendet werden? Welche Formate
und Protokolle (HTML5, Flash, etwas Proprietäres) und welche
Codecs (h.264 a.k.a. AVC, h.265 a.k.a. HEVC, VPx, Theora, ...)
verwendet die Webseite? Und so weiter.

BTW: Tödlich für die Performance ist es auch, wenn man den
Browser nicht auf dem lokalen Display startet, sondern über
eine Remote-X-Verbindung. Das kann durchaus auch versehentlich
passieren, wenn man den Browser z. B. in einem Chroot oder
Jail startet, so dass er keinen direkten Zugriff auf den
lokalen X-Socket (via /tmp) hat und den Umweg über eine lokale
Netzwerkverbindung (localhost) gehen muss, möglicherweise
sogar mit Crypto-Overhead, wenn es durch ssh getunnelt wird.

> Was für eine Kacke diese Software doch ist :(

Das lasse ich mal unkommentiert stehen.

Ich habe mal testweise auf einer Kiste mit AMD Phenom-II X6
(ca. 8 Jahre alt) Chrome mit Youtube geöffnet; das sieht
nicht viel anders aus als bei Dir:

  PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
 1432 olli 16 20 0 809M 354M uwait 1 0:51 27.67% chrome
 1294 olli 6 24 0 410M 197M CPU5 3 0:29 10.21% chrome
 1290 olli 24 21 0 387M 170M select 3 0:17 6.61% chrome
  864 root 1 20 0 24674M 54244K select 1 0:27 1.43% Xorg
 1471 olli 1 20 0 7912K 3796K CPU2 0 0:00 0.07% top
 1341 olli 6 20 0 530M 134M uwait 5 0:00 0.03% chrome

Man beachte, dass die gewichtete WCPU-Angabe relativ zu einem
Kern ist. Da es sich um einen 6-Kern-Prozessor handelt, ist
der Rechner insgesamt immer noch zu ca. 95 Prozent idle.

Mit Hilfe von sockstat, lsof, ktrace u. a. sieht man ziemlich
rasch, dass der Prozess 1290 für Netzwerk-I/O zuständig ist,
Prozess 1294 kümmert sich um das Rendern, und 1432 führt
offenbar JavaScript in der Webseite aus (wovon YouTube ja
ausgiebig Gebrauch macht). Insgesamt ist das Ergebnis nicht
verwunderlich.

Wenn ich YouTube durch eine weitgehend statische Webseite
ersetze, z. B. de.wikipedia.org, geht die CPU-Nutzung fast auf
null herunter, wie zu erwarten:

  PID USERNAME THR PRI NICE SIZE RES STATE C TIME WCPU COMMAND
  864 root 1 20 0 24674M 54244K select 4 0:32 0.30% Xorg
 1648 olli 1 20 0 7912K 3812K CPU5 2 0:00 0.13% top
 1647 olli 16 20 0 687M 230M uwait 3 0:03 0.05% chrome
 1294 olli 6 20 0 402M 197M select 3 0:56 0.00% chrome
 1290 olli 28 20 0 413M 187M select 4 0:52 0.00% chrome
 1341 olli 6 20 0 531M 135M uwait 3 0:00 0.00% chrome

Ich nehme an, dass es sich bei Firefox genauso verhält.

Gruß
   Olli

-- 
Oliver Fromme, München   --   FreeBSD + DragonFly BSD
``We are all but compressed light'' - Albert Einstein
To Unsubscribe: send mail to majordomo(at)de.FreeBSD.org
with "unsubscribe de-bsd-questions" in the body of the message