FreeBSD & Performance - Ein Vergleich

Status
Für weitere Antworten geschlossen.
Ich denke die Fine-grained Locks kommen öfter vor und sind dafür kürzer. Dann muss es bei einer Mischung ja knallen, weil sich Fine-grained und Giant gegenseitig blockieren. Dann wäre ja zu hoffen, dass die Probleme zusammen mit Giant verschwinden.
 
Dann stellt sich aber doch die Frage, warum sich das auf mancher Hardware drastisch auswirkt und bei anderen Systemen fast garnicht?
 
Ja, der Ausbau von Hardware hat das Problem in keinster Weise beeinflußt. Ich schiebe das Problem nach wie vor dem Chipsatz bzw. dem ATA-Treiber zu.
 
Ich hatte ähnliches Problem mal mit dem nve-Nick. Ein dauerhafter ping gegen eine andere Maschine half da, das Problem ist allerdings schon längere Zeit gefixt. Steve, was ist das nochmal genau für eine Kiste? Ich finds grad nicht, die Threads sind so ewig lang...

[EDIT] Erledigt, grad gefunden, erste Message im Thema...
 
Vincent Vega schrieb:
Wenn man so drüber nachdenkt, sind die hier im Thread beschriebenen Probleme ja eigentlich auch keine Probleme mit der "Performance" sondern mit "Interaktivität".

Wenn die Maus ruckelt, die Musik hängt oder das TV Bild mehr wie eine Serie von Einzelbildern erscheint, denkt man sofort, der Rechner sei überlastet und deshalb langsam. Ob der Rechner aber eigentlich trotzdem noch in der Lage wäre, mehr Arbeit z.B. in Form eines Web- oder Datenbank-Servers oder eines reinen Rechenjobs (also etwas wofür man Maus/Musik/TV nicht braucht) zu verrichten wird man ja erstmal nicht überprüfen.
Zum Vergrößern anklicken....

Das ist so generell nicht zu sehen, mit diesem Argument sind fast alle Hinweise betroffener Benutzer in der ML abgefertigt worden!

Sobald Last auf irgendeinem SATA Device ist, schnellt der Ping bei aktiven Verbindungen hoch, stockt die Terminalausgabe (tty), bleibt die Tatstureingabe hängen. Wenn zufällig auf einer solchen 'X11-headless'
Maschine auch noch Soundausgabe gemacht wird, stockt auch diese. Wie gesagt, das sind Erfahrungen an Servern mit AMD Dualcores auf TYAN Boards mit je 4 oder 8 GB RAM und eigentlich schnellen CPUs. Im Labor verwende ich einen Q6600 auf einem ASUS P5K Premium Board, 8GB RAM. Hier ähnliche Phänemonologie, allerdings wird dieses System auch mit X11 betrieben, wo sich das Hakeln dann doch stark bemerkbar macht. Allerdings dank schnellerer CPU nicht so arg wie auf den AMD Dualcores.
Dann sehe ich dieses Problem auf meinem AMD Singlecore auf Sockel 939 extrem, sobald mein RAID0 aktiv wird, geht für einige Millisekunden gar nichts mehr. Das hat sich derweil schon gebessert, aber es ist nach wie vor vorhanden.
Diese Probleme sehe ich erst seit Frühjahr letzten Jahres in dieser irrwitzigen Form. Zuvor arbeitete mein onboard nfe/nve problemlos mit USB und SATA Controller zusammen. Danach fing es dann an, daß mein ar0 RAID lahmte, dann setzte mit immer weiter fortschreitendem Entwicklungsstand des nfe-Treibers eine Inkompatibilität mit Shared IRQs (vor allem mit USB!) ein, die letztlich den nfe-Treiber ohne MSI/MSI-X Unterstützung (wie auf dem CK804 Chipsatz nun mal eben) unbrauchbar machten. Der ebenso vorhandene msk0-Adapter auf Marvell-Basis scheiterte aufgrund des unausgereiften Treibers und ist bis heute nicht stabil. Erst meine neue Intel-Karte hat viele Probleme gelöst.

Nach wie vor bin ich der Ansicht, daß die beobachtbaren Leistungseinbußen dann beobachtbar werden, wenn man Anzeigegeräte benutzt, die einem die Probleme im wahresten Sinne des Wortes vor Augen führen! Auf einem Rechner mit zwei separat betriebenen Platten am SATA COntroller sind die Probleme in etwas abgeschwächter Form beobachtbar, extrem wird es bei mir, wenn ich zwei Platten als RAID 0 zusammensetze und vom BIOS/Controller managen lasse. Wenn ich aus einem RAID 0 (2x 250 GB) auf eine 200 GB Platte unter ZFS Daten sichere, steht mein Rechner! Wenn ich auf selbigem Rechner make world beginne, steht der Rechner, wenn ich große Datenmengen kopiere, steht der Rechner. Der Q6600 Rechner hat kein RAID, ich benutze Platten unter ZFS und sehe im normalen Betrieb keine Störungen - bis zum Zeitpunkt, wenn ich ein make world mache oder 'find' die Platten absucht. Dann steht auch auf diesem System für eine Weile alles still. Auf den TTY-Servern darf man sich einer hängenden Console erfreuen. Und nun sage mir bitte keiner, daß das am USB liegen soll - denn der USB ist sinnvollerweise abgestellt und verbrät keinen wertvollen IRQ ...
 
Eisenfaust schrieb:
Sobald Last auf irgendeinem SATA Device ist, schnellt der Ping bei aktiven Verbindungen hoch, stockt die Terminalausgabe (tty), bleibt die Tatstureingabe hängen. Wenn zufällig auf einer solchen 'X11-headless'
Maschine auch noch Soundausgabe gemacht wird, stockt auch diese. Wie gesagt, das sind Erfahrungen an Servern mit AMD Dualcores auf TYAN Boards mit je 4 oder 8 GB RAM und eigentlich schnellen CPUs.
Zum Vergrößern anklicken....

Zur Eingrenzung, meine WS ist eines der Tyanboards mit zwei 252ern und nv Chipsatz, sowie nve NICs. Ich habe das Problem nicht und sehe zwei Unterschiede:

* Ich nutze nicht die SATA-Anschlüsse, sondern gehe über ein Escalade(PCIe)
* 32bit

Board ist ein S2895A2NRF
 
troll schrieb:
Zur Eingrenzung, meine WS ist eines der Tyanboards mit zwei 252ern und nv Chipsatz, sowie nve NICs. Ich habe das Problem nicht und sehe zwei Unterschiede:

* Ich nutze nicht die SATA-Anschlüsse, sondern gehe über ein Escalade(PCIe)
* 32bit

Board ist ein S2895A2NRF
Zum Vergrößern anklicken....

... damit habe ich schon zwei 'Probleme' ausgemacht. Zum einen haben zwei CPUs auch gleich zwei IOAPICs mit an Bord und somit potentiell ein paar IRQs mehr, die sie verteilen können, zum anderen bedient eine CPU den nF2200 und die andere den nF2020, um beide 16x PEGs effizient ansteuern zu können. Dadurch wird eine sehr großzügige Lastverteilung erreicht. Das zur physikalischen Seite. Die zweite Sache wäre das 32 Bit (System??), was auch immer. Ich käme nie auf die Idee, auf einer 64 Bit Maschine ein 32 Bit System zu installieren - ich vermeide es sogar jedwede 32 Bit Kompatibilität zu eleminieren, bis hin zum unsäglichen 32-Bit Linuxulator. Wenn FreeBSD 7 noch immer mit 64 Bit ein Problem haben sollte, dann weiß ich auch nicht mehr weiter, außer, daß es Zeit für ein Umdenken ist.
 
passwd.c Problematik

In diesem Thread hatte ich einmal angesprochen, daß es unter FreeBSD 6/7 nicht möglich ist, mit dem lokalen 'passwd' ein Paßwort auf einem LDAP Server (in meinem Falle OpenLDAP 2.3) zu ändern. Auf meiner Suche nach der Funktionsweise von passwd.c bin ich dann fündig geworden, die Beschwerden über das nichtfunktionierende passwd-Werkzeug des Kernsystems reichen nun schon zwei Jahre zurück. Seit ca. zwei Monaten patche ich auf allen mir zugänglichen FreeBSD 7.0-Maschinen 'passwd.c' mit einem Patch, den ich aus einem deutschen(!) Beitrag 'geklaut' habe. Dieser Patch ersetzt die unter nsswitch/PAM sowieso sinnlose Abfrage, ob die PW Anfrage nun von lokal oder via NIS kam.
Wenn man nun in /etc/pam.d/passwd das letzte 'required' in ein 'sufficient' umwandelt (warum auch immer, anders gehts leider nicht) und zuvor das Modul pam_ldap.so als Paßwort-Änderung einschiebt, kann ich bequem und problemlos lokale wie auch LDAP-gestützte Paßworte ändern. Problemlos!
Um dem Problem auch eine Nummer zu verpassen, habe ich sogar einen PR mit Patch-Anhängsel verfaßt - auf den ich bis heute keine Antwort habe. Impliziert doch, daß sich keiner mehr darum kümmert? Es impliziert weiter, daß die Revisorenstruktur nicht funktioniert und weiter, daß die Entwicklung stagniert, weil sich eine kleine Clique als Gralshüter sieht und nicht bemerkt, wie die Kronjuwelen durch Nager geraubt und geschädigt werden?
 

Anhänge

Vielleicht solltest ihr nicht Rumblubern wie schrottig FreeBSD doch ist, was euch nicht passt, was alles falsch ist, sondern bitte einmal die Realitäten sehen. In eurem eigenen Mailinglistenthread wurde eingestanden, dass ein Problem mit der Abarbeitung der PR gibt. Es wurden außerdem Lösungen vorgeschlagen und Mark Linimon wird Arbeit und Zeit investieren, um die Probleme zu beseitigen.

Also, warum macht ihr nicht das, was man zwischen den Zeilen lesen kann? Nehmt euer passwd-Problem - was ich immer noch nicht wirklich verstehe, aber vielleicht bin ich zu sehr Praktiker - und macht eine schöne Mail draus mit Patch und Begründung und Hinweis auf die PR. Die schickt ihr an freebsd-hackers@ oder freebsd-current@ -_-

Was die Performance-Probleme des VFS betrifft, wo wart ihr, als über Jahre(!) jemand gesucht wurde, der lockmgr() - der ist nämlich das Problem hierbei - umbaut? Es fand sich niemand. Nichts. Tja, nun macht Attlio Rao ist und ihr müsst bis 8.0 warten :P

Man kann nörgeln. Nörgeln fällt leicht. Man kann auch leicht sagen "diese dämlichen, dummen und hochmütigen Entwickler!". Nörgeln ist immer einfach. Aber bessermachen nicht. Ich lese jetzt hier seit 335 Beiträgen vor allem Genörgel. Wirklich konstruktiv war vielleicht ein Drittel davon. Investiert die Zeit lieber um Mailinglisten zu lesen. Diskutiert mit. Das bringt 15x mehr und hilft so manches Problem zu verstehen.
Außerdem, früher war nicht alles besser. 4.x Fehlerfrei? Stabiler alles alle andere? ROFL! Das wurde es erst, als es kaum noch MFC bekam, sondern nur Fehlerkorrekturen, zu einem Zeitpunkt als es schon fast hoffnungslos veraltet war. Panic hier, Bug dort. 3.x? Das hatte auch seine Macken. Ich sage nur Probleme mit SMP (na, kennen wir das nicht?) und grottenlahmer IP-Stack. 2.x hatte das kaputte VFS. In der Erinnerung wird nur alles besser.

Ich sag mal ehrlich, wenn hier nur immer über das gleiche genörgelt wird, dann geht zu eurem heiligen Linux und erkundet dessen teils auch ziemlich heftige Macken. Nörgel ist einfach, helfen viel schwerer und die Krönung. Letzteres ist Vorraussetzung bei Open Source.

Und ja, ich bin schlecht gelaunt!
 
Zuletzt bearbeitet:
Hallo Eisenfaust,

die Problematik kenne ich zur Genüge. Auch ich patche jedesmal nach einem Update alle Maschinen, damit passwd und LDAP wieder zusammenarbeiten.
Es gibt offensichtlich genug Patches in der Pipeline für die Problematik. Es kümmert niemanden.

Was solls
 
Um noch mal auf das Problem im Ausgangsposting zurückzukommen: Das Problem liegt in der Interrupt-Verarbeitung von FreeBSD seit Version 5. Interrupts werden seitdem in Threads abgearbeitet, um sie auf mehrere CPUs verteilen zu können.

Wenn Semi-Echtzeit-Hardware (TV-Karte, Soundkarte etc.) einen Interrupt-Request (IRQ) bei der CPU anmeldet, erwartet sie sofortige Reaktion (CPU unterbricht das, was sie gerade tut und wendet sich dem Interrupthandler im zuständigen Treiber zu). Bei FreeBSD wird jedoch nur der zuständige Thread beim Scheduler angemeldet, und dieser arbeitet ihn dann mal ab, wenn nichts zu tun hat (und kein Lock gerade irgendwo blockiert). Dadurch ist die Interruptlatenz (Zeitdauer von Request bis Abarbeitung) generell hoch. Das führt dann zu den im Startposting geschilderten Problemen und allgemein schlechter Performance.

Aber auch das Verhalten unter zu starker Interruptlast ist katastrophal. Während bei FreeBSD 4 das System immer noch geschmeidig (im ms-Bereich) reagiert, selbst wenn die CPU zu 100 % mit Abarbeiten von Interrupts beschäftigt ist (Beispiel Vollast auf GBit-Karte oder Drucken auf Parallelport), bleibt ein FreeBSD 5/6/7 einfach stehen, sobald die CPU-Ressourcen erschöpft sind.

Letzteres macht FreeBSD auch untauglich für den Servereinsatz. Ein notdürftiger Workaround dafür ist Polling, was aber nur in NIC-Treibern implementiert ist.

Da das ganze ein konzeptioneller Fehler ist, wird auch die beste Hardware draufwerfen nichts daran ändern. Da hilft nur Einsicht und ein Rewrite.
 
@Yamagi:
Hättest Du den Thread genauer gelesen, dann wüßtest Du jetzt, daß dies schon längst geschehen ist! Im übrigen darf man sich dieses Trauerspieles nun seit zwei Jahren erfreuen - inklusiver 'Threades', 'Mailingslisten', 'PR' inkl. Patch. Was soll man mehr tun (rhetorisch ... nicht vergessen).

@jtsn:
Merci für die Einsichtgebung in die Details. Welchen Vorteil sieht man mit dem ITHREAD Konzept? Wie machen es Linux oder Solaris? Wie löst NetBSD die IRQ Problematik in einer Multi-CPU Umgebung? Man sollte meinen NetBSD, als altgedientes System, das schon früh auf größeren Mehrprozessorsystemen zuhause war, sollte ein ausreichend 'erfahrungsstabiles' Konzept haben, oder? Partizipiert FreeBSD davon nicht?
 
[hohe Interruptlatenz und Verhalten unter zu starker Interruptlast]

Da das ganze ein konzeptioneller Fehler ist, wird auch die beste Hardware draufwerfen nichts daran ändern. Da hilft nur Einsicht und ein Rewrite.
Zum Vergrößern anklicken....

Wie werden diese Probleme denn unter Linux, DragonFly und Solaris gelöst? Und gibt's schon Lösungsansätze für FreeBSD?
 
juedan schrieb:
Es gibt offensichtlich genug Patches in der Pipeline für die Problematik. Es kümmert niemanden.
Zum Vergrößern anklicken....

Wie haben denn die zuständigen Entwickler auf Nachfragen per Mail geantwortet? Und wurde mal bei Core nachgefragt?

Dass PRs (auch solche mit Patches) "verrotten" kommt ja auch bei anderen Projekten oft genug vor. Ganz bestimmt auch bei Linux-Projekten.

Und was OpenBSD angeht, da hat Theo ganz klar gesagt, dass es das System der Entwickler ist, und das sonstige User keine Ansprüche zu stellen haben.

Gibt es denn überhaupt unabhängige nicht-kommerzielle Projekte, die sich durch sehr guten Umgang mit PRs, Submitter-Patches und durch gutes Qualitätsmanagement auszeichnen?
 
Moin Eisenfaust,

Merci für die Einsichtgebung in die Details. Welchen Vorteil sieht man mit dem ITHREAD Konzept?
Zum Vergrößern anklicken....
Threads haben den großen Vorteil, dass sie quasi-parallel abgearbeitet werden können. Damit sie sich nicht gegenseitig "ins Handwerk pfuschen" muß man geeigneter Stelle Mutex-Semaphoren setzen. Außerdem sind (sollten sein!) Threads kleine "Unterprogramme", die eine Aufgabe in möglichst kurzer Zeit erledigen.
Übertragen auf einen Kernel oder Treiber bedeutet das, man kann für jeden IRQ einen Thread erzeugen, der nur diesen einen IRQ bedient. Die Vorteile sind theoretisch, dass der IRQ bedient werden, während ein anderer IRQ abgearbeitet wird oder der Kernel anderes zu tun hat.

Um diese Thread-Geschichte zu implementieren gibt es mehrere Möglichkeiten (ich beziehe mich da auf OS/2-Zeiten, weil ich da am besten Bescheid weiß):
  • Ein Treiber erkennt seine Hardware und Resourcen-Belegung. Der Treiber installiert für den erkannten IRQ einen Thread statisch, der nur einmal am Scheduler angemeldet werden muß. Der Vorteil ist ganz klar, dass die Anmeldezeit nicht während der kritischen Phase durchgeführt werden muß und damit gewinnt man wertvolle Zeit.
    Man installiert bei dieser Methode einen kleinen IRQ-Handler, der nix anderes macht, als eine Semaphore auszulösen und die Endlos-Schleife im IRQ-Thread läuft einmal weiter.
  • Ein Thread wird dann installiert, wenn ein IRQ auftritt. Der Thread wertet die IRQ-Informationen aus und springt in den entsprechenden Treiber, der alles weitere abarbeitet. Der Vorteil ist der geringere Resourcenverbrauch, da Speicher nur dann belegt wird, wenn er wirklich benötigt wird. Der Nachteil ist ganz klar, dass mehr Zeit zwischen Auslösung des IRQs und Bedienen des IRQs vergeht. Wenn der Scheduler ausgelastet ist, dann muß der Thread eben warten. Man kann das setzen von Prioritäten abmildern: Maus/Tastatur niedrige Prio, HBAs hohe Prio.

Für beide Fälle gilt: Wenn ein Gerät große Datenmengen liefert, ist der Thread natürlich auch solange beschäftigt, ganz klar. Diesem Dilemma kann man auf zwei Arten begegnen. Entweder man ignoriert das, dann brauchen die Daten eben länger, bis sie im Speicher sind. Oder man ändert die Priorität dynamisch so, dass die der Thread mehr Rechenzeit bekommt und somit landen die Daten schneller im Speicher. Andere Threads bekommen dadurch zwangsläufig weniger Rechenzeit, dann "ruckelt" es eben.

Viele Grüße

JueDan
 
jtsn schrieb:
Wenn Semi-Echtzeit-Hardware (TV-Karte, Soundkarte etc.) einen Interrupt-Request (IRQ) bei der CPU anmeldet, erwartet sie sofortige Reaktion (CPU unterbricht das, was sie gerade tut und wendet sich dem Interrupthandler im zuständigen Treiber zu). Bei FreeBSD wird jedoch nur der zuständige Thread beim Scheduler angemeldet, und dieser arbeitet ihn dann mal ab, wenn nichts zu tun hat (und kein Lock gerade irgendwo blockiert). Dadurch ist die Interruptlatenz (Zeitdauer von Request bis Abarbeitung) generell hoch. Das führt dann zu den im Startposting geschilderten Problemen und allgemein schlechter Performance.
Zum Vergrößern anklicken....

Ein paar Korrekturen bzw. Ergänzungen.

Richtig ist: Interrupts werden in Interrupt Threads abgearbeitet, und zwar zum einen weil dann der Interrupt Thread blockieren kann während der Ausführung und zum andern weil man mehrere Threads gleichzeitig ausführen kann auf mehreren CPUs. Abgesehen davon gibt es weiterhin die "Fast Interrupts", welche ohne eigenen Interrupt Thread ausgeführt werden.

Nicht ganz richtig ist, dass Interrupt Threads beim Scheduler "nur angemeldet" werden, so dass sie irgendwann, wenn Zeit dafür ist, ausgeführt werden. Das stimmt so nicht ganz. Interrupt Threads haben höchste Priorität und damit sie zeitnah ausgeführt werden können, können auch andere Kernel-Threads unterbrochen werden ("Preemption").

Natürlich bleibt die Ausführung von ISRs trotzdem nicht-deterministisch. Das war aber schon immer so, und wird wohl auch noch eine ganze Zeit so bleiben. Schließlich ist FreeBSD kein Echtzeit-System.

Linux macht das mit den Interrupts übrigens genau so.
 
Gibt es denn überhaupt unabhängige nicht-kommerzielle Projekte, die sich durch sehr guten Umgang mit PRs, Submitter-Patches und durch gutes Qualitätsmanagement auszeichnen?
Zum Vergrößern anklicken....
An sich nicht. Es mag Projekte geben, die Patches schneller abarbeiten als FreeBSD, aber dort knallt es dann wieder an anderen Ecken, nicht selten an der Entwicklung neuen Codes oder der Integration neuerer Dinge. Jetztendlich heißt ein freies Projekt auch immer irgendwo Kompromisse, weil man wie gesagt einen Großteil oder sogar Entwickler nicht zwingen kann Dinge zu tun, die notwendig aber unangenehm sind.
Kommerzielle Entwickler können die unangenehmen Dinge befehlen, dafür lassen sie im Umkehrschluss aber im Zweifel Probleme offen und entscheiden sich für den Start eines nicht ausgereiften Produktes um Geld damit zu verdienen. Jetztendlich muss jeder für sich entscheiden, welches Konzept das bessere ist.
 
Vielleicht bin ich da oben in #336 ein wenig über das Ziel hinausgeschossen. Sollte ich damit jemanden auf die Füße getreten haben, tut es mir Leid :/
 
Eisenfaust schrieb:
... damit habe ich schon zwei 'Probleme' ausgemacht. Zum einen haben zwei CPUs auch gleich zwei IOAPICs mit an Bord und somit potentiell ein paar IRQs mehr, die sie verteilen können, zum anderen bedient eine CPU den nF2200 und die andere den nF2020, um beide 16x PEGs effizient ansteuern zu können. Dadurch wird eine sehr großzügige Lastverteilung erreicht.
Zum Vergrößern anklicken....

Ich werde dennoch mal eine Platte direkt an den SATA-Controller anschliessen und mein System draufkopieren. Übernächste Woche kommen eh Platten, da kann ich wohl irgendwann einen Test einschieben.

Das zur physikalischen Seite. Die zweite Sache wäre das 32 Bit (System??), was auch immer. Ich käme nie auf die Idee, auf einer 64 Bit Maschine ein 32 Bit System zu installieren.
Zum Vergrößern anklicken....

Wie gesagt, eine WS...
 
Moin,

diesen Test ( dd bs=1m < /dev/zero > tmpfile ) habe ich aus Neugierde mal auf meinem Server durchgeführt. Unter FreeBSD 5.5 konnte ich da nichts außergewöhliches feststellen, kein Mausruckeln, Fenster öffneten sich allerdings mit leichter Verzögerung, Programme benötigten beim Starten fast doppelt solange. Aber das dürfte am Giant-Locking liegen.

Hardware:
Dual P3 450MHz, Siemens-Board mit Intel 440GX-Chipsatz, 2GB ECC-RAM, Adaptec AHA-39160 (AIC-7899A) (Dual Channel), Adaptec ANA620xx/ANA69011A (Dual Port Ethernet 100MBit/s), Mylex DAC 1100 SCSI-RAID.

Sollte als Vergleich zu den guten alten Zeiten dienen:D

Viele Grüße

JueDan
 
Hatte damals schon bemerkt, dass dd mein System ausbremst. War aber nur der Fall, wenn ich per PCMCIA Adapter auf eine CF Karte (alles am Notebook) etwas geschrieben habe.

Hier mein Ergebnis zu dd bs=1m < /dev/zero > tmpfile unter Gnome. Musik hatte ich nebenbei gehört, die Lieder hatten dann immer so fünfsekündige Aussetzer.
Webseitenaufruf war wie damals mit Modem :D
 

Anhänge

Zuletzt bearbeitet:
Interessant wie einfach das geht:
Code: 
dd bs=1m if=/dev/zero of=tmpfile
705+0 records in
704+0 records out
738197504 bytes transferred in 48.550038 secs (15204880 bytes/sec)

Softupdates sind übrigens aus (das bringt schon erheblich was).

Code: 
last pid: 26634;  load averages:  0.68,  0.32,  0.12   up 17+06:20:23  16:57:46
16 processes:  2 running, 14 sleeping
CPU states:  0.8% user,  0.0% nice, 46.2% system,  2.5% interrupt, 50.4% idle
Mem: 72M Active, 331M Inact, 73M Wired, 21M Cache, 60M Buf, 992K Free
Swap: 1024M Total, 10M Used, 1014M Free, 1% Inuse

  PID USERNAME   THR PRI NICE   SIZE    RES STATE    TIME   WCPU COMMAND
26593 jtsn         1 107    0  3376K  1648K RUN      0:19 37.26% dd

Allein der Aufruf von top hat 15 Sekunden gebraucht. I/O-Scheduling?
 
Status
Für weitere Antworten geschlossen.
Zurück
Oben