Yüksek yük ortalama, düşük CPU kullanımı - neden?

Bir web uygulamasında büyük performans sorunları görüyoruz ve tıkanıklığı bulmaya çalışıyoruz. Ben bir sysadmin değilim, bu yüzden pek alamadım bazı şeyler var. Bazı temel araştırmalar CPU'nun boşta olduğunu, çok fazla boş alan olduğunu, takas yapılmadığını, G / Ç olmadığını, ancak ortalama yükün yüksek olduğunu gösteriyor.

Bu sunucudaki yazılım yığını şöyle görünür:

• Solaris 10
• Java 1.6
• WebLogic 10.3.5 (8 alan adı)

Bu sunucuda çalışan uygulamalar, farklı bir sunucudaki Oracle veritabanı ile konuşuyor.

Bu sunucuda 32GB RAM ve 10 CPU var (sanırım).

Koşma prstat -Zböyle bir şey verir:

   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

İşlemcinin çoğunlukla boşta olduğunu anlıyorum, ancak yük ortalaması yüksek, bu da benim için oldukça garip. Hafıza bir sorun gibi görünmüyor.

Koşma vmstat 15böyle bir şey verir:

 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

İşlemcinin çoğunlukla boşta olduğunu, yürütülmesi için sırada hiçbir işlem beklemiyor, az takas oluyor.

Koşu şunu iostat 15verir:

   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

Koşu netstat -i 15aşağıdakileri verir:

    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

Neyi kaçırıyorum?

Bazı araştırmalarla, performans sorununun çoğunlukla iki sistem arasındaki (Oracle SSXA ve UCM) yapılan çok sayıda şebeke çağrısından kaynaklandığı anlaşılıyor. Çağrılar hızlı ancak bol ve seri hale getirildi, bu nedenle düşük CPU kullanımı (çoğunlukla G / Ç için bekliyor), yüksek yük ortalaması (işlenmeyi bekleyen birçok çağrı) ve özellikle uzun yanıt süreleri (küçük yanıt süreleri biriktirerek).

Bu sorunla ilgili görüşünüz için teşekkür ederiz!

'Yüksek Yük Ortalaması' derken, prstat’ın çıktı rakamlarının altında 'yük ortalaması’nı gösterdiğini söylüyorum.

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

Bu sayılar, üst sağlayanlara benziyor ve muhtemelen çalışan işlemin ortalama kuyruk boyutu anlamına geliyor. Bu, kullanılmakta olan işlemci zamanının yüzdesi değil, kaç tane “nesnenin” CPU'yu çalıştırması için rahatsız ettiğini gösteriyor. Kuşkusuz ki, bunlar oldukça yüksek görünüyor, ancak bu, çalıştırmakta olduğunuz uygulamaya bağlıdır; süreçler aslında alanlarına kavuştuktan sonra pek bir şey yapmıyor olabilir. Üst ile ilgili güzel bir açıklama için buraya bakın .

WebLogic'e aşina değilim ama genel olarak Apache Tomcat ile pek çok Java iş parçacığının aynı anda pek çok istek olarak görünmediğinden ortaya çıkarılabileceğini fark ettim. Bu, bu yüksek ortalama yük numaralarına neden olan olabilir. Arka uca bağlanmak için uygun olan yerlerde bağlantı havuzu kullandığınızdan emin olun ve bağlantıları yönetmek için uygulamanız için mevcut olan boşta kalan iş parçacıklarının sayısını artırmayı düşünün (WebLogic'te bunu nasıl yaptığınızdan emin değilsiniz; bir genel uygulayıcı iplik havuzu). Bunu yapmazsanız, istekleri işleme koymak için yepyeni iş parçacıkları üretiliyor olabilir.

Performans olarak, uygulamanızın hangi bölümünün acı çektiğini tespit etmeniz gerekir . Nesnelerin WebLogic / Java tarafında gerçekleşen işlem, veritabanı erişimi, DNS aramaları (eğer bir nedenden dolayı yapılıyorlarsa ...), ağ sorunları veya işletim sistemindeki bir şey.

Zamanın% 99'u sizin kodunuz ve işleri tutan veritabanına nasıl konuştuğu olacaktır. Sonra web uygulamasının yapılandırılması olacak. Bu noktadan sonra, uygulamanızın son milisaniyesini sıkıştırmak veya aynı donanımla daha yüksek eşzamanlılık sağlamaya çalışmak için çalışacaksınız. Bu daha ince taneli performans ayarlaması için metriklere ihtiyacınız vardır.

Java için ben yüklemeden öneririm Java Melodi . Programınızın ne yaptığı hakkında çok fazla bilgi sağlayabilir ve zaman harcadığı yerin daralmasına yardımcı olabilir. Sadece Tomcat ile kullandım ancak herhangi bir Java EE konteyner / sunucu uygulaması ile iyi çalışmalıyım.

Java'yı ayarlamanın çeşitli yolları vardır, bu nedenle performans yönergelerine bakın (muhtemelen sahip olduğunuzdan eminim) ve programınıza uygun doğru Yığın Boyutunu belirlediğinizden emin olun. Java Melodi, tükettiğiniz Java yığınının boyutunu ve çöp toplayıcısının ne kadar çalıştığını / nesnelerin temizlenmesi için programınızın ne sıklıkta kesintiye uğradığını izlemenize yardımcı olabilir.

Umarım yardımcı olmuştur. Daha fazla bilgi verirseniz, bu cevabı güncelleyebilir ve ihtiyaçlarınızı daha doğru bilebilirim.

Bir yan not olarak, yükleme ortalaması ayrıca disk aktivitesi için bekleyenleri (yani diski taciz eden) ve cpu'yu bekleyenleri içerir, bu ikisinin toplamıdır, yani birinde veya diğerinde sorun olabilir.

Bkz. Http://en.wikipedia.org/wiki/Load_(computing) "Linux, kesintisiz uyku durumlarında (genellikle disk etkinliğini bekliyor) [yük ortalamalarında] işlemleri de içeriyor"

Bir yan not olarak, karşılaştığım özel sorun, yüksek yük ortalamamın yanı sıra çok fazla boşta cpu ve düşük disk kullanımım olmasıydı.

En azından benim durumumda, bazen G / Ç için bekleyen iş parçacığı / işlemlerinin yük ortalamasında göründüğü, ancak "bekle" sütununda bir artışa neden olmadığı görülüyor . Ama hala G / Ç bağlılar.

Bunun şu şekilde olduğunu söyleyebilirsiniz, eğer çalılık içinde çalıştırırsanız (her biri 100 G / Ç ile sadece 100 iş parçacığı yapar):

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

Bunun gibi bir üst çıktı verir:

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

Bu yüzden,% 0.0 wa, ama çok yüksek bir yük ortalamasının çok fazla boşta cpu değerine sahip olduğunu görebilirsiniz.

iostat da benzer şekilde diski temel olarak boşta gösterir:

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

ayrıca bkz. http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html

Diğer bir not olarak, bu aynı zamanda (en azından bu durumda - CentOS çalıştıran) yük ortalamasının toplamda her bir dişi ayrı ayrı içerdiği anlamına gelir.

Bugün aynı problem vardı. Bazı araştırma ve teşhislerden sonra, küçük VPS'imin disk tükendiğini anladım .

Kabuk / istemde (Linux / Unix) yazın

df -h

diski makinenizde ücretsiz görmek için . Disk tükeniyorsa, bu sorun / sorun olabilir.

Bu durumda yardımcı olacak başka bir faydalı araç nmon olduğunu.

Diğer araçlar tarafından sunulan aynı verileri tek bir küçük pakette görüntülemek için çeşitli yollar içerir.

Bu, önbelleğe alınamayan bir içerik ise, yükü dağıtmak için tcp modunda haproxy gibi bir yük dengeleyicisinin arkasına birden fazla sunucu yerleştirmenizi tavsiye ederim.

Sadece buna ek olarak, söz konusu sorunların ayıklanmasında yararlı olan bazı Solaris'e özgü araçlar "intrstat", "mpstat" ve "lockstat" dır. Daha önce de bazı ağır ETL yüklerini çalıştıran bir ana bilgisayarda benzer bir sorun yaşamamış mpstat, konuyu ima eden çok sayıda G / Ç ile ilgili olarak yüksek miktarda kesinti olduğunu ortaya koydu.

O sırada, mpstat'lı bir T4-4'te kısa takip döngüsü boyunca 30000'den fazla vcpus'un teslim edildiğini gördük, ardından performans acı çekmeye başladı. Bu durumda tek geçici çözüm ona daha fazla CPU atmaktı ancak daha sonra kodu geliştirmek için çalışmalar yapıldı.

Brendan Gregg, yıllar boyunca özellikle G / Ç civarında performans hakkında çok şey yazdı ve daha fazla bilgi edinmek istiyorsanız araştırmaya değer.