Hallo Six,
danke für die Antwort und ..... sorry .... ok, das war vermutlich zu allgemein. Wie komme ich auf die Zahl?:
Code: Alles auswählen
total_time=$(expr $(echo $(cat /proc/stat | head -1 | tr -s ' ' | cut -f2,3,4,5 -d ' ' | sed 's/ / + /g')))
idle_time=$(cat /proc/stat | head -1 | tr -s ' ' | cut -f 5 -d ' ')
calc_time=$(expr $total_time - $idle_time)
uptime
echo "scale=2; $calc_time * 100 / $total_time" | bc
Warum denke ich, dass dies am Limit ist? Nun, das ist natürlich subjektiv. In den Spitzenzeiten wird die Arbeit schon ordentlich verzögert (da hängt auch schon mal eine Anwendung kurz - andere würden sagen, xmms hängt). Ob unser System jedoch nur nicht besonders gut für Lastspitzen und parallele Job's konfiguriert ist, oder aber die Anforderungen an einen K6/1GHz und KDE für mehrere User (meist 4 echt parallel) mittels X-Export auf Thin-Clients zu hoch sind, kann ich nicht sagen. Deshalb habe ich zunächst nach einem allgemeinen Vergleichswert gesucht, welcher eventuell die Frage beantworten kann, ob mein Fokus eher der Hardware oder der Konfiguration gelten sollte.
Über Peak-Lasten kann ich keine genaue Auskunft geben, da ich nicht weiß, wie ich sowas rausbekommen soll, außer ein aufwendiges Protokoll (aller 60s z.Bsp.). Ich kann daher nur subjektiv sagen (was man eben so im top sieht), dass die Peak's durchaus mehrere Minuten eine idle-time von 0% bewirken. Dabei ist jedoch alles 'vernicet' ... was für ein Wort
Ich will damit sagen, dass 0% idle meist nicht stören, da solche Jobs idR mit hohen nice Werten arbeiten. Die user (KDE) haben sowiso nur nice Werte > 10. Aber irgendwie scheint das Limit erreicht zu sein. Das merke ich immer am besten, da alle meine Job's nice Werte >= 12 besitzen.
Da die Job's aber kaum wegkonfiguriert werden können
, habe ich hier im Forum ein wenig gelesen und speziell nach performanter paralleler Jobverarbeitung (ohne SMP) gesucht. Was ich dabei gefunden habe, aber nicht verstehe, ist die Sache mit CONFIG_PREEMPT. Ist vermutlich ein neuer Thread
Wenn ich die Wikipedia zum Thema "Präemptives Multitasking" richtig verstehe, ist doch ein Linux Kernel nicht
kooperativ?!
Code: Alles auswählen
>zgrep PREE /proc/config.gz
# CONFIG_PREEMPT is not set
Auch verstehe ich die Aussage von markus_b hier aus einem
Forumsthread nicht. Was ganz genau bringt mir denn diese (bei uns nicht aktivierte) Option? Nach seiner Aussage ist der Verzicht auf diesen patch besser für "Server" (also kein eigenes GUI?) geeignet? Aber es handelt sich doch trotzdem um eine Zeitscheibe?! Leider ging es in diesem Thread um eine andere Kernftrage.
Im Forum finde ich zum Thema
preemptive nicht sonderlich viel, außer das alle zu wissen scheinen, was das genau bewirkt ... und irgendwie wie von Zauberhand alles schneller macht
:
*
http://www.debianforum.de/forum/viewtop ... preemptive
Interessant ist noch der Thread
low-latency patch / preemptible kernel patch. Danach bin ich mir aber nicht sicher, ob die Option wirklich benötigt wird. Es geht um die Latenzzeiten. Ok, das 'spürt' man vermutlich im GUI. Auch bei einem X-Export?
