Високе середнє завантаження, низьке використання процесора - чому?

У веб-додатку ми спостерігаємо величезні проблеми з продуктивністю, і ми намагаємося знайти вузьке місце. Я не сисадмін, тому є деякі речі, які я не дуже розумію. Деякі базові дослідження показують, що центральний процесор працює в режимі очікування, багато пам'яті має бути доступною, без заміни, без вводу-виводу, але високе середнє навантаження.

Програмний стек на цьому сервері виглядає приблизно так:

• Соляріс 10
• Java 1.6
• WebLogic 10.3.5 (8 доменів)

Програми, що працюють на цьому сервері, розмовляють із базою даних Oracle на іншому сервері.

Цей сервер має 32 ГБ оперативної пам’яті та 10 процесорів (я думаю).

Біг prstat -Zдає щось подібне:

   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

Я розумію, що процесор здебільшого простоює, але середня завантаженість висока, що для мене досить дивно. Пам'ять, здається, не є проблемою.

Біг vmstat 15дає щось подібне:

 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

Я розумію, що процесор здебільшого простоює, жодні процеси не чекають у черзі, яку слід виконати, мало міняється місцями.

Біг iostat 15дає це:

   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

Біг netstat -i 15дає наступне:

    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

Що я пропускаю?

З деяким подальшим розслідуванням виявляється, що проблема продуктивності здебільшого пов’язана з великою кількістю мережевих дзвінків між двома системами (Oracle SSXA та UCM). Виклики швидкі, але великі та серіалізовані, отже, низьке використання процесора (в основному чекає вводу-виводу), високе середнє завантаження (багато дзвінків, які очікують на обробку) та особливо тривалий час відгуку (за рахунок накопичення малих часів відповіді).

Дякуємо за ваше розуміння цієї проблеми!

Коли ви говорите "Високе середнє навантаження", я вважаю, що ви маєте на увазі, що prstat показує "середнє навантаження" внизу вихідних цифр

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

Ці цифри виглядають схожими на ті, які надає верх, і, ймовірно, означають середній розмір черги запущеного процесу. Це не відсоток використовуваного часу процесора, а скільки «речей», які переслідують процесор за час його роботи. Справді, вони виглядають досить високо, але все це залежить від програми, яку ви працюєте; процеси, можливо, насправді не роблять багато чого, як тільки вони отримують свій слот. Дивіться тут гарне пояснення щодо верху.

Я не знайомий з WebLogic, але я помітив, що, як правило, за допомогою Apache Tomcat багато потоків Java можуть породжуватися одночасно для того, що видається не так багато запитів. Це може спричинити великі середні навантаження. Переконайтеся, що ви використовуєте пул з'єднань, де це доречно, для підключення до бекенда, і розглянути можливість збільшення кількості непрацюючих потоків, доступних вашій програмі для обробки з'єднань (не впевнено, як це зробити в WebLogic; Tomcat має пул потоків на з'єднувачі або загальний пул потоків виконавців). Якщо цього не зробити, то для обробки запитів можуть створюватися нові теми.

Щодо продуктивності, вам потрібно визначити, яка частина вашої програми страждає. Це обробка, яка відбувається в речах WebLogic / Java, доступ до бази даних, пошук DNS (якщо вони з якихось причин ...), проблеми з мережею чи щось на ОС.

99% часу це буде ваш код і те, як він спілкується з базою даних, яка підтримує речі. Тоді це буде конфігурація веб-програми. Минувши цей момент, ви будете працювати над тим, щоб вичавити останні мілісекунди зі свого додатка або шукати більш високу сумісність з тим же обладнанням. Для цієї тонкої налаштування продуктивності вам потрібні показники.

Для Java я б запропонував встановити Java Melody . Він може надати багато інформації про те, що робить ваша програма, і допоможе звузити місце, де вона проводить час. Я використовував його лише з Tomcat, але повинен добре працювати з будь-яким контейнером / сервлетом Java EE.

Існує кілька способів налаштування Java, тому перегляньте їх рекомендації щодо виконання (я впевнений, що ви, мабуть, є) та переконайтеся, що ви встановлюєте правильний розмір куки тощо, відповідний для вашої програми. Java Melody може допомогти вам відстежити розмір купи Java, який ви споживаєте, а також наскільки важко працює сміттєзбірник / як часто він перериває вашу програму для очищення об'єктів.

Я сподіваюся, що це було корисно. Якщо ви надасте більше інформації, я, можливо, зможу оновити цю відповідь і більше відточити її до ваших потреб.

Як зауваження, середня завантаженість включає також речі, які чекають дискової активності (тобто тормоз диска), а також ті, що чекають на процесор, це сума обох ... так що у вас можуть виникнути проблеми в тому чи іншому.

Див. Http://en.wikipedia.org/wiki/Load_(computing) "Linux також включає [у середній показник завантаження] процеси у станах безперебійного сну (зазвичай чекають активності диска)"

Як зауваження, особливою проблемою, з якою я стикався, було те, що я мав високу середню завантаженість, а також багато непрацюючих процесорів та низьке використання диска.

Здається, що, принаймні в моєму випадку, іноді потоки / процеси, які очікують на введення / виведення, відображаються в середньому навантаженні, але не викликають збільшення стовпця "очікування". Але вони все ще пов'язані вводу-виводу.

Ви можете сказати, що це стосується наступного коду, якщо ви запускаєте його в jruby (всього 100 потоків з великою кількістю вводу-виводу кожного):

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

Що дає такий вихід:

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

Тож ви можете бачити, що він має багато процесорів на холостому ходу, 0,0% wa, але дуже високий середній навантаження.

iostat аналогічно показує диск як непрацюючий:

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

див. також http://linuxgazette.net/141/misc/lg/tracking_load_average_isissue.html

З іншого боку, це також означає, що (принаймні, у цьому випадку - запуск CentOS) середнє навантаження включає кожну нитку окремо в загальну суму.

Була така ж проблема і сьогодні. Після деяких досліджень та діагнозів я зрозумів, що у мого маленького VPS закінчився диск .

У формі shell / prompt (Linux / Unix)

df -h

щоб побачити диск на вашій машині. Якщо у вас не вистачає диска, це може бути проблемою.

Іншим корисним інструментом, який допоможе в цій ситуації, є nmon.

Вона включає в себе різноманітні способи перегляду одних і тих же даних, представлених іншими інструментами, в одному невеликому пакеті.

Якщо це вміст, який неможливо кешувати, я рекомендую розмістити кілька серверів за балансиром навантаження, наприклад, haproxy в режимі tcp для розподілу навантаження.

Додамо до цього, деякі інструменти Solaris, про які не було сказано, які корисні при налагодженні таких питань, є "intrstat", "mpstat" і "lockstat". Випробувавши подібну проблему раніше на хості, який працює з великими навантаженнями ETL, mpstat виявив велику кількість перерв, що стосуються безлічі вводу-виводу, які натякали на проблему.

У той час на T4-4 з mpstat ми бачили, як vcpus передає понад 30000 перерв за короткий цикл моніторингу, після чого продуктивність почала погіршуватися. У цьому випадку єдиним рішенням було кинути на нього більше процесора, однак згодом було проведено роботу над вдосконаленням коду.

Брендан Грегг багато написав про продуктивність, особливо навколо вводу-виводу протягом багатьох років, і варто пошукати, якщо ви хочете дізнатися більше.