Вопрос: Высокая загрузка, низкая загрузка процессора - почему?


Мы видим огромные проблемы с производительностью в веб-приложении, и мы пытаемся найти узкое место. Я не системный администратор, поэтому есть некоторые вещи, которые я не совсем понимаю. Некоторое базовое исследование показывает, что CPU остается бездействующим, много доступной памяти, без обмена, без ввода-вывода, но с высокой средней нагрузкой.

Программный стек на этом сервере выглядит следующим образом:

  • Solaris 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

Что мне не хватает?


66
2018-02-29 22:29


Источник


Я не дома с Solaris, поэтому я буду откладывать для кого-то другого для этого, но я бы начал искать конфигурацию вашего веб-сервера. Возможно, что-то искусственно приводит в действие производительность таким образом, чтобы оставить много потоков в очереди выполнения. (Не уверен, что это может быть или даже если это возможно, хотя). Правда, за хорошо написанный вопрос. - SmallClanger
10 процессоров (я думаю) возможно, проблема. Вы должны точно знать, какое оборудование вы используете, прежде чем расследовать это. использование psrinfo -v для отображения фактического количества процессоров. - jlliagre
Я никогда не слышал об этой команде, но при ее запуске выглядит примерно 250 виртуальных процессоров. Это даже имеет смысл? В этом случае среднее значение нагрузки 50 было бы незначительным? - Spiff
Я думаю, что это также может произойти, когда ваш диск заполнен. У меня было это сегодня с 1% свободного места на / и загрузка продолжала расти до тех пор, пока 19.00 без видимых причин. Создание свободного пространства позволило решить проблему (вскоре после ее схода); также может быть совпадением. - nh2


Ответы:


С некоторыми дальнейшими исследованиями, похоже, что проблема с производительностью связана в основном с большим количеством сетевых вызовов между двумя системами (Oracle SSXA и UCM). Вызовы бывают быстрыми, но много и сериализованы, следовательно, низкое использование ЦП (в основном ожидая ввода-вывода), среднее значение средней нагрузки (многие вызовы ждут обработки) и особенно длительное время отклика (путем накопления небольшого времени отклика).

Спасибо за понимание этой проблемы!


38
2018-03-02 15:15





Когда вы говорите «High Load average», я предполагаю, что вы имеете в виду, что 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-мелодия, Он может предоставить много информации о том, что делает ваша программа, и помочь сузить место, где он проводит время. Я использовал его только с Tomcat, но должен отлично работать с любым контейнером / сервлетом Java EE.

Существует несколько способов настройки Java, поэтому ознакомьтесь с их рекомендациями по эффективности (я уверен, что у вас есть) и убедитесь, что вы устанавливаете правильный размер кучи и т. Д., Подходящий для вашей программы. Java Мелодия может помочь вам отслеживать размер кучи Java, который вы потребляете, а также насколько сложно работает сборщик мусора / как часто он прерывает вашу программу для очистки объектов.

Надеюсь, это было полезно. Если вы предоставите более подробную информацию, я могу обновить этот ответ и отточить его больше в соответствии с вашими потребностями.


30
2018-03-01 00:36



Спасибо за ваш ответ, если бы мой представитель был достаточно высоким, я бы поднял его. Из моего опыта код или SQL-запросы обычно являются виновниками. Я сделал несколько профайлов и не смог найти горячую точку, поэтому я начал смотреть на более фундаментальные факторы. Я исследую еще несколько вопросов и обновляю вопрос, поскольку я нахожу больше. - Spiff
Я также проверил вывод «mpstat 1 5», чтобы просмотреть статистику каждого процессора и посмотреть столбцы «csw» и «syscl». Из вашего vmstat выше это похоже на то, что вы выполняете довольно много системных вызовов и переключателей контекста, которые, похоже, подтверждают подозрение webtoe, что у вас много потоков (Solaris называет их LWPs-LightWeight Processes), постоянно преследуя CPU. Ни один из них не делает очень много, когда они работают, но многие тратят время на ожидание, поэтому средние значения средней нагрузки. - eirescot


В качестве побочной заметки среднее значение нагрузки также включает в себя вещи, ожидающие активности диска (т. Е. Издевательства над диском), а также ожидающих процессора, это сумма обоих ... так что у вас могут быть проблемы в одном или другом.

Видеть http://en.wikipedia.org/wiki/Load_(computing) «Linux также включает в себя [в своих усредненных нагрузках] процессы в состояниях бесперебойного сна (обычно ожидающих активности диска)»

В качестве побочной заметки особая проблема, с которой я столкнулся, заключалась в том, что у меня было среднее значение средней загрузки, но также было много незанятого процессора и низкого использования диска.

Похоже, что, по крайней мере, в моем случае, иногда потоки / процессы, ожидающие ввода / вывода, отображаются в среднем по загрузке, но делают не вызывают увеличение столбца «ожидание». Но они все еще связаны с I / O.

Вы можете сказать, что это имеет место со следующим кодом, если вы запустили его в 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% ва, но очень высокая средняя загрузка.

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_issues.html

В качестве дополнительной дополнительной заметки это также, по-видимому, означает, что (по крайней мере, в этом случае - запуск CentOS) среднее значение нагрузки включает каждую нить отдельно в общей сумме.


19
2017-07-19 17:46





Сегодня такая же проблема. После некоторых исследований и диагнозов я понял, что мой маленький VPS был исчерпание диска,

В shell / prompt (Linux / Unix)

df -h

чтобы увидеть свободный диск на вашей машине. Если у вас заканчивается диск, который может быть проблемой / проблемой.


6
2018-01-23 17:36



я полагаю, вы меняете, так что это вызвало это? - rogerdpack


Другим полезным инструментом, который поможет в этой ситуации, является nmon.

Он включает в себя множество способов просмотра одних и тех же данных, представленных другими инструментами, в одном маленьком пакете.

Если это контент, который нельзя кэшировать, я бы рекомендовал разместить несколько серверов за балансировщиком нагрузки, например, haproxy в режиме tcp, чтобы распределить нагрузку.


3
2017-07-19 18:17





Чтобы добавить к этому, некоторые специальные инструменты Solaris, которые не были упомянуты, которые полезны при отладке таких проблем, - это «intrstat», «mpstat» и «lockstat». Испытав аналогичную проблему, прежде чем на хосте, который запускает некоторые тяжелые нагрузки ETL, mpstat обнаружил большое количество прерываний, связанных с большим количеством ввода-вывода, которые намекали на проблему.

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

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


0
2018-06-23 14:20