cpu usage: wie prozesspriorität hochsetzen um idle time auszunutzen?

M

milius.net

tail -f /var/log/nerd
hallo,
hab hier seit stunden 3 tars laufen die verschiedene ordner komprimieren - und mir dauert das viel zu lange :)
wie kann man die ganze sache anschieben?
hab's mit renice -20 pid versucht aber top zeigt immer noch:

Code: 
last pid: 45336;  load averages:  0.15,  0.10,  0.08                up 9+21:34:12  09:16:29
183 processes: 1 running, 182 sleeping
CPU states:  4.3% user,  0.0% nice,  1.9% system,  0.4% interrupt, 93.4% idle
Mem: 312M Active, 69M Inact, 86M Wired, 17M Cache, 59M Buf, 972K Free
Swap: 2048M Total, 334M Used, 1714M Free, 16% Inuse, 24K In

90% idle time? muss das sein?
 
Hallo,

mit renice könnte man das schon tun, der "Flaschenhals" Datendurchsatz wird damit jedoch nicht wirklich beseitigt. Wenn Du so viel File I/O Aktivität hast durch die Sicherung in TARs und es Dir schlicht zu lange dauert bleibt nur den Datenspeicher physikalisch anzupassen bzw. das System physikalisch selbst. D.h. Platten zu verbauen mit mehr Datendurchsatz und entsprechenden Controller dafür verwenden wo schlicht gesagt einfach mehr Daten fließen können in kürzerer Zeit. Der Arbeitsspeicher sollte natürlich für den Einsatzzweck entsprechend groß dimensioniert sein.

So wie es aussieht "klemmts" bei Dir einfach nur am Datenstrom selbst und zu wenig RAM. Die CPU scheint hier nicht das Problem zu sein.

Gruß Bummibaer
 
Zuletzt bearbeitet:
ich weiss genau was du meinst - allerdings müsste dann doch viel mehr los sein auf dem rechner als das hier:

Code: 
cp# iostat
      tty             ad0              md0             cpu
 tin tout  KB/t tps  MB/s   KB/t tps  MB/s  us ni sy in id
   0   18  0.00   0  0.00   0.00   0  0.00   5  0  3  1 91

cp# vmstat
 procs      memory      page                    disks     faults      cpu
 r b w     avm    fre  flt  re  pi  po  fr  sr ad0 md0   in   sy  cs us sy id
 0 35 0 2769360  21020  518   1   2   1 919 706   0   0  369 4556 348  5  4 91

oder?


ach und ich sehe gerade:
die tar.gzs laufen in einem screen - müssen dann alle prozesse hochgesetzt werden?
Code: 
        |-screen(90213)---tar(90214)---gzip(90215)
        |-screen(88796)---tar(88797)---gzip(88798)
        |-screen(88672)---tar(88673)---gzip(88675)
 
Zuletzt bearbeitet:
Also, um erst einmal etwas grundsätzliches klarzustellen: FreeBSD hat in beiden Schedulern, also SCHED_4BSD und SCHED_ULE einen Ansatz, der versucht die Welt realistisch zu sehen. Oder anders gesagt, wer viel Rechenleistung braucht, wird vollautomatisch gegenüber kleineren Prozessen mit weniger Ansprüchen bevorzugt. Dies steht im Gegensatz zu Linux, welches in aktuellen Kernelversionen versucht alle Prozesse erst einmal gleich zu betrachten. Prinzipbedingt hat unter FreeBSD das nice(1) Kommando eine deutlich geringere - bis gar keine - Auswirkung als unter Linux.
Jeff Roberson, welcher den aktuellen SCHED_ULE geschrieben hat, schriebt dazu:
I generally dislike nice. I really only see utility in using nice +20 as a pseudo idle priority thing. In most cases users are not going to change tunables and static allocations are almost never going to scale properly. This is the same reason I argued against any kind of threshold/watermark based memory allocation schemes. I favor adaptive algorithms wherever possible.

The ULE algorithm is simple, efficient, and has few edge cases where it's not likely to do what you want. It has some tunables available via sysctl but I consider those more for development experiments than for users. However, if the interactivity algorithm isn't doing what you want, you can disable it with a sysctl and use static nice values.

The only really inconvenient edge case is when the task you'd like to be interactive is a cpu hog and you have a number of other cpu hogs running. However, the scheduler is not omnipotent. In this case tricks like boosting the priority of foreground windowing applications are reasonable but we fortunately have not had to resort to that

Quelle: http://jeffr-tech.livejournal.com/15171.html?thread=133187#t133187
Zum Vergrößern anklicken....

Aber wie dem auch sei, deine Probleme liegen woanders. Siehe den Post von Bummibär oben, es fehlt dir an IO-Durchsatz. Ich tippe auf die Platten und eventuell deren Controller :)
 
Warum startest du die tars nicht nacheinander. Einfach mit ; aneinander hängen.

Das sollte viel schneller gehen.
 
@ yamagi
Oder anders gesagt, wer viel Rechenleistung braucht, wird vollautomatisch gegenüber kleineren Prozessen mit weniger Ansprüchen bevorzugt.
Zum Vergrößern anklicken....
ja, das klappt ja auch ganz gut - im normalen (automatisierten hintergrund-) ablauf hab ich dagegen auch nichts einzuwenden. es sollte allerdings die möglchkeit geben einem prozess kurzzeitig die volle (restliche / idle) cpu-power zuweisen zu können um ihn zu beschleunigen. nach dieser möglichkeit suche ich. kennst du sie?
unter windows geht das mit taskinfo

ach übrigens:
wenn ich deine signatur befolge und beide shift-tasten (gleichzeit) benutze funktionieren bei mir folgende buchstaben nicht: q f y x b o p h k ö m :D ist das bei dir auch so? auf diesem rechner ist winxp ...


@ kamikaze: coole idee! da hätte ich mal gleich dran denken sollen, das bringt bestimmt etwas ...
 
Zuletzt bearbeitet:
Du kannst keinem Prozess 100% zuweisen, was deine Situation betrifft. Dein System ist zu 93.4% idle. All diese tollen Sachen wie nice(1), automatische Leistungsverteilung und so weiter greifen erst, wenn mehrere Prozesse parallel laufen, die zusammen mehr als 100% konsumieren wollen. Das ist hier allerdings gar nicht der Fall, dein System hat noch freie Ressourcen ohne Ende. Egal was du dort an Prioritäten gibst, es wird nichts ändern, da sich im Moment gar keine Prozesse ins Gehege kommen, welche untereinder die Rechenleistung nach Prioritäten auf sich verteilt bekommen müssen. Du kannst die automatische Lastverteilung, welche nice(1) weitgehend ignoriert, per Sysctl abschalten. Aber frage mich nun nicht, welches das ist, da ich leider gerade kein FreeBSD zur Verfügung habe :/
 
ja, ihr habt natürlich recht - bei mir ist der rechner idle - lastenverteilung bringt da rein gar nichts...
flaschenhals muss also hd oder controller sein ...

letzte fragen:
1. dma für die hd ist im bios gesetzt - wie finde ich heraus ob es auch genutzt wird? kernel?
2. und: wie kann man das dateisystem optimieren? noatime und nodiratime deaktivieren?
3. und was könnte das bringen?
 
Zuletzt bearbeitet:
Hast du die Prozesse serialisiert?

Das was du vorschlägst ist nicht zielführend. Wenn du den Durchsatz wirklich steigern willst, reicht es nicht, ein paar Knöpfe zu drücken, sondern du musst das System grundlegend umgestalten. Wenn ich sehe, dass 16% des Swaps benutzt werden, gerade geswapped wird und dann über fehlende Performance geklagt wird, die CPU leerläuft und dann am Prozess-Scheduler gedreht wird, um den Durchsatz zu steigern laufen mir kalte Schauer über den Rücken...

Weiterhin:
systat -vmstat
 
milius.net schrieb:
letzte fragen:
1. dma für die hd ist im bios gesetzt - wie finde ich heraus ob es auch genutzt wird? kernel?
Zum Vergrößern anklicken....
Das geht mit atacontrol mode ganz gut. Das Kommando ist sehr nützlich, weil FreeBSD in meinem Notbook mit PIO4 hochkommt. Auf dem Desktop wiederum kommen die laufwerke zwar mit UDMA33 hoch, einige DVDs kann ich mir aber nur ansehen, wenn ich das Laufwerk in PIO4 schicke.
 
Mit:
Code: 
gstat
lässt sich detailiert anschauen, wie Schreib- und Leseaktivitäten
Laufwerke auslasten.

Mit systat -vmstat, wie Endorphine vorschlug,
sieht man natürlich auch die Schreib und Leseaktivitäten auf Laufwerken. (und noch viel mehr)


Gruß, Fusselbär
 
1. Viele kleine Dateien zu erstellen|verschieben|entpacken|verpacken dauert erfahrungsgemäß länger als das selbe mit ein paar großen zu tun.

2. Viele Festplattenzugriffe, verteilt über die Platte, am besten noch von mehreren Prozessen, verlaufen alles andere als schnell.

3. FreeBSD mag es nicht wenn viele auf der selben Platte rumdödln, das wird sich hoffentlich in 8 mit nem neuen IO-Scheduling ändern IIRC (bitte um Verbesserung).

3. Schonmal dran gedacht, dass das einfach so lange dauert?
 
FreeBSD mag es nicht wenn viele auf der selben Platte rumdödln, das wird sich hoffentlich in 8 mit nem neuen IO-Scheduling ändern IIRC
Zum Vergrößern anklicken....
Naja, wunder sollte man nicht erwarten. Bei einer Platte blockiert eher die Hardware als VFS, das wird sich natürlich auch mit 8.0 nicht ändern. Ändern wird sich eher, dass Zugriffe auf eine Platte an Controller A auch die Zugriffe auf die andere Platte an Controller B blockieren. Oder das ein langlaufendes tar das ganze System blockieren kann. Und so weiter ;)
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Zurück
Oben