sonnenblen.de - Das unabhängige Sun User Forum
Betriebssysteme => Solaris => Thema gestartet von: Riemster am 18. März 2009, 11:23:05
-
Hi
mich wuerde interessieren was den die Zahlen zu bedeuten haben . Das sie den load anzeigen ist mir klar aber wie sind sie einzuschaetzen. Von bis wie weit sind sie ok.
Danke
-
Hi,
man w gibt Auskunft:
The w command displays a summary of the current activity on
the system, including what each user is doing. The heading
line shows the current time, the length of time the system
has been up, the number of users logged into the system, and
the average number of jobs in the run queue over the last 1,
5 and 15 minutes.
somit ist ein (laufender) job auf einer CPU ein load von 1 und damit ist das System optimal ausgelastet. Ein load von >1 heisst, deine Maschine ist unterdimensioniert, einer von < 1 Maschine ist ueberdimensioniert (jetzt mal krass ausgedrueckt)
wenn der load staendig weit ueber 1 ist, sollte man aber schon ueber mehr hardware nachdenken.
Mfg. Erisch
-
wenn der load staendig weit ueber 1 ist, sollte man aber schon ueber mehr hardware nachdenken.
$ uptime
2:05pm up 3 day(s), 7:38, 118 users, load average: 45.83, 53.26, 55.08
Ich hatte ja schon öfter die Vermutung das unser Kunde es mit dem Denken nicht so genau nimmt... ;D
-
http://www.runningunix.com/2009/01/what-is-load-average-in-solaris/
So what is a “high” number for load average? Well, first it depends on how many CPUs you have on your system, since the calculations do not take that into account. If you have one CPU, then a load average of 1.0 would mean you are, on average, consuming exactly 100% of that one CPU over the measurement period. If your number climbs above 1.0, then you have threads in the run queue at some point, waiting for CPU time. Solaris actually handles CPU saturation very well, so this may not mean your performance will degrade; it just means your CPU is well-used.
-
http://www.linux-magazin.de/heft_abo/ausgaben/2007/08/leistungsdiagnostik
Leider ist der Artikel nicht mehr online, aber da wurde mal versucht diese Werte zu erklären, damit sie auch ein Normalmensch versteht.....
ich hab den in Papierformm daheim, der ist mir aber zum Abschreibseln zu lang ;)
-
wenn der load staendig weit ueber 1 ist, sollte man aber schon ueber mehr hardware nachdenken.
$ uptime
2:05pm up 3 day(s), 7:38, 118 users, load average: 45.83, 53.26, 55.08
Ich hatte ja schon öfter die Vermutung das unser Kunde es mit dem Denken nicht so genau nimmt... ;D
Na gut, wenn jeder User im Schnitt mit 1/50 der Rechenleistung zufrieden ist ...
-
Und, äääh, wie lange geht sowas thermisch gut?
GvH
-
hey danke für die schnelle auskunft. ;D
-
Und, äääh, wie lange geht sowas thermisch gut?
GvH
Was hast denn du fuer Hardware, die bei 100% Last zusammenbricht?
-
Und, äääh, wie lange geht sowas thermisch gut?
GvH
Was hast denn du fuer Hardware, die bei 100% Last zusammenbricht?
Nen windows X86 Rechner :D :D :D :D
-
Aber ich habe doch drei angaben!! 1.10, 1.14, 1.14. bedeuten diese alles das gleiche oder wie sieht die aufteilung aus
-
$ uptime
2:05pm up 3 day(s), 7:38, 118 users, load average: 45.83, 53.26, 55.08
Ich hatte ja schon öfter die Vermutung das unser Kunde es mit dem Denken nicht so genau nimmt... ;D
Na gut, wenn jeder User im Schnitt mit 1/50 der Rechenleistung zufrieden ist ...
[/quote]
Hm, wenn das eine 80-CPU Kiste ist, ist es doch nicht so wild?
-
Aber ich habe doch drei angaben!! 1.10, 1.14, 1.14. bedeuten diese alles das gleiche oder wie sieht die aufteilung aus
Damit kannst du quasi die zeitliche Entwicklung der Systemauslastung nachvollziehen. Die erste Zahl gibt die Load in der letzten Minute an, die zweite bzw. dritte Zahl die Load während der letzten 5 bzw. 15 Minuten.
-
$ uptime
2:05pm up 3 day(s), 7:38, 118 users, load average: 45.83, 53.26, 55.08
Ich hatte ja schon öfter die Vermutung das unser Kunde es mit dem Denken nicht so genau nimmt... ;D
Na gut, wenn jeder User im Schnitt mit 1/50 der Rechenleistung zufrieden ist ...
Hm, wenn das eine 80-CPU Kiste ist, ist es doch nicht so wild?
[/quote]
ja, sorry, ich hab das verhauen. Ich dachte es zeigt schon den load/CPU an, aber er zeigt ja nur den Gesamtload an, rechnen muss man dann noch selbst.
Also muss es richtig heissen: Wenn der load die Anzahl von CPUs dauerhaft weit uebersteigt, sollte man ueber Aufruesten nachdenken.
-
$ uptime
2:05pm up 3 day(s), 7:38, 118 users, load average: 45.83, 53.26, 55.08
Ich hatte ja schon öfter die Vermutung das unser Kunde es mit dem Denken nicht so genau nimmt... ;D
Na gut, wenn jeder User im Schnitt mit 1/50 der Rechenleistung zufrieden ist ...
Hm, wenn das eine 80-CPU Kiste ist, ist es doch nicht so wild?
Das ist genau der Punkt. Wenn ich das noch richtig im Kopf habe, sagt der Load-Wert nur, wie viele Prozesse sich in der Run-Queue befinden, also wie viele Prozesse gerne Rechenzeit des Prozessors hätten. Eine Load von 50 bei einem Single-Core/Single-Thread-System heisst, da geht quasi gar nichts mehr. Weil immer nur ein Prozess zu einer Zeit laufen kann und die anderen 49 hinten anstehen müssen. Ein Load von 50 auf einem UltraSPARC T2+ (8 Cores je 8 Threads, also 64 mögliche parallele Prozesse) sagt, dass 14 von dem 64 Cores gerade nichts zu tun haben, weil gerade nicht genug Prozesse, die CPU-Leistung haben wollen.
Sinngemäß gilt das natürlich auch für SMP-Systeme mit mehreren CPUs. Die drei Werte sind normalerweise Durchschnittswerte über die letzten 1min, 5min, 15min, wie Padde schon geschrieben hat.
Der Load-Wert ist nur ein sehr mäßig brauchbarer Wert zur Beurteilung von Performance. Da sind Sachen wie IO-Wait, Context-Switches und Paging-Aktivität wichtiger. Für einen allerersten groben Überblick reicht es natürlich.
wolfgang
-
Der Load-Wert ist nur ein sehr mäßig brauchbarer Wert zur Beurteilung von Performance. Da sind Sachen wie IO-Wait, Context-Switches und Paging-Aktivität wichtiger. Für einen allerersten groben Überblick reicht es natürlich.
Wie kann man das alles sinnvoll abfragen, abgesehen von prstat?
Claus
-
Der Load-Wert ist nur ein sehr mäßig brauchbarer Wert zur Beurteilung von Performance. Da sind Sachen wie IO-Wait, Context-Switches und Paging-Aktivität wichtiger. Für einen allerersten groben Überblick reicht es natürlich.
Wie kann man das alles sinnvoll abfragen, abgesehen von prstat?
Claus
mit den ganzen anderen ...stats: iostat, vmstat
-
Ok, wer kann mir das ungefähr erklären? Die manpages überfordern mich wirklich ...
Claus
-
Der Load-Wert ist nur ein sehr mäßig brauchbarer Wert zur Beurteilung von Performance. Da sind Sachen wie IO-Wait, Context-Switches und Paging-Aktivität wichtiger. Für einen allerersten groben Überblick reicht es natürlich.
Wie kann man das alles sinnvoll abfragen, abgesehen von prstat?
mit den ganzen anderen ...stats: iostat, vmstat
mpstat, lockstat, plockstat fallen mir spontan noch ein.
Ab Solaris 10 alternativ mit DTrace. Was die Sache aber nicht einfacher macht :-) Zum Start mit DTrace halte ich das DTrace Toolkot für recht brauchbar. Das ist eine umfangreiche Sammlung fertiger Scripts, alles dokumentiert.
Wenn ich morgen dazu komme, suche ich ein paar Tutorials etc. raus und poste die passenden Links. Ist aber generell keine einfache Materie. Um solche Zahlen richtig beurteilen zu können, braucht es allerlei unterschiedlichstes Wissen über Kernel Interas. Kann man sich aber alles in endlicher Zeit anlesen...
wolfgang
-
Wenn ich morgen dazu komme, suche ich ein paar Tutorials etc. raus und poste die passenden Links.
Ich habe das noch nicht vergessen, bin im Moment nur ziemlich mit Arbeit zu. Immerhin habe ich schon die ganzen URLs zusammengesucht. Brauchen "nur" noch kommentiert zu werden :) Stay tuned...
wolfgang
-
Das ist genau der Punkt. Wenn ich das noch richtig im Kopf habe, sagt der Load-Wert nur, wie viele Prozesse sich in der Run-Queue befinden,
Exakt. Daher wirds kritisch wenn der "Load/CPUs > 1" ist.
Empfehlen kann ich übrigens den Buch Dreiteiler von Sun:
1) Solaris Internals
2) Solaris Performance and Tools
3) Solaris Application Development
In (2) werden die ganzen unmengen an tools vorgestellt die du nutzen kannst um die
Last rauszufinden. Da merkt man mal den Unterschied zu Linux.
-
Wenn ich morgen dazu komme, suche ich ein paar Tutorials etc. raus und poste die passenden Links. Ist aber generell keine einfache Materie. Um solche Zahlen richtig beurteilen zu können, braucht es allerlei unterschiedlichstes Wissen über Kernel Interas. Kann man sich aber alles in endlicher Zeit anlesen...
So, endlich habe ich Muse, hier ein paar kommentierte Links zu posten.
Für Solaris <10, genau genommen sogar <8 gibt es ein recht gutes Buch zum Thema:
Adrian Cockcroft, Richard Pettit
Sun Performance and Tuning: Java and the Internet (2nd edition, 1999)
http://www.pearsonhighered.com/educator/academic/product/0,3110,0130952494.html,00.html (http://www.pearsonhighered.com/educator/academic/product/0,3110,0130952494.html,00.html)
Das Buch müsste z. B. bei Amazon US noch neu zu kriegen sein. In dem Buch wird recht schön beschrieben, wie welche Messwerte zusammen spielen und worauf man schauen muss, wenn ein bestimmter Wert aus der Reihe tanzt. Oft genug darf nämlich ein einzelner Wert auch mal länger gehörig aus der Reihe tanzen, solange es den anderen Parametern allen gut geht.
In dem Buch ist die Rede von einem SE Toolkit. Das ist eine Sammlung nützlicher Scripts und Tools, um der Performance eines Systems auf den Grund zu gehen. Es gibt bunte graphische Outputs und man bekommt Hinweise, wo man tunen kann oder sollte. Das SE-Toolkit ist natürlich auch unabhängig vom Buch zu bekommen:
http://sourceforge.net/projects/setoolkit/ (http://sourceforge.net/projects/setoolkit/)
Der Buchautor Adrian Cockroft ist nach wie vor im Performance-Bereich unterwegs und schreibt darüber gelegentlich in seinem Blog: http://perfcap.blogspot.com/ (http://perfcap.blogspot.com/).
Wer noch weiter zurück gehen muss, sei auf das sog. Solaris White Album verwiesen. Das ist im Prinzip eine Sammlung von Whitepapers und technischen Aufsätzen anlässlich verschiedener Konferenzen, in denen die Architektur des Kernels und kernelnaher Subsysteme für Solaris 2.x beschrieben sind. Es gibt dazu einen Blogeintrag, der viele der Papers verlinkt:
http://blogs.sun.com/plan9/date/20050304#sun_white_album_essential_papers (http://blogs.sun.com/plan9/date/20050304#sun_white_album_essential_papers)
Ich habe mir vor einiger Zeit mal die Mühe gemacht, die Papers alle zusammen zu tragen, ein Titelblatt und ein Inhaltsverzeichnis dazu zu fabrizieren und das ganze in einem Copyshop binden zu lassen. Ich stelle euch mal die Sammlung als ZIP zum Download zur Verfügung:
http://www.stiefkind.org/download/Solaris_Whitealbum.zip (http://www.stiefkind.org/download/Solaris_Whitealbum.zip)
Für Solaris 8 gibt es dann das erste Solaris Internals Buch, das im wesentlichen Kernel-Strukturen beschreibt, das dafür sehr ausführlich:
Jim Mauro and Richard McDougall
Solaris Internals (2000)
http://www.sun.com/books/catalog/mauro_mcdougall.xml (http://www.sun.com/books/catalog/mauro_mcdougall.xml)
Irgendwann zwischen Solaris 7 und Solaris 10 hat das Benchmark Center von Sun in Langen eine ToolsCD heraus gegeben mit einem Sammelsurium an unterschiedlichsten Werzeugen für Benchmarks und Performance-Untersuchungen. Die CD ist nach wie vor bei Sun zum Download verfügbar: http://mediacast.sun.com/share/stefanschneider/PerformanceCD3.0.tar.gz (http://mediacast.sun.com/share/stefanschneider/PerformanceCD3.0.tar.gz).
Zur CD gibt es auch einen Forumseintrag, wo die ToolsCD 3.0 angekündigt wird. Da stehen dann auch ein paar mehr Details zur CD und zu den Werkzeugen darauf:
http://www.opensolaris.org/jive/thread.jspa?threadID=66396&tstart=59 (http://www.opensolaris.org/jive/thread.jspa?threadID=66396&tstart=59).
Und es gibt auch eine Präsentation dazu, wo die CD ausführlicher vorgestellt wird:
http://mediacast.sun.com/users/stefanschneider/media/ToolsCD-2008.pdf (http://mediacast.sun.com/users/stefanschneider/media/ToolsCD-2008.pdf)
Etwa in die selbe Zeit wie die ToolsCD fällt eine Präsentation von Uli Gräf über übliche Performance-Probleme wie sie bei Kunden damals häufig vorkamen. In der Präsentation werden auch Lösungsansätze aufgezeigt. Mittlerweile evangelisiert Uli ja überwiegend mit OpenSolaris, insbesondere ZFS. Im Archiv des LinuxTags gibt es besagte Präsentation von Uli: http://www.linuxtag.org/2006/fileadmin/linuxtag/dvd/12441-part2-solaris-performance.pdf (http://www.linuxtag.org/2006/fileadmin/linuxtag/dvd/12441-part2-solaris-performance.pdf)
Und damit sind wir dann bei Solaris 10 angelangt. Das bringt mit DTrace zwar ein sehr umfangreiches Instrumentarium mit, aber auch dazu muss man erstmal verstehen, was man messen will. Dazu hat llothar schon Bücher genannt. Die ersten beiden habe ich auch in meinen Notizen für diesen Beitrag stehen:
Richard McDougall and Jim Mauro
Solaris Internals, Second Edition: Solaris 10 and OpenSolaris Kernel Architecture (2006)
http://www.sun.com/books/catalog/solaris_internals.xml (http://www.sun.com/books/catalog/solaris_internals.xml)
Und ja, das ist die zweite Auflage des oben bereits genannten Buches. Allerdings stark erweitert.
Richard McDougall, Jim Mauro and Brendan Gregg
Solaris Performance and Tools: DTrace and MDB Techniques for Solaris 10 and OpenSolaris (2006)
http://www.sun.com/books/catalog/solaris_perf_tools.xml (http://www.sun.com/books/catalog/solaris_perf_tools.xml)
Zu den Büchern gibt es auch ein Solaris Internals Wiki:
http://www.solarisinternals.com/wiki/index.php/Solaris_Internals_and_Performance_FAQ (http://www.solarisinternals.com/wiki/index.php/Solaris_Internals_and_Performance_FAQ)
Bereits genannt habe ich DTrace als Werkzeug. DTrace ist sehr mächtig, aber auch sehr umfangreich und gerade für Einsteiger nicht eben leicht zu überblicken. Die "offizielle" Dokumentation dazu ist der Solaris Dynamic Tracing Guide: http://docs.sun.com/app/docs/doc/817-6223/ (http://docs.sun.com/app/docs/doc/817-6223/).
Ähnlich dem oben genannten SE-Toolkit gibt es auch für DTrace eine Sammlung fertiger Scripts, die man entweder out of the box verwendet oder als Ausgangspunkt für eigene Modifikationen nimmt. Das Ding heißt dann auch DTrace Toolkit: http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/ (http://www.opensolaris.org/os/community/dtrace/dtracetoolkit/).
Das Bigadmin-Portal bei Sun hat auch eine eigenen Einstiegsseite zu DTrace mit allerlei interessanten und hilfreichen Links dazu: http://www.sun.com/bigadmin/content/dtrace/ (http://www.sun.com/bigadmin/content/dtrace/). Und es gibt im Bigadmin-Portal auch eine generelle Seite zu Solaris Performance: http://www.sun.com/bigadmin/collections/performance.jsp (http://www.sun.com/bigadmin/collections/performance.jsp). Übrigens greifen eine ganze Reihe der Statistik-Werkzeugen in Solaris 10 auf DTrace-Mechanismen zurück (lockstat, plockstat, vmstat, mpstat...).
Wer gerne mal so zwischendurch ein bisschen auf dem laufenden bleibt, was sich in der Performance- und Benchmarkingwelt so tut, für den habe ich drei Blogs aus dem Sun-Universum parat:
http://blogs.sun.com/bmseer (http://blogs.sun.com/bmseer)
http://blogs.sun.com/brendan (http://blogs.sun.com/brendan)
http://blogs.sun.com/MrBenchmark/ (http://blogs.sun.com/MrBenchmark/)
BMSeer liest sich gelegentlich wie Sun Propaganda (höher, schneller, weiter). Die Berichte taugen immerhin, um herauszufinden, wo IBM seine Schwächen hat. Es gibt umgekehrt auch einen ähnlichen Blog von IBM. Der ist aber noch viel mehr gehirngewaschen, deshalb ist er wieder aus meinem RSS-Reader gefallen. Brendan Gregg macht im Moment viel mit dem Storage 7000 rum, einigen hier sollte er aus dem Video bekannt sein, wo er in ein JBOD rein brüllt und mittels DTrace zeigt, dass die Latenz bei denjenigen Platten deutlich ansteigt, die durch das Brüllen in Vibration versetzt wurden. Generell lohnt sich, mal auf http://blogs.sun.com/ (http://blogs.sun.com/) nach Stichworten rund um Performance, DTrace etc. zu suchen. Ich kenne keinen anderen Hersteller aus der IT-Welt, wo so viele Engineers so exzellente, hochwertige Blogartikel abliefern.
Und wer gerne mal was von außerhalb Suns lesen will, der kann sich ja mal auf http://www.spec.org/ (http://www.spec.org/) umschauen. Die veröffentlichten Ergebnisse zu SPECfp und SPECint (Detailberichte, beides z. B. aus SPEC2000) sind gelegentlich nicht uninteressant. Darin müssen nämlich z. B. auch Compileroptionen veröffentlicht werden, mit denen die Benchmarks gefahren werden. Weil Benchmarking eigentlich Voodoo ist, ist es für einen aussagekräftigen Vergleich der Ergebnisse unabdingbar, sich auch die jeweils konkrete Messmethode mit anzuschauen.
So, viel Material für die Osterwoche. Ich wünsche viel Spaß bei der Sekundärliteratur :)
wolfgang
-
Wow!!! Vielen Dank, das ist echt ein Haufen Zeugs (und ein HAUFEN Arbeit gewesen)!
Sieht auch alles sehr interessant aus, eventuell begreif ich damit das alles auch mal!
Claus