Tải trung bình cao, sử dụng CPU thấp - tại sao?

Chúng tôi đang gặp vấn đề lớn về hiệu suất trên một ứng dụng web và chúng tôi đang cố gắng tìm ra nút cổ chai. Tôi không phải là một sysadmin nên có một số thứ tôi không nhận được. Một số điều tra cơ bản cho thấy CPU không hoạt động, có rất nhiều bộ nhớ, không trao đổi, không có I / O, nhưng tải trung bình cao.

Ngăn xếp phần mềm trên máy chủ này trông như thế này:

• Solaris 10
• Java 1.6
• WebLogic 10.3.5 (8 tên miền)

Các ứng dụng chạy trên máy chủ này nói chuyện với cơ sở dữ liệu Oracle trên một máy chủ khác.

Máy chủ này có 32GB RAM và 10 CPU (tôi nghĩ vậy).

Chạy prstat -Zcho một cái gì đó như thế này:

   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

Tôi hiểu rằng CPU chủ yếu là nhàn rỗi, nhưng mức tải trung bình cao, điều này khá lạ đối với tôi. Bộ nhớ dường như không phải là một vấn đề.

Chạy vmstat 15cho một cái gì đó như thế này:

 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

Tôi hiểu rằng CPU chủ yếu là không hoạt động, không có quá trình nào đang chờ trong hàng đợi để được thực thi, việc hoán đổi nhỏ đang diễn ra.

Chạy iostat 15cho điều này:

   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

Chạy netstat -i 15cho sau:

    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

Tôi đang thiếu gì?

Với một số điều tra thêm, có vẻ như vấn đề hiệu năng chủ yếu là do số lượng cuộc gọi mạng lớn giữa hai hệ thống (Oracle SSXA và UCM). Các cuộc gọi nhanh nhưng nhiều và được tuần tự hóa, do đó mức sử dụng CPU thấp (chủ yếu là chờ I / O), trung bình tải cao (nhiều cuộc gọi chờ xử lý) và đặc biệt là thời gian phản hồi dài (bằng cách tích lũy thời gian phản hồi nhỏ).

Cảm ơn bạn đã hiểu biết về vấn đề này!

Khi bạn nói 'Trung bình tải cao' Tôi giả sử bạn có nghĩa là prstat hiển thị cho 'trung bình tải' ở dưới cùng của các số liệu đầu ra của

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

Những con số này, trông tương tự như những con số cung cấp hàng đầu và có thể có nghĩa là kích thước hàng đợi trung bình của quá trình đang chạy. Đây không phải là phần trăm thời gian của bộ xử lý được sử dụng mà là có bao nhiêu "thứ" đang quấy rối CPU để có thời gian chạy. Phải thừa nhận rằng những thứ này trông khá cao nhưng tất cả phụ thuộc vào ứng dụng mà bạn đang chạy; các quy trình có thể không thực sự được thực hiện nhiều khi họ có được vị trí của mình. Xem ở đây để giải thích tốt về đầu trang.

Tôi không quen thuộc với WebLogic nhưng tôi đã nhận thấy rằng, nói chung, với Apache Tomcat, nhiều luồng Java có thể được sinh ra đồng thời cho những gì xuất hiện dưới dạng không có nhiều yêu cầu. Nó có thể là điều này gây ra những số tải trung bình cao. Đảm bảo rằng bạn đang sử dụng nhóm kết nối khi thích hợp để kết nối với phụ trợ và xem xét tăng số lượng luồng không có sẵn cho ứng dụng của bạn để xử lý các kết nối (không chắc chắn cách bạn thực hiện điều này trên WebLogic; Tomcat có nhóm luồng kết nối trên mỗi trình kết nối hoặc một nhóm chủ đề thực thi chung). Nếu bạn không làm điều này thì các chủ đề hoàn toàn mới có thể được sinh ra để xử lý các yêu cầu.

Về hiệu suất, bạn cần tìm hiểu xem phần nào trong ứng dụng của bạn đang bị ảnh hưởng. Có phải đó là quá trình xử lý đang diễn ra ở phía WebLogic / Java, truy cập cơ sở dữ liệu, tra cứu DNS (nếu chúng được thực hiện vì một số lý do ...), các sự cố mạng hoặc một cái gì đó trên HĐH.

99% thời gian sẽ là mã của bạn và cách nó nói chuyện với cơ sở dữ liệu đang giữ mọi thứ. Sau đó, nó sẽ là cấu hình của ứng dụng web. Quá thời điểm này, bạn sẽ làm việc để vắt những mili giây cuối cùng ra khỏi ứng dụng của mình hoặc xem xét việc cung cấp đồng thời cao hơn với cùng phần cứng. Đối với điều chỉnh hiệu suất chi tiết tốt hơn này, bạn cần số liệu.

Đối với Java, tôi khuyên bạn nên cài đặt Java Melody . Nó có thể cung cấp rất nhiều thông tin liên quan đến những gì chương trình của bạn đang làm và giúp thu hẹp thời gian sử dụng. Tôi chỉ sử dụng nó với Tomcat nhưng sẽ hoạt động tốt với bất kỳ bộ chứa / dịch vụ Java EE nào.

Có một số cách bạn có thể điều chỉnh Java, vì vậy hãy xem hướng dẫn hiệu suất của chúng (tôi chắc chắn bạn có thể có) và đảm bảo rằng bạn đang đặt Kích thước Heap chính xác, v.v. phù hợp với chương trình của bạn. Java Melody có thể giúp bạn theo dõi kích thước của đống Java mà bạn đang tiêu thụ cũng như mức độ khó của trình thu gom rác / tần suất làm gián đoạn chương trình của bạn để xóa các đối tượng.

Tôi hy vọng điều đó đã có ích. Nếu bạn cung cấp thêm thông tin, tôi có thể cập nhật câu trả lời này và trau dồi nó nhiều hơn theo nhu cầu của bạn.

Một lưu ý phụ, tải trung bình cũng bao gồm những thứ đang chờ hoạt động của đĩa (tức là quấy rối đĩa) cũng như những thứ đang chờ cpu, đó là tổng của cả hai ... vì vậy bạn có thể gặp vấn đề ở cái này hay cái khác.

Xem http://en.wikipedia.org/wiki/Load_(computing) "Linux cũng bao gồm các quy trình [trong mức trung bình tải] của nó trong trạng thái ngủ không bị gián đoạn (thường chờ hoạt động của đĩa)"

Một lưu ý phụ, vấn đề cụ thể tôi gặp phải là tôi có tải trung bình cao, nhưng cũng có rất nhiều cpu nhàn rỗi và sử dụng đĩa thấp.

Dường như, ít nhất là trong trường hợp của tôi, đôi khi các luồng / tiến trình chờ I / O hiển thị trong mức trung bình tải, nhưng không gây ra sự gia tăng trong cột "chờ đợi". Nhưng họ vẫn bị ràng buộc I / O.

Bạn có thể nói rằng đây là trường hợp với đoạn mã sau, nếu bạn chạy nó trong jruby (chỉ thực hiện 100 luồng với rất nhiều I / O mỗi):

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

Cung cấp một đầu ra hàng đầu như thế này:

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

Vì vậy, bạn có thể thấy rằng nó có rất nhiều cpu nhàn rỗi, 0,0% wa, nhưng tải trung bình rất cao.

iostat tương tự hiển thị đĩa về cơ bản là nhàn rỗi:

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

xem thêm http://linuxgazette.net/141/misc/lg/tracking_load_alusive_issues.html

Một lưu ý nữa, điều này dường như cũng ngụ ý rằng (ít nhất là trong trường hợp này - chạy CentOS) trung bình tải bao gồm mỗi luồng riêng biệt trong tổng số.

Có vấn đề tương tự ngày hôm nay. Sau một số nghiên cứu và chẩn đoán tôi nhận ra rằng VPS nhỏ của tôi đã hết đĩa .

Trong kiểu shell / prompt (Linux / Unix)

df -h

để xem đĩa miễn phí trên máy của bạn. Nếu bạn đang chạy ra khỏi đĩa có thể là vấn đề / vấn đề.

Một công cụ hữu ích khác sẽ giúp trong tình huống này là nmon.

Nó bao gồm nhiều cách khác nhau để xem cùng một dữ liệu được trình bày bởi các công cụ khác, trong một gói nhỏ.

Nếu đây là nội dung không thể lưu trong bộ nhớ cache, tôi khuyên bạn nên đặt nhiều máy chủ phía sau bộ cân bằng tải như haproxy ở chế độ tcp để phân phối tải.

Chỉ cần thêm vào điều này, một số công cụ cụ thể của Solaris chưa được đề cập có ích trong việc gỡ lỗi các vấn đề như vậy là "xâm nhập", "mpstat" và "lockstat". Đã trải qua một vấn đề tương tự trước đây trên một máy chủ đang chạy một số tải ETL nặng, mpstat đã tiết lộ một số lượng lớn các ngắt xử lý nhiều I / O gợi ý về vấn đề này.

Vào thời điểm đó, trên một T4-4 với mpstat, chúng tôi đã thấy vcpus chuyển giao vượt quá 30000 ngắt trong chu kỳ giám sát ngắn, sau đó hiệu suất bắt đầu bị ảnh hưởng. Trong trường hợp này, cách giải quyết duy nhất là ném thêm CPU vào nó, tuy nhiên, công việc sau đó đã được thực hiện để cải thiện mã.

Brendan Gregg đã viết rất nhiều về hiệu suất, đặc biệt là xung quanh I / O trong những năm qua và đáng để tìm kiếm nếu bạn muốn tìm hiểu thêm.