Vraag Hoog belastingsgemiddelde, laag CPU-gebruik - waarom?


We zien enorme prestatieproblemen in een webtoepassing en we proberen de bottleneck te vinden. Ik ben geen systeembeheerder dus er zijn dingen die ik niet helemaal snap. Een basisonderzoek toont aan dat de CPU inactief is, dat er veel geheugen beschikbaar is, dat er niet wordt geruild, dat er geen I / O is, maar dat er een hoge gemiddelde belasting is.

De softwarestack op deze server ziet er als volgt uit:

  • Solaris 10
  • Java 1.6
  • WebLogic 10.3.5 (8 domeinen)

De toepassingen die op deze server worden uitgevoerd, spreken met een Oracle-database op een andere server.

Deze server heeft 32GB RAM en 10 CPU's (denk ik).

hardlopen prstat -Z geeft zoiets als dit:

   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

Ik begrijp dat de CPU meestal niet actief is, maar het gemiddelde belasting is hoog, en dat vind ik nogal vreemd. Geheugen lijkt geen probleem te zijn.

hardlopen vmstat 15 geeft zoiets als dit:

 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

Ik begrijp dat de CPU meestal inactief is, er geen processen wachten in de wachtrij om te worden uitgevoerd, weinig wisselen gebeurt.

hardlopen iostat 15 geeft dit:

   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

hardlopen netstat -i 15 geeft het volgende:

    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

Wat mis ik?


71
2018-02-29 22:29


oorsprong


Ik ben niet thuis bij Solaris, dus ik zal dit aan iemand anders doorgeven, maar ik begin met het bekijken van je webserverconfiguratie. Misschien bewaart iets de uitvoering kunstmatig zodanig dat er veel threads in de wachtrij staan. (Niet zeker wat dat zou kunnen zijn of zelfs als het mogelijk is, hoewel). Maar een pluim voor een goed geschreven vraag. - SmallClanger
10 CPU's (denk ik) is mogelijk het probleem. U moet nauwkeuriger weten welke hardware u gebruikt voordat u verder onderzoek doet. Gebruik psrinfo -v om het werkelijke aantal CPU's weer te geven. - jlliagre
Ik heb nog nooit van deze opdracht gehoord, maar als het wordt uitgevoerd, ziet het ernaar uit dat er ongeveer 250 virtuele processors zijn. Klopt dat eigenlijk? In dat geval zou een belastinggemiddelde van 50 onbeduidend zijn? - Spiff
Ik denk dat dit ook kan gebeuren als je schijf vol is. Ik had dit vandaag met 1% vrije ruimte op / en de lading bleef toenemen tot voorbij 19.00 zonder zichtbare reden. Een beetje ruimte vrij maken loste het probleem op (kort nadat het was gevallen); kan ook een toeval zijn. - nh2


antwoorden:


Bij nader onderzoek blijkt dat het prestatieprobleem grotendeels te wijten is aan een groot aantal netwerkaanroepen tussen twee systemen (Oracle SSXA en UCM). De oproepen zijn snel, maar voldoende en in serie verdeeld, vandaar het lage CPU-gebruik (meestal wachtend op I / O), het hoge belastingsgemiddelde (veel wachtende oproepen om te worden verwerkt) en vooral de lange responstijden (door accumulatie van kleine reactietijden).

Bedankt voor uw inzicht in dit probleem!


39
2018-03-02 15:15





Als u 'Hoge belasting gemiddeld' zegt, neem ik aan dat u hiermee bedoelt dat prstat aangeeft voor 'belastingsgemiddelde' onderaan de uitvoercijfers van

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

Deze getallen lijken op de bovenvermelde getallen en betekenen waarschijnlijk de gemiddelde wachtrijgrootte van het lopende proces. Dit is niet het percentage van de gebruikte processortijd, maar hoeveel 'dingen' de CPU lastig vallen om te worden uitgevoerd. Toegegeven, deze zien er vrij hoog uit, maar dit hangt allemaal af van de app die je gebruikt; de processen voeren misschien niet echt veel uit als ze hun slot hebben. Zien hier voor een leuke uitleg over top.

Ik ben niet bekend met WebLogic, maar ik heb gemerkt dat, in het algemeen, met Apache Tomcat veel Java-threads gelijktijdig kunnen worden voortgebracht voor wat er als niet veel verzoeken worden weergegeven. Dit kan de oorzaak zijn van die hoge gemiddelde belastingsaantallen. Zorg ervoor dat u verbindingspooling gebruikt waar nodig om verbinding te maken met de backend en overweeg het aantal inactieve threads dat beschikbaar is voor uw app om verbindingen af ​​te handelen (niet zeker hoe u dit doet op WebLogic; Tomcat heeft een per-thread pool of een thread pool van algemene uitvoerder). Als u dit niet doet, kunnen splinternieuwe threads worden gebruikt voor het verwerken van aanvragen.

Wat betreft de prestaties, moet je nagaan wat een deel van je app lijdt. Is het de verwerking die plaatsvindt in de WebLogic / Java-kant van dingen, de databasetoegang, DNS-lookups (als ze om een ​​of andere reden worden gedaan ...), netwerkproblemen of iets in het besturingssysteem.

99% van de tijd zal het jouw code zijn en hoe het praat met de database die dingen in de hand houdt. Dan zal het de configuratie van de webapp zijn. Voorbij dit punt zul je werken aan het uitpersen van de laatste milliseconden uit je app of aan het bieden van hogere gelijktijdigheid met dezelfde hardware. Voor deze subtielere prestatiemeting heb je statistieken nodig.

Voor Java zou ik willen voorstellen om te installeren Java Melody. Het kan veel informatie geven over wat uw programma aan het doen is en u helpen bepalen waar het tijd doorbrengt. Ik heb het alleen met Tomcat gebruikt, maar zou goed moeten werken met elk Java EE-container / servlet dingetje.

Er zijn een aantal manieren waarop je Java kunt afstemmen, dus bekijk hun prestatierichtlijnen (ik ben er zeker van dat je dit waarschijnlijk hebt) en zorg ervoor dat je de juiste Heap-maat etc. instelt die geschikt is voor jouw programma. Java Melody kan je helpen om de grootte van de door jou gebruikte hoeveelheid Java op te sporen, en ook hoe hard de afvalverzamelaar werkt / hoe vaak hij je programma onderbreekt om objecten te wissen.

Ik hoop dat dit nuttig was. Als u meer informatie opgeeft, kan ik dit antwoord mogelijk bijwerken en beter afstemmen op uw behoeften.


30
2018-03-01 00:36



Bedankt voor uw antwoord, als mijn vertegenwoordiger hoog genoeg zou zijn, zou ik het overstemmen. Van mijn ervaringscode of SQL zijn de vragen gewoonlijk de beklaagde. Ik deed een aantal profilering runs en kon geen hot spot vinden, daarom ging ik op zoek naar meer fundamentele factoren. Ik zal nog meer onderzoeken en de vraag bijwerken als ik meer vind. - Spiff
Ik zou ook de uitvoer van 'mpstat 1 5' controleren om de statistieken per processor te bekijken en de kolommen 'csw' en 'syscl' te bekijken. Vanuit je vmstat hierboven ziet het ernaar uit dat je behoorlijk veel systeemaanroepen en context-switches doet, wat de neiging van webtoe wil bewijzen dat je veel threads hebt (Solaris noemt ze LWPs- LightWeight-processen) die constant de CPU lastig vallen. Geen van hen doet veel als ze aan het rennen zijn, maar velen brengen tijd door met wachten om te rennen, vandaar de hoge belastinggemiddelden. - eirescot


Als een kanttekening, omvat het laadgemiddelde ook dingen die wachten op schijfactiviteit (dat wil zeggen de schijf lastig vallen) evenals diegenen die wachten op cpu, het is een optelsom van beide ... dus u kunt problemen hebben in de ene of de andere.

Zien http://en.wikipedia.org/wiki/Load_(computing) "Linux omvat ook [in zijn belastingsgemiddelde] processen in niet-onderbreekbare slaapstanden (meestal wachtend op schijfactiviteit)"

Als een kanttekening, het specifieke probleem dat ik tegenkwam was dat ik hoge belasting gemiddeld had, maar ook veel idle cpu en een laag schijfgebruik.

Het lijkt erop dat, althans in mijn geval, soms threads / processen die wachten op I / O verschijnen in het gemiddelde van de belasting, maar doen dat wel niet een toename van de kolom "afwachten" veroorzaken. Maar ze zijn nog steeds I / O gebonden.

Je kunt zien dat dit het geval is met de volgende code, als je het in jruby uitvoert (doet alleen 100 threads met veel I / O elk):

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

Wat een topoutput geeft als deze:

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

U kunt dus zien dat het veel lege cpu's heeft, 0,0% wa, maar een zeer hoog belastingsgemiddelde.

iostat toont de schijf op dezelfde manier als inactief:

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

zie ook http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html

Als een verdere kanttekening lijkt dit ook te impliceren dat (althans in dit geval - CentOS draaien) het ladingsgemiddelde elke thread apart in het totaal omvat.


19
2017-07-19 17:46



"laadgemiddelde bevat ook dingen die wachten op schijfactiviteit" op Linux, terwijl deze vraag oorspronkelijk over Solaris ging, welke lijkt alleen lopende en uitvoerbare (dat wil zeggen wachten op CPU) taken op te nemen in gemiddelde belasting. Eén Linux-versie van deze vraag is deze. - Nickolay


Had vandaag hetzelfde probleem. Na wat onderzoek en diagnoses realiseerde ik me dat mijn kleine VPS was onvoldoende schijf.

In shell / prompt (Linux / Unix) type

df -h

om de ... te zien schijf vrij op uw machine. Als de schijf bijna op is, kan dit het probleem / probleem zijn.


6
2018-01-23 17:36



was je aan het ruilen, neem ik aan, dus dat veroorzaakte het? - rogerdpack


Een andere handige tool die in deze situatie zal helpen is nmon.

Het bevat verschillende manieren om dezelfde gegevens te bekijken die door de andere hulpmiddelen worden gepresenteerd, in één klein pakket.

Als dit inhoud is die niet in de cache kan worden geplaatst, raad ik aan om meerdere servers achter een load-balancer, zoals haproxy, in de tcp-modus te plaatsen om de belasting te verdelen.


3
2017-07-19 18:17





Gewoon om hieraan toe te voegen, sommige Solaris-specifieke hulpprogramma's die niet zijn genoemd en die nuttig zijn bij het debuggen van dergelijke problemen, zijn "intrstat", "mpstat" en "lockstat". Na een soortgelijk probleem eerder te hebben ervaren op een host met een aantal zware ETL-belastingen, onthulde mpstat een grote hoeveelheid interrupts die te maken hadden met veel I / O die op het probleem wezen.

Op dat moment zagen we op een T4-4 met mpstat dat vcpus meer dan 30000 interrupts overhandigde tijdens een korte controlecyclus, waarna de performance begon te lijden. In dit geval was de enige oplossing echter om er meer CPU naartoe te gooien. Vervolgens werd gewerkt om de code te verbeteren.

Brendan Gregg heeft veel geschreven over de uitvoering, vooral over I / O door de jaren heen en is de moeite van het zoeken waard als je meer wilt weten.


1
2018-06-23 14:20