есть ли какие-нибудь инструменты для определения причины высокой загрузки процессора? Общая картина:
локальная сеть с вечерним онлайном в 400 компьютеров. трафик в это время ~40Mbit/30Mbit (down/up). Шлюз - Intel(R) Pentium(R) D CPU 3.00GHz, 512 DDR2.
Загрузка процессора может быть более 90%. Почти всё это занятно под "system" (как показывает vmstat).
грешил на количество прерываний, ибо много написано статей на эту тему. в качестве проверки собрал тестовый шлюз на процессоре Duron 750MHz. Сквозной трафик - почти 100Мбит. загрузка процессора - 50%. количество прерываний ~26k/s. На рабочем шлюзе вечером не больше 15к. То есть не похоже, что из-за прерываний. Так же не похоже, что из за трафика (если смотреть только на скорость).Отсюда вопрос: как можно определить на что конкретно уходит процессорное время? на определение маршрута пакета? на поддержку connection tracking? на что-то ещё?
Дисковая активность ~0. Других процессов почти нет, на них загрузка ~0. Slackware 11. Linux 2.4.31
А top что говорит?
>А top что говорит?top - 10:13:32 up 7 days, 23:15, 1 user, load average: 0.00, 0.02, 0.00
Tasks: 16 total, 1 running, 15 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0% user, 30.6% system, 0.0% nice, 69.4% idle
Mem: 191056k total, 85620k used, 105436k free, 29876k buffers
Swap: 0k total, 0k used, 0k free, 14028k cachedPID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1 root 9 0 244 244 216 S 0.0 0.1 2:16.73 init [3]
2 root 9 0 0 0 0 S 0.0 0.0 0:00.00 [keventd]
3 root 19 19 0 0 0 S 0.0 0.0 316:25.32 [ksoftirqd_CPU0]
4 root 9 0 0 0 0 S 0.0 0.0 0:00.00 [kswapd]
5 root 9 0 0 0 0 S 0.0 0.0 0:00.00 [bdflush]
6 root 9 0 0 0 0 S 0.0 0.0 0:38.07 [kupdated]
10 root -1 -20 0 0 0 S 0.0 0.0 0:00.00 [mdrecoveryd]
11 root 9 0 0 0 0 S 0.0 0.0 0:08.95 [kjournald]
65 root 9 0 684 680 576 S 0.0 0.4 0:26.51 /usr/sbin/syslogd
68 root 9 0 456 456 400 S 0.0 0.2 0:07.54 /usr/sbin/klogd -c 3 -x
161 root 9 0 1480 1480 1224 S 0.0 0.8 0:00.02 /usr/sbin/sshd
168 root 8 0 624 624 536 S 0.0 0.3 0:18.14 /usr/sbin/crond -l10
197 root 9 0 484 484 432 S 0.0 0.3 0:00.00 /sbin/agetty 38400 tty1 linux
4886 root 9 0 1732 1732 1428 S 0.0 0.9 0:01.11 sshd: root@pts/0
4889 root 15 0 1460 1460 1112 S 0.0 0.8 0:00.19 -bash
4906 root 16 0 1052 1052 848 R 0.0 0.6 0:00.01 topот вечернего top'a этот отличается только загрузкой cpu - меньше idle - больше system.
> 316:25.32 [ksoftirqd_CPU0]Фигассе... : ) Похоже ядро сильно озадачено оброботкой прерываний, действительно. Но это скорее не процессор, а матушка виновата.
>> 316:25.32 [ksoftirqd_CPU0]
>
>Фигассе... : ) Похоже ядро сильно озадачено оброботкой прерываний, действительно. Но это
>скорее не процессор, а матушка виновата.316 минут за 8 дней - это много???
>316 минут за 8 дней - это много???ХЗ, у меня ни на одном из серверов такого не наблюдается. Но 2% от общего времени - как-то субъективно дохрена. А что за сетевушки используете?
>ХЗ, у меня ни на одном из серверов такого не наблюдается. Но
задумался :( вспомнил: дабы ещё подпортить значимость этих минут - как раз на этих выходных, флудер один нам жизнь портил - в сумме часа 3-4 кидался тучей пакетов. сервер "очень медленно" отвечал. загружен был по самое не балуйся. думаю, что в это время ksoftirqd_CPU0 должен был "набрать" много процессорных тиков.>2% от общего времени - как-то субъективно дохрена. А что за
>сетевушки используете?
чип rtl8139.
>>ХЗ, у меня ни на одном из серверов такого не наблюдается. Но
>задумался :( вспомнил: дабы ещё подпортить значимость этих минут - как раз
>на этих выходных, флудер один нам жизнь портил - в сумме
>часа 3-4 кидался тучей пакетов. сервер "очень медленно" отвечал. загружен был
>по самое не балуйся. думаю, что в это время ksoftirqd_CPU0 должен
>был "набрать" много процессорных тиков.Я тут почитал немного про softirq - как и предполагал, это обработка событий, в частности - сетевых: http://www.linux.org/docs/ldp/howto/KernelAnalysis-HOWTO-5.html
Потому когда идет большой нагруз по сети - вполне может быть, что и натикало. А ядро нагружено сетевыми правилами - там, пару сотен маршрутов или тысячу iptables-правил?
>>2% от общего времени - как-то субъективно дохрена. А что за
>>сетевушки используете?
>чип rtl8139.Хм... А карточки гарантированно рабочие? Может сбоит, в результате чего обработчик ядра и провисает?
>А ядро нагружено сетевыми правилами - там, пару сотен
>маршрутов или тысячу iptables-правил?
если правильно понял про маршруты:
ip r | wc -l
11(iptables -vnxL ; iptables -t nat -vnxL; iptables -t mangle -vnxL)| wc -l
43вот где цифирь побольше:
cat /proc/slabinfo | grep conn
ip_conntrack 49586 76973 288 5268 5921 1и тут:
ip -s r list cache | wc -l
15100>>>2% от общего времени - как-то субъективно дохрена. А что за
>>>сетевушки используете?
>>чип rtl8139.
>
>Хм... А карточки гарантированно рабочие? Может сбоит, в результате чего обработчик ядра
>и провисает?
не знаю, что ответить. как проверить их 100%-ную рабочесть? дать сквозной трафик 100Мб? флуд-пинг? это мысль. попробую ночью.
лагов не замечено. пинг непрерывается. лампочки мигают :) чипы холодные.
как ещё?
>как ещё?Поменять на другие : )
>>> 316:25.32 [ksoftirqd_CPU0]
>>
>>Фигассе... : ) Похоже ядро сильно озадачено оброботкой прерываний, действительно. Но это
>>скорее не процессор, а матушка виновата.
>
>316 минут за 8 дней - это много???Это очень дохрена.
На самом загруженном сервере:
# uptime
12:12:23 up 54 days, 21:14, 3 users, load average: 29.15, 21.83, 17.70
0:26.44 ksoftirqd/0Проверь мать, сетевуху.
>Это очень дохрена.
>На самом загруженном сервере:
># uptime
> 12:12:23 up 54 days, 21:14, 3 users, load average:
>29.15, 21.83, 17.70
>0:26.44 ksoftirqd/0
>
>Проверь мать, сетевуху.а чем занята машина? тоже шлюз или что-то другое? если шлюз, то какой трафик через него бегает?
когда-то давно на одной из шлюзовых машинах наблюдалась подобная картина - высокая загрузка процессора (тоже под system всё уходило). ksoftirqd_CPU0 набирал процессорное время ГОРАЗДО активнее - если правильно помню, прибавлял примерно 1 секунду за 2 секунды прошедшего времени. тут хотя бы всё видно: процессор занят и видно его подсистема, на которую уходит время. а сейчас картина несколько иная - процессор занят, но по top'у точно не скажешь, на что уходит время.
>На самом загруженном сервере:
># uptime
> 12:12:23 up 54 days, 21:14, 3 users, load average:
>29.15, 21.83, 17.70
>0:26.44 ksoftirqd/0
а можешь показать результат следующего: ?
vmstat 2 3
>>На самом загруженном сервере:
>># uptime
>> 12:12:23 up 54 days, 21:14, 3 users, load average:
>>29.15, 21.83, 17.70
>>0:26.44 ksoftirqd/0
>а можешь показать результат следующего: ?
> vmstat 2 3Да, пожалуйста.
~ # vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
12 0 2788 718164 233052 1768316 0 0 1 1 0 1 64 7 30 0
10 0 2788 714168 233052 1768316 0 0 0 320 2015 1652 86 12 2 0
4 0 2788 709816 233052 1768424 0 0 0 200 2110 2132 82 10 8 0
6 0 2788 710952 233052 1768424 0 0 0 0 2115 1783 75 7 17 0
2 0 2788 710800 233052 1768500 0 0 0 0 2154 1907 72 7 21 0
9 0 2788 710504 233052 1768500 0 0 0 296 1906 1533 77 7 16 0
Ув. Сергей. Не могли Бы Вы отписать на irсобакаtrytek.ru
У меня схожая проблема.