Meine Frage bezieht sich im Wesentlichen auf die Speicherzuweisung für virtuelle Solaris-Maschinen.
Ich betreibe ein paar alte Sun ONE 6 Java-Webserver auf zwei virtuellen Solaris 8-Maschinen. Ich sehe, dass eine beträchtliche Menge an Swap-Speicherplatz verwendet wird, bin mir aber nicht ganz sicher, ob dies darauf hinweisen könnte, dass diesen Maschinen mehr RAM hinzugefügt werden muss.
Zu Spitzenzeiten (normalerweise morgens) steigt die Antwortzeit der Webanwendung, die diese Server hosten, auf höchstens 11 Sekunden (was für das Laden einer relativ einfachen Webseite etwas nachteilig ist). Die durchschnittliche Antwortzeit außerhalb der Spitzenzeiten beträgt etwa 5 Sekunden.
Was können Sie aus der folgenden Ausgabe über die RAM-Nutzung dieser Maschinen ableiten? Sind diese Informationen ausreichend? Oder müsste ich andere Befehle ausführen, um einen Mangel an Serverspeicher auszuschließen?
Da den Kern des Setups eine Java-Anwendung bildet, habe ich außerdem über Folgendes nachgedacht:
1) Verfolgen Sie die Objektzuweisung des Heaps, um mögliche Speicherlecks zu erkennen.
2) Führen Sie ein Leistungsprofil durch, um zu sehen, ob dies stattdessen mit Netzwerkverzögerungen zusammenhängt. Ich erwähne dies, da die Anwendung mit einer einzelnen Oracle-Datenbank kommuniziert, aber ich würde bezweifeln, dass dies der Fall ist, da sie aus Sicht der Netzwerksegmentierung ziemlich nah beieinander liegen.
Ich freue mich über alle Einblicke und Rückmeldungen, die Sie mir geben können.
Vielen Dank für Ihre Zeit und Hilfe.
Server 1:
40 processes: 38 sleeping, 1 zombie, 1 on cpu
CPU states: 99.1% idle, 0.4% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Memory: 2048M real, 295M free, 865M swap in use, 3788M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
12676 webservd 112 29 10 616M 242M sleep 103:37 0.48% webservd
18317 root 1 59 0 23M 19M sleep 67:24 0.08% perl
9479 support 1 59 0 6696K 2448K cpu/1 0:11 0.05% top
8012 root 10 59 0 34M 704K sleep 80:54 0.04% java
1881 root 33 29 10 110M 13M sleep 33:03 0.02% webservd
7808 root 1 59 0 83M 67M sleep 7:59 0.00% perl
1461 root 20 59 0 5328K 1392K sleep 6:49 0.00% syslogd
1691 root 2 59 0 27M 680K sleep 4:22 0.00% webservd
24386 root 1 59 0 15M 11M sleep 2:50 0.00% perl
23259 root 1 59 0 11M 4240K sleep 2:42 0.00% perl
24718 root 1 59 0 11M 5464K sleep 2:29 0.00% perl
22810 root 1 59 0 19M 11M sleep 2:21 0.00% perl
24451 root 1 53 2 11M 3800K sleep 2:18 0.00% perl
18501 root 1 56 1 11M 3960K sleep 2:18 0.00% perl
14450 root 1 56 1 15M 6920K sleep 1:49 0.00% perl
Server 2
42 processes: 40 sleeping, 1 zombie, 1 on cpu
CPU states: 98.8% idle, 0.4% user, 0.8% kernel, 0.0% iowait, 0.0% swap
Memory: 1024M real, 31M free, 554M swap in use, 3696M swap free
PID USERNAME THR PRI NICE SIZE RES STATE TIME CPU COMMAND
5607 webservd 74 29 10 284M 173M sleep 20:14 0.21% webservd
15919 support 1 59 0 4056K 2520K cpu/1 0:08 0.09% top
13138 root 10 59 0 34M 1952K sleep 210:51 0.08% java
13753 root 1 59 0 22M 12M sleep 170:15 0.07% perl
22979 root 33 29 10 112M 7864K sleep 85:07 0.04% webservd
22930 root 1 59 0 3424K 1552K sleep 17:47 0.01% xntpd
22978 root 2 59 0 27M 2296K sleep 10:49 0.00% webservd
13571 root 1 59 0 9400K 5112K sleep 5:52 0.00% perl
5606 root 2 29 10 29M 9056K sleep 0:36 0.00% webservd
15910 support 1 59 0 9128K 2616K sleep 0:00 0.00% sshd
13106 root 1 59 0 82M 3520K sleep 7:47 0.00% perl
13547 root 1 59 0 12M 5528K sleep 6:38 0.00% perl
13518 root 1 59 0 9336K 3792K sleep 6:24 0.00% perl
13399 root 1 56 1 8072K 3616K sleep 5:18 0.00% perl
13557 root 1 53 2 8248K 3624K sleep 5:12 0.00% perl
Antwort1
Um herauszufinden, ob Ihren Servern RAM fehlt, wäre die Spalte sr in der Ausgabe des vmstat-Befehls eine nützliche Messgröße. Führen Sie einfach vmstat 10 10während Referenz- und Spitzenzeiten (10 Proben alle 10 Sekunden) etwas wie aus und veröffentlichen Sie die Ausgabe. swap -sAusgaben wären auch nützlich. Alternativ zu vmstat können Sie auch Folgendes ausführen: sar -g 5 5
In jedem Fall scheint Server2 laut der Ausgabe von „top“ RAM zu fehlen. Solaris verfügt über einen unterstützten Befehl ähnlich top, der ebenfalls dabei helfen könnte, die virtuellen und physischen Speicherverbraucher zu identifizieren:
prstat -s rss -n 5
prstat -s size -n 5
Antwort2
Die Dinge, die mir in diesen Schnappschüssen auffallen, sind die folgenden:
- Viele Perl-Prozesse
- Mehrere Webservd-Prozesse
- Maschinen sind zu 98 % und 99 % im Leerlauf
Diese Fakten führen zu folgenden Fragen …
- Können Sie die Anzahl der Perl-Prozesse reduzieren?
- Ich nehme an, es gibt keine Möglichkeit, zu einem Thread-Webservermodell zu wechseln?
- Wie sieht die Systemspitze aus, wenn die Maschinen unter Stress stehen?
Um das Problem zu ermitteln, würde ich Folgendes tun:
- Verwenden Sie einen Netzwerk-Sniffer wie Wireshark, um zu sehen, welcher Teil des HTTP-Prozesses tatsächlich aufgehalten wird. Ist es die Verbindung? Ist es die Bereitstellung der Seite? Ist es die Bereitstellung eines dynamischen Teils der Seite?
- Besorgen Sie sich ein HTTP-Stresstool und belasten Sie Ihre Webserver, um zu sehen, wie sie reagieren. Beobachten Sie die Antworten mit vmstat und top: Ich verwende hierfür gerne screen in einem Terminal.
Viel Glück!
Antwort3
Ich habe immer festgestellt, dass die Systemabrechnung die einfachste Möglichkeit ist, die Speichernutzung zu verfolgen. Sie kann stark schwanken, daher ist es wichtig, mindestens eine Woche lang zu überprüfen, um das Nutzungsmuster zu erkennen.
Bearbeiten Sie die Crontab „sys“, und Sie werden einige auskommentierte Ausführungen des Skripts /usr/lib/sa/sa1 sehen. Wie oft es ausgeführt wird, bestimmt die zeitliche Auflösung der gespeicherten Abrechnungsdaten. Normalerweise mache ich für ein 24x7-System so etwas:
20,40 * * * * /usr/lib/sa/sa1
Dadurch werden die Statistiken in /var/adm/sa nach Tag des Monats gespeichert. Jetzt verwenden Sie sar, um die Speicherstatistiken für alle dort gespeicherten Tage zu sichern. Nehmen wir an, der 3. war für mich ein Spitzentag:
sar -f /var/adm/sa/sa03 -g
Die Spalte von primärem Interesse ist pgscan/s. Wenn diese Zahl über längere Zeiträume über 200 liegt, hat das System nicht genügend Speicher. Bei 100 profitieren Sie wahrscheinlich von mehr Speicher, aber die Verschlechterung ist nicht gravierend. Heutzutage, wo Disk-Swap so viel langsamer ist als der Speicher, versuche ich, ihn außer bei kurzfristigen Sprüngen bei 0 zu halten.