Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
Autor |
Nachricht |
Westbeam
Anmeldungsdatum: 22.12.2009 Beiträge: 760
|
Verfasst am: 25.04.2011, 16:21 Titel: [Linux] "hald" -11% CPU-Last ? |
|
|
Hi
Da sich bei mir WINE aufgehangen hatte, habe ich es über Systemverwaltung/Systemüberwachung/Prozesse beendet. Dabei ist mir folgendes bei den Prozessen aufgefallen:
http://www.imagebanana.com/view/uorfyf4i/screenshot_014.png
Wie kann ein Prozess -11% CPU benötigen? Das verstehe ich nicht. |
|
Nach oben |
|
|
MilkFreeze
Anmeldungsdatum: 22.04.2011 Beiträge: 116
|
Verfasst am: 25.04.2011, 16:31 Titel: Re: [Linux] "hald" -11% CPU-Last ? |
|
|
Westbeam hat Folgendes geschrieben: | Hi
Da sich bei mir WINE aufgehangen hatte, habe ich es über Systemverwaltung/Systemüberwachung/Prozesse beendet. Dabei ist mir folgendes bei den Prozessen aufgefallen:
http://www.imagebanana.com/view/uorfyf4i/screenshot_014.png
Wie kann ein Prozess -11% CPU benötigen? Das verstehe ich nicht. |
hald ist der Hardware Abstraction Layer Daemon. Der kann auch gern mal etwas mehr Leistung für sich beanspruchen. Warum da eine negative Prozent-Zahl bei rum kommt, kann ich mir nicht erklären. Wenn du das nochmal hast, überprüf mal die Werte mit einem anderem Programm. "htop" liefert eigentlich immer richtige Werte.
Ansonsten wende dich an den Bugtracker deiner Distribution oder an das jeweilige Projekt (ich denke mal GNOME). _________________ Milch ftw |
|
Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009 Beiträge: 760
|
Verfasst am: 25.04.2011, 16:50 Titel: |
|
|
Was hald ist, weiß ich auch, aber trotzdem danke für die Erklärung.
Bei htop kommt -10% CPU-Last raus, aber dennoch eine negative Zahl. Ist ein wenig seltsam, denn ich denke ja nicht, dass mir "hald" 10-11% mehr CPU-Leistung gibt. |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 25.04.2011, 18:47 Titel: |
|
|
Wenn ich ein Programm beende, nimmt es durchaus mal eine kurze Zeit lang 200% des Prozessors in Anspruch. Der Grund liegt wohl an der Berechnungsroutine; die genaue Prozessorlast lässt sich bei dem zugrunde liegenden Konzept nämlich afaik gar nicht exakt bestimmen, sondern muss "geschätzt" bzw. aus den Werten über einen gewissen Zeitraum hinweg berechnet werden. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009 Beiträge: 760
|
Verfasst am: 25.04.2011, 19:03 Titel: |
|
|
Du hat Folgendes geschrieben: | sondern muss "geschätzt" werden |
Ja, aber wie können dabei negative Zahlen rauskommen? |
|
Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007 Beiträge: 4597 Wohnort: ~/
|
Verfasst am: 25.04.2011, 20:06 Titel: |
|
|
Naja, so, wie halt bei einer Berechnung negative Werte heraus kommen können.
Um dir die Frage zu beantworten, fehlen mir die genaueren Kenntnisse der internen Abläufe. Ich könnte mir zum Beispiel vorstellen, dass in außergewöhnlichen Situationen - Prozessorlast steigt kurzfristig extrem an oder sinkt extrem ab - die Berechnung, die unter "Normalbedingungen" gut brauchbare Werte liefert, nun rein rechnerisch auf sinnlos erscheinende Werte kommt. Mal ganz abgesehen von der Möglichkeit von Fehlern in der Berechnungsformel (auch wenn ich davon zunächst einmal nicht ausgehe, aber kann ja sein).
Laut Google ist dein Rechner auf jeden Fall nicht der einzige, bei dem so etwas passiert. _________________ Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
Nach oben |
|
|
MilkFreeze
Anmeldungsdatum: 22.04.2011 Beiträge: 116
|
Verfasst am: 25.04.2011, 22:47 Titel: |
|
|
Westbeam hat Folgendes geschrieben: | Was hald ist, weiß ich auch, aber trotzdem danke für die Erklärung. |
Ups. Tut mir leid
Westbeam hat Folgendes geschrieben: | Bei htop kommt -10% CPU-Last raus, aber dennoch eine negative Zahl. Ist ein wenig seltsam, denn ich denke ja nicht, dass mir "hald" 10-11% mehr CPU-Leistung gibt. |
Hast du einen Prozessor der sich automatisch hoch- beziehungsweise runtertaktet? Vielleicht kommt deswegen eine so merkwürdige Zahl bei rum. Ich kann aber auch nur Mutmaßen.
Nützlich zu wissen wäre: Distribution, Version des Kernels, Version von HAL, verwendete Desktop-Umgebung + Version
nemored hat Folgendes geschrieben: | Mal ganz abgesehen von der Möglichkeit von Fehlern in der Berechnungsformel (auch wenn ich davon zunächst einmal nicht ausgehe, aber kann ja sein). |
Könnte durchaus ein Bug im Kernel sein. Der kümmert sich ja bekanntlich um /proc/. Und die Berechnung der CPU-Belastung basiert meines Wissens auf den Informationen aus /proc/. Ich hab zum Glück kein HAL mehr, kann also nicht überprüfen ob der Fehler auch bei mir auftritt. _________________ Milch ftw |
|
Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009 Beiträge: 760
|
Verfasst am: 25.04.2011, 23:03 Titel: |
|
|
Nein, kein Automatisch hoch/runter-taktender Prozessor.
Ich verwende Arch Linux mit dem Kernel 2.6.32-31-generic und der GNOME-GUI 2.30.2. HAL benutze ich in der Version 0.5.14
Was benutzt du denn anstelle von HAL? |
|
Nach oben |
|
|
MilkFreeze
Anmeldungsdatum: 22.04.2011 Beiträge: 116
|
Verfasst am: 26.04.2011, 00:50 Titel: |
|
|
Hat es einen Grund warum du so einen alten Kernel benutzt? Aktuell ist doch 2.6.38.4 (glaube ich).
Ich hab HAL deinstalliert. FAM hatte ich sowieso nie, weil thunar auch mit gamin umgehen kann. Und was genau jetzt für Automount sorgt kann ich dir nicht sagen, aber ich meine das macht udev. Gnome3, KDE4.6 und XFCE 4.6 kommen ohne HAL aus, wenn ich das gerade richtig im Gedächtnis habe.
HAL war lange Zeit einer großen Anzahl von Nutzern ein Dorn im Auge. Genauso wie FAM und DBUS. Warum genau kann ich dir nicht sagen. Aber FAM und HAL werden definitiv aussterben...
Zurück zum Problem: Versuchs mit einen Kernel-Update wenns dich stört. Wenn dich das nicht stört und es zu keinen weiteren Fehlern kommt: Kümmer dich nicht weiter drum, wenns dich interessiert kannst du ja immer mal wieder die Bugtracker durchforsten. _________________ Milch ftw |
|
Nach oben |
|
|
Westbeam
Anmeldungsdatum: 22.12.2009 Beiträge: 760
|
Verfasst am: 26.04.2011, 10:33 Titel: |
|
|
Oh tatsächlich, es ist ein neuer Kernel draußen. Ich war eine Woche im Urlaub und hab das wohl verpasst, habe nun ein Update gemacht.
Geändert hat dies aber nichts.
Aber eigentlich stört es mich auch nicht. Ich habe mich nur einfach gewundert, wie ein Prozess -11% CPU verbrauchen kann. |
|
Nach oben |
|
|
Manuel
Anmeldungsdatum: 23.10.2004 Beiträge: 1271 Wohnort: Bayern
|
Verfasst am: 28.04.2011, 15:08 Titel: |
|
|
MilkFreeze hat Folgendes geschrieben: | Hat es einen Grund warum du so einen alten Kernel benutzt? Aktuell ist doch 2.6.38.4 (glaube ich). | Unter Arch gibts ja auch noch den LTS-Kernel (kernel26-lts), der meines Wissens gerade auf 2.6.32.xx basiert. Als "Reißleine" durchaus sinnvoll. Man weiß ja nie, ob das aktuellste kernel26-Package nach einem Update einwandfrei mit der Hardware zusammenarbeitet^^... Zitat: | HAL war lange Zeit einer großen Anzahl von Nutzern ein Dorn im Auge. Genauso wie FAM und DBUS. Warum genau kann ich dir nicht sagen. | Großteils deshalb, weil es XML-Dateien für die Config verwendet und dem elitären Trend, Configs einfach und schnell über Textdateien zu bearbeiten, im Weg stand *g* . Nein, ernsthaft, XML-Dateien über einen Editor ohne Syntaxhighlighting zu arbeiten, ist tatsächlich grausam^^. Außerdem benötigte HAL lange Zeit PolicyKit, was wiederum neben noch mehr XML-Files auch mal eben 30 Jahre User- und Gruppenverwaltung von Linux über Bord wirft und bei dem kleinsten Fehler in irgendeiner der ~12 im System verstreuten Configs jegliche Userberechtigung, die Policykit voraussetzt, sofort dichtmacht. Viel Spaß, ohne Policykit mit z.B. Gnome zu arbeiten - da darf man nichtmal den Rechner herunterfahren, und jegliche Admintools verweigern per se den Dienst, ohne auch nur nach irgendeinem Passwort zu fragen...
Ist gerade bei Basteldistros wie Gentoo oder eben Arch extrem ärgerlich. Bis man da irgendeinen Fehler findet, ist man schneller dran mit Neuinstallieren - fast so wie bei Windows... Zitat: | Hast du einen Prozessor der sich automatisch hoch- beziehungsweise runtertaktet? | Wäre nicht ungewöhnlich; ist bei meinem Laptop genauso... _________________ DL Walk (Denkspiel) | DL Malek (Denkspiel) | DL Warrior (ASCII-Adventure) | DL Sokodos (Sokoban-Klon)
---
www.astorek.de.vu |
|
Nach oben |
|
|
MilkFreeze
Anmeldungsdatum: 22.04.2011 Beiträge: 116
|
Verfasst am: 29.04.2011, 13:25 Titel: |
|
|
Manuel hat Folgendes geschrieben: | Ist gerade bei Basteldistros wie Gentoo oder eben Arch extrem ärgerlich. Bis man da irgendeinen Fehler findet, ist man schneller dran mit Neuinstallieren - fast so wie bei Windows... |
Das kann ich so nicht bestätigen. Ich habe einmal erleben müssen das Hardware bei dem neuen Kernel streikt. Dann habe ich meine Arch-Installations-CD rausgeholt und den Kernel mit chroot und pacman auf die alte version gebracht. Alles Neuinstallieren musste ich noch nie - mit einer Live-CD kann ich im Normalfall alles installieren. Und seit einem Unfall beim Configurieren habe ich immer ein Grml in reichweite.
Manuel hat Folgendes geschrieben: | Zitat: | Hast du einen Prozessor der sich automatisch hoch- beziehungsweise runtertaktet? | Wäre nicht ungewöhnlich; ist bei meinem Laptop genauso... |
Ist bei meinem Ebenfalls so, deswegen habe ich gefragt. Meine Idee war folgende: Durch das Ändern der Taktung wird auch die verfügbare Rechenzeit geändert. Die beanpruchte Rechenzeit bleibt und bevor sich die Werte "angleichen" gibt es merkwürdige Zahlen für die CPU-Belastung.
P.S.: Grml ist ein geniales Werkzeug, wenn ein Linux repariert werden muss! _________________ Milch ftw |
|
Nach oben |
|
|
Manuel
Anmeldungsdatum: 23.10.2004 Beiträge: 1271 Wohnort: Bayern
|
Verfasst am: 29.04.2011, 13:46 Titel: |
|
|
MilkFreeze hat Folgendes geschrieben: | Manuel hat Folgendes geschrieben: | Ist gerade bei Basteldistros wie Gentoo oder eben Arch extrem ärgerlich. Bis man da irgendeinen Fehler findet, ist man schneller dran mit Neuinstallieren - fast so wie bei Windows... |
Das kann ich so nicht bestätigen. | Das Ganze war auf HAL und davon abgeleitet auf PolicyKit bezogen, nicht auf "Basteldistros" ansich . Ich hatte leider schon öfters den Fall, dass eine Neuinstallation von z.B. Arch und Gnome mir Letzteres ums Verrecken nichts erlaubt hatte, obwohl ich keinerlei Config-Datei von PolicyKit oder HAL angerührt hatte, die Symptome aber 100% darauf hindeuteten. Nach zig fehlgeschlagenen Versuchen das zu beheben, habe ich irgendwann frustriert aufgegeben und nochmal neu installiert - und plötzlich lief alles reibungslos, obwohl ich mMn. absolut garnichts anders gemacht habe als beim letzten Mal... Zitat: | P.S.: Grml ist ein geniales Werkzeug, wenn ein Linux repariert werden muss! | Dito. Grml habe ich immer als "Linux-Rettungs-CD" dabei, wirklich eine sehr gute und praktische Distro _________________ DL Walk (Denkspiel) | DL Malek (Denkspiel) | DL Warrior (ASCII-Adventure) | DL Sokodos (Sokoban-Klon)
---
www.astorek.de.vu |
|
Nach oben |
|
|
|