Rata-rata beban tinggi, penggunaan CPU rendah - mengapa?

Kami melihat masalah kinerja yang sangat besar pada aplikasi web dan kami berusaha menemukan hambatannya. Saya bukan sysadmin jadi ada beberapa hal yang saya tidak mengerti. Beberapa investigasi dasar menunjukkan CPU menjadi idle, banyak memori yang tersedia, tidak ada pertukaran, tidak ada I / O, tetapi beban rata-rata yang tinggi.

Tumpukan perangkat lunak pada server ini terlihat seperti ini:

• Solaris 10
• Jawa 1.6
• WebLogic 10.3.5 (8 domain)

Aplikasi yang berjalan di server ini berbicara dengan database Oracle di server yang berbeda.

Server ini memiliki 32GB RAM dan 10 CPU (saya pikir).

Berlari prstat -Zmemberi sesuatu seperti ini:

   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

Saya mengerti bahwa sebagian besar CPU idle, tetapi rata-rata beban tinggi, yang cukup aneh bagi saya. Memori sepertinya tidak menjadi masalah.

Berlari vmstat 15memberi sesuatu seperti ini:

 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

Saya mengerti bahwa sebagian besar CPU idle, tidak ada proses yang menunggu dalam antrian untuk dieksekusi, sedikit swapping terjadi.

Berjalan iostat 15memberikan ini:

   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

Menjalankan netstat -i 15memberi yang berikut:

    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

Apa yang saya lewatkan?

Dengan beberapa penyelidikan lebih lanjut, tampak bahwa masalah kinerja sebagian besar disebabkan oleh banyaknya panggilan jaringan antara dua sistem (Oracle SSXA dan UCM). Panggilannya cepat tetapi banyak dan serial, karenanya penggunaan CPU yang rendah (kebanyakan menunggu I / O), rata-rata beban tinggi (banyak panggilan menunggu untuk diproses) dan terutama waktu respons yang panjang (dengan akumulasi waktu respons kecil).

Terima kasih atas wawasan Anda tentang masalah ini!

Ketika Anda mengatakan 'Rata-rata Beban Tinggi', saya berasumsi maksud Anda prstat menunjukkan 'rata-rata beban' di bagian bawah angka output dari

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

Angka-angka ini, terlihat mirip dengan yang disediakan di atas dan mungkin berarti ukuran antrian rata-rata dari proses yang berjalan. Ini bukan persentase waktu prosesor yang digunakan tetapi berapa banyak 'hal' yang mengganggu CPU untuk waktu berjalan. Memang, ini memang terlihat cukup tinggi tetapi ini semua tergantung pada aplikasi yang Anda jalankan; proses mungkin tidak benar-benar melakukan banyak setelah mereka mendapatkan slot mereka. Lihat di sini untuk penjelasan yang bagus mengenai top.

Saya tidak terbiasa dengan WebLogic tetapi saya perhatikan bahwa, secara umum, dengan Tomcat Apache banyak utas Java dapat muncul secara bersamaan untuk apa yang tampak sebagai tidak banyak permintaan. Bisa jadi ini yang menyebabkan angka-angka beban rata-rata tinggi. Pastikan Anda menggunakan pooling koneksi yang sesuai untuk terhubung ke backend dan pertimbangkan untuk menambah jumlah thread idle yang tersedia untuk aplikasi Anda untuk menangani koneksi (tidak yakin bagaimana Anda melakukan ini di WebLogic; Tomcat memiliki pooling per konektor atau kumpulan utas pelaksana umum). Jika Anda tidak melakukan ini, maka utas baru mungkin muncul untuk memproses permintaan.

Mengenai kinerja, Anda perlu menentukan bagian mana dari aplikasi yang Anda derita. Apakah itu proses yang terjadi di sisi WebLogic / Java, akses database, pencarian DNS (jika mereka dilakukan untuk beberapa alasan ...), masalah jaringan atau sesuatu pada OS.

99% dari waktu itu akan menjadi kode Anda dan bagaimana itu berbicara ke database yang menahan segalanya. Maka itu akan menjadi konfigurasi aplikasi web. Melewati titik ini Anda akan berusaha menekan milidetik terakhir dari aplikasi Anda atau melihat memberikan konkurensi lebih tinggi dengan perangkat keras yang sama. Untuk penyempurnaan kinerja berbutir halus ini Anda perlu metrik.

Untuk Java saya sarankan menginstal Java Melody . Ini dapat memberikan banyak info mengenai apa yang sedang dilakukan program Anda dan membantu mempersempit waktu yang dihabiskannya. Saya hanya menggunakannya dengan Tomcat tetapi harus bekerja dengan baik dengan wadah Java EE / servlet apapun.

Ada beberapa cara Anda bisa menyetel Java, jadi lihatlah pedoman kinerja mereka (saya yakin Anda mungkin sudah memilikinya) dan pastikan Anda mengatur Heap Size yang benar, dll. Cocok untuk program Anda. Java Melody dapat membantu Anda melacak ukuran tumpukan Java yang Anda konsumsi serta seberapa keras pengumpul sampah bekerja / seberapa sering mengganggu program Anda untuk membersihkan objek.

Saya harap itu bermanfaat. Jika Anda memberikan informasi lebih lanjut, saya mungkin dapat memperbarui jawaban ini dan lebih mengasahnya sesuai kebutuhan Anda.

Sebagai catatan, rata-rata memuat juga termasuk hal-hal yang menunggu aktivitas disk (yaitu melecehkan disk) serta yang menunggu cpu, ini adalah jumlah keduanya ... sehingga Anda mungkin memiliki masalah di satu atau yang lain.

Lihat http://en.wikipedia.org/wiki/Load_(computing) "Linux juga menyertakan proses [dalam load rata-rata] dalam kondisi tidur yang tidak terputus (biasanya menunggu aktivitas disk)"

Sebagai catatan, masalah khusus yang saya temui adalah bahwa saya memiliki rata-rata beban tinggi, tetapi juga banyak CPU kosong dan penggunaan disk yang rendah.

Tampaknya, setidaknya dalam kasus saya, terkadang utas / proses menunggu I / O muncul di rata-rata beban, tetapi tidak menyebabkan peningkatan pada kolom "menunggu". Tapi mereka masih terikat I / O.

Anda dapat mengatakan bahwa ini adalah kasus dengan kode berikut, jika Anda menjalankannya di jruby (cukup lakukan 100 utas dengan masing-masing I / O):

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

Yang memberikan output top seperti ini:

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

Jadi Anda dapat melihat bahwa ia memiliki banyak CPU idle, 0,0% wa, tetapi rata-rata beban sangat tinggi.

iostat juga menunjukkan disk pada dasarnya idle:

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

lihat juga http://linuxgazette.net/141/misc/lg/tracking_load_average_issues.html

Sebagai catatan tambahan, ini juga tampaknya menyiratkan bahwa (setidaknya dalam hal ini - menjalankan CentOS) rata-rata beban mencakup setiap utas secara terpisah dalam total.

Punya masalah yang sama hari ini. Setelah beberapa penelitian dan diagnosa saya menyadari bahwa VPS kecil saya kehabisan disk .

Dalam shell / prompt (Linux / Unix) ketik

df -h

untuk melihat disk bebas di mesin Anda. Jika Anda kehabisan disk yang bisa menjadi masalah / masalah.

Alat lain yang bermanfaat yang akan membantu dalam situasi ini adalah nmon.

Ini mencakup berbagai cara untuk melihat data yang sama yang disajikan oleh alat lain, dalam satu paket kecil.

Jika ini adalah konten yang tidak bisa di-cache saya akan merekomendasikan menempatkan beberapa server di belakang penyeimbang beban seperti haproxy dalam mode tcp untuk mendistribusikan beban.

Hanya untuk menambah ini, beberapa alat khusus Solaris yang belum disebutkan yang berguna dalam men-debug masalah tersebut adalah "intrstat", "mpstat" dan "lockstat". Setelah mengalami masalah yang sama sebelumnya pada host yang menjalankan beberapa beban ETL yang berat, mpstat mengungkapkan sejumlah besar gangguan yang berhubungan dengan banyak I / O yang mengisyaratkan masalah ini.

Pada saat itu, pada T4-4 dengan mpstat kami melihat vcpus memberikan lebih dari 30000 gangguan selama siklus pemantauan pendek, setelah itu kinerja mulai menurun. Dalam hal ini satu-satunya solusi adalah dengan melemparkan lebih banyak CPU pada itu, pekerjaan kemudian dilakukan untuk meningkatkan kode.

Brendan Gregg telah menulis banyak tentang kinerja, terutama di sekitar I / O selama bertahun-tahun dan layak untuk dicari jika Anda ingin tahu lebih banyak.