Frage Hoher Ladendurchschnitt, geringe CPU-Auslastung - warum?


In einer Webanwendung treten enorme Leistungsprobleme auf und wir versuchen, den Engpass zu finden. Ich bin kein Systemadministrator, also gibt es einige Sachen, die ich nicht ganz verstehe. Einige grundlegende Untersuchungen zeigen, dass die CPU im Leerlauf ist, viel Speicher verfügbar ist, kein Swapping, keine I / O, aber eine hohe durchschnittliche Auslastung.

Der Software-Stack auf diesem Server sieht folgendermaßen aus:

  • Solaris 10
  • Java 1.6
  • WebLogic 10.3.5 (8 Domänen)

Die auf diesem Server ausgeführten Anwendungen sprechen mit einer Oracle-Datenbank auf einem anderen Server.

Dieser Server hat 32 GB RAM und 10 CPUs (glaube ich).

Laufen prstat -Z gibt so etwas:

   PID USERNAME  SIZE   RSS STATE  PRI NICE      TIME  CPU PROCESS/NLWP
  3836 ducm0101 2119M 2074M cpu348  58    0   8:41:56 0.5% java/225
 24196 ducm0101 1974M 1910M sleep   59    0   4:04:33 0.4% java/209
  6765 ducm0102 1580M 1513M cpu330   1    0   1:21:48 0.1% java/291
 16922 ducm0102 2115M 1961M sleep   58    0   6:37:08 0.0% java/193
 18048 root     3048K 2440K sleep   59    0   0:06:02 0.0% sa_comm/4
 26619 ducm0101 2588M 2368M sleep   59    0   8:21:17 0.0% java/231
 19904 ducm0104 1713M 1390M sleep   59    0   1:15:29 0.0% java/151
 27809 ducm0102 1547M 1426M sleep   59    0   0:38:19 0.0% java/186
  2409 root       15M   11M sleep   59    0   0:00:00 0.0% pkgserv/3
 27204 root       58M   54M sleep   59    0   9:11:38 0.0% stat_daemon/1
 27256 root       12M 8312K sleep   59    0   7:16:40 0.0% kux_vmstat/1
 29367 root      297M  286M sleep   59    0  11:02:13 0.0% dsmc/2
 22128 root       13M 6768K sleep   59    0   0:10:51 0.0% sendmail/1
 22133 smmsp      13M 1144K sleep   59    0   0:01:22 0.0% sendmail/1
 22003 root     5896K  240K sleep   59    0   0:00:01 0.0% automountd/2
 22074 root     4776K 1992K sleep   59    0   0:00:19 0.0% sshd/1
 22005 root     6184K 2728K sleep   59    0   0:00:31 0.0% automountd/2
 27201 root     6248K  344K sleep   59    0   0:00:01 0.0% mount_stat/1
 20964 root     2912K  160K sleep   59    0   0:00:01 0.0% ttymon/1
 20947 root     1784K  864K sleep   59    0   0:02:22 0.0% utmpd/1
 20900 root     3048K  608K sleep   59    0   0:00:03 0.0% ttymon/1
 20979 root       77M   18M sleep   59    0   0:14:13 0.0% inetd/4
 20849 daemon   2856K  864K sleep   59    0   0:00:03 0.0% lockd/2
 17794 root       80M 1232K sleep   59    0   0:06:19 0.0% svc.startd/12
 17645 root     3080K  728K sleep   59    0   0:00:12 0.0% init/1
 17849 root       13M 6800K sleep   59    0   0:13:04 0.0% svc.configd/15
 20213 root       84M   81M sleep   59    0   0:47:17 0.0% nscd/46
 20871 root     2568K  600K sleep   59    0   0:00:04 0.0% sac/1
  3683 ducm0101 1904K 1640K sleep   56    0   0:00:00 0.0% startWebLogic.s/1
 23937 ducm0101 1904K 1640K sleep   59    0   0:00:00 0.0% startWebLogic.s/1
 20766 daemon   5328K 1536K sleep   59    0   0:00:36 0.0% nfsmapid/3
 20141 daemon   5968K 3520K sleep   59    0   0:01:14 0.0% kcfd/4
 20093 ducm0101 2000K  376K sleep   59    0   0:00:01 0.0% pfksh/1
 20797 daemon   3256K  240K sleep   59    0   0:00:01 0.0% statd/1
  6181 root     4864K 2872K sleep   59    0   0:01:34 0.0% syslogd/17
  7220 ducm0104 1268M 1101M sleep   59    0   0:36:35 0.0% java/138
 27597 ducm0102 1904K 1640K sleep   59    0   0:00:00 0.0% startWebLogic.s/1
 27867 root       37M 4568K sleep   59    0   0:13:56 0.0% kcawd/7
 12685 ducm0101 4080K  208K sleep   59    0   0:00:01 0.0% vncconfig/1
ZONEID    NPROC  SWAP   RSS MEMORY      TIME  CPU ZONE
    42      135   22G   19G    59%  87:27:59 1.2% dsuniucm01

Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11

Ich verstehe, dass die CPU im Leerlauf ist, aber der Lastdurchschnitt ist hoch, was mir ziemlich fremd ist. Speicher scheint kein Problem zu sein.

Laufen vmstat 15 gibt so etwas:

 kthr      memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr s0 s1 s4 sd   in   sy   cs us sy id
 0 0 0 32531400 105702272 317 1052 126 0 0 0 0 13 13 -0 8 9602 107680 10964 1 1 98
 0 0 0 15053368 95930224 411 2323 0 0 0 0 0 0  0  0  0 23207 47679 29958 3 2 95
 0 0 0 14498568 95801960 3072 3583 0 2 2 0 0 3 3  0 21 22648 66367 28587 4 4 92
 0 0 0 14343008 95656752 3080 2857 0 0 0 0 0 3 3  0 18 22338 44374 29085 3 4 94
 0 0 0 14646016 95485472 1726 3306 0 0 0 0 0 0 0  0  0 24702 47499 33034 3 3 94

Ich verstehe, dass die CPU meist untätig ist, keine Prozesse in der Warteschlange warten, um ausgeführt zu werden, wenig Austausch ist passiert.

Laufen iostat 15 gibt dies:

   tty        sd0           sd1           sd4           ssd0           cpu
 tin tout kps tps serv  kps tps serv  kps tps serv  kps tps serv   us sy wt id
   0  676 324  13    8  322  13    8    0   0    0  159   8    0    1  1  0 98
   1 1385   0   0    0    0   0    0    0   0    0    0   0    0    3  4  0 94
   0  584  89   6   24   89   6   25    0   0    0  332  19    0    2  1  0 97
   0  296   0   0    0    0   0    0    0   0    0    0   0    0    2  2  0 97
   1 1290  43   5   24   43   5   22    0   0    0  297  20    1    3  3  0 94

Laufen netstat -i 15 gibt folgendes:

    input   aggr26    output       input  (Total)    output
packets errs  packets errs  colls  packets errs  packets errs  colls
1500233798 0     1489316495 0     0      3608008314 0     3586173708 0     0
10646   0     10234   0     0      26206   0     25382   0     0
11227   0     10670   0     0      28562   0     27448   0     0
10353   0     9998    0     0      29117   0     28418   0     0
11443   0     12003   0     0      30385   0     31494   0     0

Was vermisse ich?


71
2018-02-29 22:29


Ursprung


Ich bin nicht mit Solaris zu Hause, deshalb werde ich mich auf jemand anderen verlegen, aber ich würde anfangen, Ihre Webserver-Konfiguration zu betrachten. Vielleicht ist es etwas, das die Performance künstlich so einstellt, dass viele Threads in der Run-Queue verbleiben. (Nicht sicher, was das sein könnte oder auch wenn es möglich ist). Ein großes Lob für eine gut geschriebene Frage. - SmallClanger
10 CPUs (glaube ich) ist möglicherweise das Problem. Sie sollten genauer wissen, welche Hardware Sie ausführen, bevor Sie weitere Untersuchungen durchführen. Benutzen psrinfo -v um die tatsächliche Anzahl der CPUs anzuzeigen. - jlliagre
Ich habe noch nie von diesem Befehl gehört, aber wenn ich ihn starte, sieht es so aus, als gäbe es ungefähr 250 virtuelle Prozessoren. Macht das überhaupt Sinn? In diesem Fall wäre ein Lastdurchschnitt von 50 unbedeutend? - Spiff
Ich denke, das kann auch passieren, wenn Ihre Festplatte voll ist. Ich hatte das heute mit 1% freiem Speicherplatz auf / und die Belastung nahm bis zum Ende zu 19.00 ohne erkennbaren Grund. Etwas Platz frei machen löste das Problem (kurz nachdem es herunterkam); kann aber auch ein Zufall sein. - nh2


Antworten:


Bei einigen weiteren Untersuchungen scheint das Leistungsproblem hauptsächlich auf eine hohe Anzahl von Netzwerkverbindungen zwischen zwei Systemen (Oracle SSXA und UCM) zurückzuführen zu sein. Die Anrufe sind schnell, aber reichlich und serialisiert, daher die geringe CPU-Auslastung (meistens auf E / A wartend), der hohe Lastdurchschnitt (viele Anrufe warten auf Verarbeitung) und vor allem die langen Antwortzeiten (durch Anhäufung kleiner Antwortzeiten).

Danke für deinen Einblick in dieses Problem!


39
2018-03-02 15:15





Wenn Sie "High Load Average" sagen, nehme ich an, dass Sie meinen, dass prstat für 'load average' am unteren Ende der Ausgabezahlen von zeigt

Total: 135 processes, 3167 lwps, load averages: 54.48, 62.50, 63.11

Diese Zahlen ähneln denen, die oben angegeben sind, und meinen wahrscheinlich die durchschnittliche Warteschlangengröße des laufenden Prozesses. Dies ist nicht der Prozentsatz der Prozessorzeit, der verwendet wird, sondern wie viele "Dinge" die CPU für die Ausführungszeit belästigen. Zugegebenermaßen sehen diese ziemlich hoch aus, aber das hängt alles von der App ab, die Sie ausführen; Die Prozesse können nicht wirklich viel tun, sobald sie ihren Platz bekommen. Sehen Hier für eine nette Erklärung bezüglich top.

Ich bin mit WebLogic nicht vertraut, aber mir ist aufgefallen, dass mit Apache Tomcat im Allgemeinen viele Java-Threads gleichzeitig erzeugt werden können, die als nicht viele Anfragen erscheinen. Es könnte sein, dass diese hohen Durchschnittsladungszahlen verursachen. Stellen Sie sicher, dass Sie das Verbindungspooling verwenden, um eine Verbindung zum Backend herzustellen, und überlegen Sie, die Anzahl der inaktiven Threads, die für Ihre Anwendung verfügbar sind, zu verarbeiten (nicht sicher, wie Sie dies in WebLogic tun; Tomcat verfügt über einen Threadpool pro Connector) ein allgemeiner Executor-Thread-Pool). Wenn Sie dies nicht tun, werden möglicherweise brandneue Threads zur Verarbeitung von Anforderungen generiert.

In Bezug auf die Leistung müssen Sie sich festsetzen Was Ein Teil deiner App leidet. Ist es die Verarbeitung, die in der WebLogic / Java-Seite der Dinge passiert, den Datenbankzugriff, DNS-Lookups (wenn sie aus irgendeinem Grund ausgeführt werden), Netzwerkprobleme oder etwas auf dem OS?

99% der Zeit wird es Ihr Code sein und wie er mit der Datenbank kommuniziert, die die Dinge hält. Dann wird es Konfiguration der Web-App sein. Über diesen Punkt hinaus werden Sie daran arbeiten, die letzten Millisekunden aus Ihrer App herauszuquetschen oder eine höhere Parallelität mit der gleichen Hardware zu erreichen. Für dieses feinkörnigere Performance-Tuning benötigen Sie Metriken.

Für Java würde ich vorschlagen, zu installieren Java-Melodie. Es kann eine Menge von Informationen über das, was Ihr Programm tut, und Hilfe eingrenzen, wo es Zeit verbringt. Ich habe es nur mit Tomcat verwendet, sollte aber mit jedem Java EE Container / Servlet Thingy funktionieren.

Es gibt eine Reihe von Möglichkeiten, wie Sie Java optimieren können. Sehen Sie sich daher ihre Leistungsrichtlinien an (ich bin mir sicher, dass Sie das wahrscheinlich haben) und stellen Sie sicher, dass Sie die richtige Heap-Größe usw. für Ihr Programm einstellen. Java Melody kann Ihnen dabei helfen, die Größe des von Ihnen verwendeten Java-Heapspeichers aufzuspüren sowie herauszufinden, wie stark der Garbage Collector funktioniert / wie oft er Ihr Programm zum Löschen von Objekten unterbricht.

Ich hoffe, das war hilfreich. Wenn Sie weitere Informationen zur Verfügung stellen, kann ich diese Antwort möglicherweise aktualisieren und an Ihre Bedürfnisse anpassen.


30
2018-03-01 00:36



Danke für deine Antwort, wenn mein Vertreter hoch genug wäre, würde ich ihn aufwerten. Aus meiner Erfahrung sind Code- oder SQL-Abfragen meist der Täter. Ich habe ein paar Profiling-Läufe gemacht und konnte keinen Hot Spot finden, weshalb ich anfing, nach grundlegenderen Faktoren zu suchen. Ich werde etwas mehr untersuchen und die Frage aktualisieren, wenn ich mehr finde. - Spiff
Ich würde auch die Ausgabe von 'mpstat 1 5' überprüfen, um die Statistiken pro Prozessor einzusehen und die Spalten "csw" und "syscl" zu betrachten. Von Ihrem vmstat oben sieht es so aus, als würden Sie ziemlich viele Systemaufrufe und Kontextwechsel machen, was den Verdacht von Webtoe bestätigt, dass Sie viele Threads haben (Solaris nennt sie LWPs - LightWeight Processes), die ständig die CPU belästigen. Keiner von ihnen macht sehr viel, wenn sie laufen, aber viele verbringen Zeit, um zu laufen, folglich die hohen Lastmittelwerte. - eirescot


Als Nebenbemerkung enthält der Lastdurchschnitt auch Dinge, die auf Festplattenaktivität warten (d. H. Die Festplatte belästigen), sowie solche, die auf CPU warten, es ist eine Summe von beiden ... also könnten Sie Probleme in der einen oder anderen haben.

Sehen http://en.wikipedia.org/wiki/Load_(computing) "Linux beinhaltet auch [in seinem Lastdurchschnitt] Prozesse in unterbrechungsfreien Schlafzuständen (die normalerweise auf Festplattenaktivität warten)"

Als Nebenbemerkung war das Problem, dass ich einen hohen Lastdurchschnitt hatte, aber auch eine Menge Idle-CPU und eine geringe Festplattenbelegung.

Es scheint, dass zumindest in meinem Fall Threads / Prozesse, die auf E / A warten, im Lastdurchschnitt erscheinen, aber dies tun nicht verursacht eine Erhöhung der Spalte "erwarten". Aber sie sind immer noch I / O-gebunden.

Sie können feststellen, dass dies mit dem folgenden Code der Fall ist, wenn Sie ihn in jruby ausführen (macht nur 100 Threads mit jeder Menge I / O):

100.times { Thread.new { loop { File.open('big', 'w') do |f| f.seek 10_000_000_000; f.puts 'a'; end}}}

Was gibt eine Top-Ausgabe wie folgt:

top - 17:45:32 up 38 days,  2:13,  3 users,  load average: 95.18, 50.29, 23.83
Tasks: 181 total,   1 running, 180 sleeping,   0 stopped,   0 zombie
Cpu(s):  3.5%us, 11.3%sy,  0.0%ni, 85.1%id,  0.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32940904k total, 23239012k used,  9701892k free,   983644k buffers
Swap: 34989560k total,        0k used, 34989560k free,  5268548k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
31866 packrd    18   0 19.9g  12g  11m S 117.0 41.3   4:43.85 java
  912 root      11  -5     0    0    0 S  2.0  0.0   1:40.46 kjournald

Sie können also sehen, dass es viel Idle-CPU, 0,0% Wa, aber einen sehr hohen Lastdurchschnitt hat.

Ähnlich zeigt iostat die Festplatte als im Grunde leer:

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
       9.62    0.00    8.75    0.00    0.00   81.62

Device:         rrqm/s   wrqm/s   r/s   w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00    49.00  0.00  6.40     0.00   221.60    69.25     0.01    0.81   0.66   0.42
sda1              0.00    49.00  0.00  6.40     0.00   221.60    69.25     0.01    0.81   0.66   0.42
sda2              0.00     0.00  0.00  0.00     0.00     0.00     0.00     0.00    0.00   0.00   0.00

siehe auch http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html

Als weitere Randnotiz scheint dies auch zu bedeuten, dass (zumindest in diesem Fall - laufendes CentOS) der Lastdurchschnitt jeden Thread einzeln in den Gesamtwert einbezieht.


19
2017-07-19 17:46



"Ladedurchschnitt enthält auch Dinge, die auf Festplattenaktivität warten" unter Linux, während diese Frage ursprünglich über Solaris war, welche scheint nur laufende und ausführbare (d. h. warten auf CPU) Tasks im Lastdurchschnitt zu enthalten. Eine Linux-Version dieser Frage ist diese. - Nickolay


Hatte das gleiche Problem heute. Nach einigen Recherchen und Diagnosen stellte ich fest, dass mein kleines VPS war Die Festplatte ist leer.

In Shell / Eingabeaufforderung (Linux / Unix)

df -h

zu sehen Festplatte frei auf deiner Maschine. Wenn Sie keine Festplatte mehr haben, kann das Problem sein.


6
2018-01-23 17:36



Würdest du dann tauschen, nehme ich an, also hat es das verursacht? - rogerdpack


Ein anderes nützliches Werkzeug, das in dieser Situation helfen wird, ist nmon.

Es enthält eine Vielzahl von Möglichkeiten, dieselben Daten, die von den anderen Tools präsentiert werden, in einem kleinen Paket anzuzeigen.

Wenn dies Inhalte sind, die nicht zwischengespeichert werden können, würde ich empfehlen, mehrere Server hinter einen Load Balancer wie haproxy im tcp-Modus zu stellen, um die Last zu verteilen.


3
2017-07-19 18:17





Um nur einige zu nennen, einige Solaris-spezifische Tools, die beim Debuggen solcher Probleme nicht erwähnt wurden, sind "intrstat", "mpstat" und "lockstat". Nachdem auf einem Host, auf dem einige schwere ETL-Lasten laufen, ein ähnliches Problem aufgetreten war, zeigte mpstat eine hohe Anzahl von Interrupts, die mit vielen I / O-Operationen zu tun hatten, die auf das Problem hindeuteten.

Zu der Zeit, auf einem T4-4 mit mpstat, sahen wir, dass vcpus mehr als 30000 Interrupts über einen kurzen Überwachungszyklus übergab, woraufhin die Leistung darunter zu leiden begann. In diesem Fall bestand die einzige Problemumgehung darin, mehr CPU-Leistung zu erzeugen. Es wurde jedoch später daran gearbeitet, den Code zu verbessern.

Brendan Gregg hat über die Jahre eine Menge über Performance geschrieben, insbesondere über I / O und ist eine Suche wert, falls Sie mehr erfahren möchten.


1
2018-06-23 14:20