Hallo Stefan (und die Gruppe wieder im CC), oh je, da habe ich mit dem Anekdotischen den Blick fürs Wesentliche verstellt ... Am Samstag, den 01.08.2020, 00:34 +0200 schrieb Stefan Ziegler:
Hallo Urs,
Gesendet: Freitag, 31. Juli 2020 um 07:53 Uhr von: "Urs Liska" < ul@openlilylib.org> Kommt beides in Frage. Grafische Programme erlauben einem ja manchmal einfach schon einen ganz intuitiven Zugang zu solchen Problemen. Aber irgendwie hätte ich auch jedesmal den Verdacht, dass das Tool selbst in die Gleichung eingreift.
ich habe hier beim mir top im Kommandozeilenfenster und die "Gnome Systemüberwachung als grafisches Tool. Bei Einschaltung der Webcam geht die CPU-Nutzung um einige Prozent hoch, aber nicht merklich. (4 Cores ohne laufende Kompilierung)
So, ich habe einmal die Webkonferenz im Browser aktiviert (also noch im lokalen Modus die Kamera an ohne echte Konferenz). Das Bild sieht unauffällig aus, der eine Peak ist beim *Ausschalten* der Kamera.
Eine Schwierigkeit ist, dass meine Probleme ja nicht wirklich reproduzierbar sind, sondern nur tendenziell auftreten, also im live- Betrieb, wenn ich meistens über den Tag verteilt immer mehr Anwendungen offen habe. Jetzt gerade bin ich sowieso zuhause ohne externe Monitore, echte Tests kann ich erst wieder Montag machen.
Wie würde ich am besten die Last einer laufenden Webcam beobachten?
Bei der ersten Analyse sollte man schon auf CPU und Hauptspeicherauslastung schauen. Erst wenn das nicht auffällig ist, kann man woanders suchen.
So, hier wäre meine Frage gewesen: Wie finde ich die Prozesse, die ich beobachten soll?Wie schon irgendwo gesagt, bin ich mir sicher, dass weder der Hauptspeicher noch die CPUs in Summe jemals vollaufen, das kann also das Problem nicht erklären. Es kann natürlich sein, dass ein Prozess nicht Multithreading-fähig ist, eine einzelne CPU blockiert und damit das Gesamtsystem irgendwie beeinträchtigt.
Auch eine Hardwareerweiterung macht ohne Analyse der Ursache nur wenig Sinn.
Ja, genau deswegen schreibe ich ja hier. Im Kontext meines ursprünglich angedachten und nun geänderten Nutzungsverhaltens hätte ich vielleicht ohne nähere Prüfung eine dedizierte Grafikkarte installiert. Da das aber nicht geht, muss ich wohl etwas tiefer einsteigen.
Die Auslastung der Grafikkarte kann man mit den üblichen Systemwerkzeugen schlecht anzeigen. Ich würde es auch bei drei Monitoren weniger auf die Grafikkarte schieben. Die Grafikkarte hat keine Auswirkung auf Webcams oder Kompiler. Wenn das Kompilieren länger dauert, dann kann das eigentlich nur die CPU oder irgendeine Art IO-Durchfluss sein.
Kann man zumindest ein Teil der Kompilierung auf einen anderen Rechner ("Compute Server") auslagern, wenn diese so zeitkritisch ist? 6 Cores sind gut. Wieviel Cores bekommen die Kompiler normalerweise und wieviel bei Webcam-Nutzung? Wie schwankt die CPU-Auslastung bei den beiden Fällen mit/ohne Webcam? Wenn du 10 Cores für Lilypond nutzt (also 10 Hyperthreading, oder 5 Real-Cores), dann bleibt nur ein 1 Real-Core für den ganzen Rest von Webcam, grafische Oberfläche, Browser usw. übrig. Das fühlt sich natürlich zäh an. Sehr wahrscheinlich wird es weniger zäh, wenn du 2 Real-Cores für den Rest übrig lässt und nur 8 HT-Cores für Lilypond nutzt.
So, hier habe ich dich offensichtlich völlig abgelenkt.Die Konstruktion mit dem parallelen Kompilieren ist gar nicht das Problem. Wenn ich 10 Cores für Kompilieren nutze, ist klar, dass der Rest des Systems träge wird. Der Punkt *daran* ist eigentlich nur, dass ich es cool finde, dass es überhaupt möglich ist. Ohne meine JobQueue würde ich ja Tausende von Prozessen starten und das OS damit "alleine lassen" - und das führte erwartungsgemäß dazu, dass alles völlig überlastet wird.D.h. wenn ich diesen Vorgang starte, dann erwarte ich nicht, dass mein Rechner noch flüssig läuft, und das mache ich auch nur ganz gelegentlich, und bestimmt nicht parallel zu einer Videkonferenz. Mein praktisches Problem ist, dass, während Videkonferenzen laufen oder ich in Kdenlive mit Videos arbeite, mein Desktop insgesamt oft träge wird, und zwar oft in einem Maß, das das flüssige Arbeiten (also mal nebenher eine LibreOffice-Instanz zu öffnen oder etwas in einem Web- Interface zu machen) merklich behindert. Die Beobachtung, dass in diesem Zustand auch Compiler deutlich mehr Zeit brauchen, ist nur eine Zusatzinfo und hat mit dem aktuellen Use Case nicht wirklich zu tun. Manchmal nutze ich das, indem ich während der VK Dokumente mit LaTeX kompiliere, aber das ist nicht das Wesentliche. Herzliche Grüße Urs
Viele Grüße, Stefan.
Hallo Urs, hallo Liste!
Am 01.08.20 um 08:13 schrieb Urs Liska:
So, hier wäre meine Frage gewesen: Wie finde ich die Prozesse, die ich beobachten soll? Wie schon irgendwo gesagt, bin ich mir sicher, dass weder der Hauptspeicher noch die CPUs in Summe jemals vollaufen, das kann also das Problem nicht erklären. Es kann natürlich sein, dass ein Prozess nicht Multithreading-fähig ist, eine einzelne CPU blockiert und damit das Gesamtsystem irgendwie beeinträchtigt.
Hast Du schon mal versucht, die parallel (im Hintergrund) laufenden Prozesse mittels ionice und nice zu zähmen? Wenn Du im Hintergrund kompilierst sollte das bei entsprechendem nice-Level egal sein ob Du 10 oder 100 Prozesse startest, wenn Du genug RAM hast. Die nicht "gedrosselten" Andwendungen im Vordergrund sollten sich trotzdem normal bedienen lassen.
Mein praktisches Problem ist, dass, während Videkonferenzen laufen oder ich in Kdenlive mit Videos arbeite, mein Desktop insgesamt oft träge wird, und zwar oft in einem Maß, das das flüssige Arbeiten (also mal nebenher eine LibreOffice-Instanz zu öffnen oder etwas in einem Web-Interface zu machen) merklich behindert. Die Beobachtung, dass in diesem Zustand auch Compiler deutlich mehr Zeit brauchen, ist nur eine Zusatzinfo und hat mit dem aktuellen Use Case nicht wirklich zu tun. Manchmal nutze ich das, indem ich während der VK Dokumente mit LaTeX kompiliere, aber das ist nicht das Wesentliche.
Tritt Dein Problem auf, wenn Du per Webbrowser an einer Videokonferenz teilnimmst und gleichzeitig ein Webinterface bedienst? Dann würde ich versuchen, das Problem zu reproduzieren und dann das Webinterface in einer anderen Browserinstanz (zur Sicherheit in einem anderen Browser) zu öffnen und erneut zu versuchen ob das System lahmt. - Ich habe das Gefühl, daß trotz ständiger Verbesserung der Browser das Multithreading in der Browser- oder Javascript-Engine das Problem ist.
Viele Grüße, Christian
Hallo Urs,
So, hier wäre meine Frage gewesen: Wie finde ich die Prozesse, die ich beobachten soll? Wie schon irgendwo gesagt, bin ich mir sicher, dass weder der Hauptspeicher noch die CPUs in Summe jemals vollaufen, das kann also das Problem nicht erklären. Es kann natürlich sein, dass ein Prozess nicht Multithreading-fähig ist, eine einzelne CPU blockiert und damit das Gesamtsystem irgendwie beeinträchtigt.
Viele Prozesse sind nicht multithreading-fähig. Das ist oft auch nicht nötig. Die Prozesse bekommen eine "Zeitscheibe" auf einem Kern der CPU und können in der Zeit rechnen. Welcher Kern das ist, ist den meisten Programmen egal. Danach der nächste. Je mehr Prozesse da sind, desto kleiner/weniger werden die Zeitscheiben pro Prozess. Je nach nice-Wert u.a. Angaben wird die Zuteilung der Zeitscheiben geregelt. Laufende Videokonferenzen brauchen eine gewisse Last/Leistung von CPU und RAM. Programmen wie Skype kann man gut eine Priorität/nice-Wert zuweisen, einem Browsertab schlechter. Viele Grüße, Stefan.
-
Christian Fröhlich -
Stefan Ziegler -
Urs Liska