Wie kann ich in Solaris SunOS 5.10 auf gestohlene Zeitdaten zugreifen?

Question

Ich glaube, die von uns verwendete Solaris-Version ist zu alt, um die Diebstahlzeit in Top zu melden. Gibt es eine Möglichkeit, diese Informationen über diese ältere Solaris-Version abzurufen? Hier sind die grundlegenden Versionsinformationen:

-bash-3.2$  uname -aX
SunOS sekritname 5.10 Generic_150400-59 sun4v sparc sun4vSystem = SunOS
Node = sekritname
Release = 5.10
KernelID = Generic_150400-59
Machine = sun4v
BusType = <unknown>
Serial = <unknown>
Users = <unknown>
OEM# = 0
Origin# = 1
NumCPU = 32

Ich habe keine wirkliche Erfahrung mit diesen Sun VM-Systemen, daher verstehe ich die Dinge vielleicht falsch und es gibt vielleicht eine bessere Möglichkeit, das zu tun, was ich in dieser Situation brauche. Wenn ich mein Intel-Denkmodell anwende, vermute ich, dass wir von der CPU verdrängt werden, aber wie kann ich das messen?

Aktualisieren

Verzeihen Sie die Intel-Terminologie. Wir betreiben im Grunde zwei VMs auf einem einzigen Blade, von denen eine ein Anwendungsserver ist und die andere SSO-Unterstützung für die Anwendung bietet. Es gibt Momente, in denen der Anwendungsserver deutlich langsamer wird, und es gibt auch Momente, in denen die SSO-Anwendung eines Drittanbieters ins Stocken gerät.

Außerdem sind Silos und Politik im Spiel, sodass ich keinen Einblick in den SSO-Host oder die eigentliche Hardwareebene habe.

Meine derzeitige Betriebshypothese ist, dass die SSO-Anwendung, wenn sie verrücktspielt, die CPU so stark beansprucht, dass der Anwendungsserver nicht genügend reale Rechenzeit erhält, um mit der Last Schritt zu halten. Ich habe die GC-Protokolle der Anwendung analysiert und dabei fielen Einträge wie dieser auf:

[Times: user=0.71 sys=1.36, real=1.47 secs]

Das ist normalerweise bei 10 parallelen GC-Worker-Threads der Fall, user >> real >> sysund eine Ursache für das seltsame Zeitmuster ist eine VM, bei der Sie nicht genügend CPU erhalten. (Wir führen kein Swapping durch und die Systeme sind alle SSD-basiert, sodass IO-Wartezeiten kein Problem darstellen.)

An diesem Punkt muss ich Daten sammeln, um diese Theorie zu beweisen, und in meinem Linux-Gedanken würde ich einfach den st% in top überprüfen. Beim Googeln sagt man auch, dass ich in der modernen Version von Solaris dasselbe tun könnte. Mein Problem ist, dass wir diese moderne Version von Solaris nicht ausführen.

Answer 1

Ihr eigentliches Problem scheinen hier die Leistungseinbußen zu sein. Und Steal-Time ist auf einem Solaris 10 T1000/T2000-Server wahrscheinlich bedeutungslos.

Um herauszufinden, ob Sie in einer Zone arbeiten, verwenden Sie den /usr/bin/zonenameBefehl (der Speicherort kann bei verschiedenen Solaris-Versionen unterschiedlich sein – überprüfen Sie auch /bin, /sbin/, und /usr/sbin.) Wenn zonenameetwas anderes als zurückgegeben wird global, arbeiten Sie in einer Zone.

Wenn Sie aus irgendeinem Grund keinen Zugriff auf den Befehl haben zonename, können Sie mit mehreren psBefehlen feststellen, ob Sie sich in einer Zone befinden. Suchen Sie zunächst nach init:

ps -ef | grep init

Wenn dadurch kein initProzess mit der PID gefunden wird 1, befinden Sie sich in einer Zone. Sie können auch nach Folgendem suchen zsched(IIRC):

ps -ef | grep zsched

Wenn dies einen Prozess zurückgibt, der sein eigener übergeordneter Prozess ist (sowohl PID als auch PPID sind gleich und größer als 1), dann arbeiten Sie in einer Zone.

Wenn Sie sich in einer Zone befinden, stoßen Sie möglicherweise auf Ressourcenbeschränkungen, die Sie verlangsamen. Dies ist jedoch wahrscheinlich nicht der Fall.

Wasandersläuft aber auf dem Server? Einschließlich anderer Zonen. Ich habe wirklich schlimme Leistungsprobleme auf Sun T-Serie-Servern gesehen, die denen ähneln, die Sie beschreiben. Sie wurden durch Interaktionen zwischen dem ZFS ARC und Anwendungen verursacht, die riesige Speicherseiten verwenden – wie etwa eine Oracle-Datenbank.

Der ZFS ARC verwendet 4k Speicherseiten, fragmentiert also den Speicher - und fragmentiertALLEder Speicher auf Ihrem Server. Wenn Ihr Server in diesen Zustand gerät und ein Prozess eine erhebliche Menge an großen Speicherseiten benötigt, muss der Kernel eine Reihe kleiner Seiten zu großen zusammenfassen, was das Verschieben einer Menge Speicher erfordert. Und das alles wird einfädig erledigt. Und jeder einzelne Thread auf einem frühen T-Serien-Server istLANGSAMda die Server für die Verarbeitung einer großen Anzahl von Threads mit großen Latenzen ausgelegt sind – wie beispielsweise ein Webserver oder Datenbankserver, der viele Verbindungen über ein Netzwerk verarbeitet.

Daher führt der Kernel längere Zeiträume durch, in denen er praktisch nichts anderes tut, als kleine Speicherseiten zu großen Seiten zusammenzufassen.

Anschließend erhält ZFS ARC die Seiten zurück, nachdem der Prozess mit großen Seitenmengen abgeschlossen ist und sie fragmentiert werden.

Ich vermute, dass Sie möglicherweise genau dasselbe Problem haben.

Um das herauszufinden, führen Sie

echo ::memstat | mdb -k

als Root in der globalen Zone, wenn Sie Zonen ausführen. Wenn Ihr freier Speicher sehr gering ist, liegt dieses Problem möglicherweise bei Ihnen vor.

Um dies herauszufinden, führen Sie das folgende dTrace-Skript erneut als Root aus der globalen Zone aus, um zu ermitteln, wo der Kernel seine gesamte Zeit verbringt:

#!/usr/sbin/dtrace -s

profile:::profile-1001hz
/arg0/
{
    @[ stack() ] = count();
}

Kopieren Sie es beispielsweise in eine Datei, hot.dmachen Sie es ausführbar ( chmod 755 hot.d) und führen Sie es als Root aus der globalen Zone aus:

./hot.d

Führen Sie es aus, wenn Sie Verlangsamungen feststellen. Lassen Sie es für gute 10-20 Sekunden laufen, wenn nicht länger, nachdem es ausgegeben wurde matched 1 probe, und unterbrechen Sie es dann mit CTRL-C. Es wird dann einvielvon Ausgaben, von denen Sie die meisten nicht interessieren. Die letzten paar Stacktraces-Ausgaben werden jedoch die am häufigsten abgetasteten sein und Ihnen sagen, womit der Kernel seine ganze Zeit verbringt.

Damit wissen Sie definitiv, wo Ihr Problem liegt. Es ist vielleicht nicht präzise genug, um es vollständig zu lösen, und Sie müssen möglicherweise weitere Untersuchungen durchführen, aber Sie wissen, wo Sie suchen müssen.

Wenn Sie viele Stacktraces mit idleoder waitdarin sehen, liegt ein Benutzerbereichsproblem vor. Sie können dies möglicherweise feststellen, indem Sie stack()im obigen dTrace-Skript durch ersetzen ustack(), um den Benutzer-Stack abzurufen.

Und wenn Sie viele Stacktraces coalescein den Funktionsnamen sehen, verbringt der Kernel seine ganze Zeit damit, große Speicherseiten zu erstellen. Die Lösung hierfür besteht darin, Speicher freizugeben, höchstwahrscheinlich durch die Begrenzung der ZFS ARC-Größe, möglicherweise sogar stark. Ich mussteKniescheibedas ZFS ARC auf einigen Servern auf unter 1 GB, um Leistungseinbußen vorzubeugen.