LINUX.ORG.RU

Высокий Load Average | Низкий CPU USAGE


0

1

Сабж.


top - 01:50:27 up 1 day, 21 min, 6 users, load average: 43.10, 41.23, 39.65
Tasks: 298 total, 1 running, 297 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.0%us, 0.0%sy, 0.0%ni, 99.3%id, 0.7%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16464136k total, 8256904k used, 8207232k free, 308128k buffers
Swap: 3929036k total, 0k used, 3929036k free, 4071032k cached



(root)-(jobs:0)-(~)
(! 499)-> vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 0 8208852 308140 4071048 0 0 4 30 2 6 0 0 100 0
0 0 0 8208968 308140 4071048 0 0 0 0 5089 32912 0 0 100 0
1 0 0 8208100 308140 4071052 0 0 0 256 5109 32528 0 0 99 1
0 0 0 8207976 308140 4071048 0 0 0 132 5176 32502 0 0 99 1
0 0 0 8207976 308140 4071048 0 0 0 0 5036 32218 0 0 100 0
0 0 0 8208108 308140 4071052 0 0 0 140 5173 32208 0 0 99 1
0 0 0 8208108 308140 4071048 0 0 0 0 5079 32125 0 0 100 0
0 0 0 8208232 308140 4071048 0 0 0 0 5204 32183 0 0 100 0


(root)-(jobs:0)-(~)
(! 500)-> free -m
total used free shared buffers cached
Mem: 16078 8060 8017 0 300 3975
-/+ buffers/cache: 3784 12294
Swap: 3836 0 3836


P.S: Хардварный RAID-0.

04:00.0 RAID bus controller: Hewlett-Packard Company Smart Array G6 controllers (rev 01)

NIC: 05:00.0 Ethernet controller: Intel Corporation 82576 Gigabit Network Connection (rev 01)

al1as ()
Ответ на: комментарий от FakeLinux

Тоже так думаю. Вообще-то на этой машине пускаю игровые сервера. (hlds_i686).

Серверный FPS нестабильный. Подозреваю что выноват CONFIG_HZ=250 в конфиге ядра.

al1as ()
Ответ на: комментарий от al1as

Проверяйте логи, особенно на предмет наличия дисковой активности или ошибок, связанных с RAID. Проверьте, может, какой-то сервис (или сам игровой сервер) каким-то образом создает high IO (к примеру, игровой сервер может срать в лог), ради этой цели можете воспользоваться iotop. Попробуйте на время убрать swap. Если ничего, выводите информацию а нагрузке железа через cron.

FakeLinux ()
Ответ на: комментарий от FakeLinux

Каким образом можно отследить процесс который вызывает высокий I/O?

iotop пустует, раз в 5 секунд на хард записываются 5-10 килобайт, не более.

al1as ()
Ответ на: комментарий от tensai_cirno

В данном случае я хостер, так что сваливать некуда)

al1as ()
Ответ на: комментарий от sdio

Гуглил но так и не нашёл дорогу понизить cs. Есть ли ман на эту тему?

al1as ()
Ответ на: комментарий от Murr

R = Running? Или я ошибаюсь?

По моим наблюдением у процесса Top state всегда R.

Со state-ом D, процессов нету, что и подозрительно. :/

al1as ()
Ответ на: комментарий от al1as

Ничего не понял, если честно. То есть многократные последовательные запуски ps|egrep показывают, что в R|D только 1 нить, но при этом load average на протяжении 15 минут стабильно порядка 40?

Murr ★★ ()

что-то я не понял...

Высокий Load Average | Низкий CPU USAGE


а что здесь странного? UNINTERRUPTIBLE tasks (D) считаются «active».
идея в том, что они, скорее всего, ждут i/o.

см, например kernel/sched.c:calc_load_fold_active()

раньше вообще был nr_active (или как-то так) который просто
считал nr_running + nr_uninterruptible.

idle ★★★★★ ()
Ответ на: комментарий от sdio

Придётся собирать по новой. Есть ли какие либо рекомендации по оптимизации системы для многозадачность?

З.Ы: Игровых серверов несколько десятков.

al1as ()

Та же самая проблема с clearos... как ловить засранца, непонятно.

pekmop1024 ★★★★★ ()
Ответ на: комментарий от al1as

> Процессов D как таковых нету.

Хард юзается по минимуму.


тогда не знаю...

у тебя 2.6.36. я начинаю смутно вспоминать, вроде были
проблемы с accounting после всех оптимизаций...

к примеру, 0f004f5a696a9434b7214d0d3cbd0525ee77d428 из
2.6.37 «looks promising», но точно не скажу.

idle ★★★★★ ()
Ответ на: комментарий от sdio

>Разве ты в топовом сообщении не видел?

Видел, и что дальше?

Murr ★★ ()
Ответ на: комментарий от idle

>идея в том, что они, скорее всего, ждут i/o.

Идею на современном этапе там понять вообще сложно, поскольку ждущие i/o считаются как nr_iowait.

Murr ★★ ()
Ответ на: комментарий от Murr

> ждущие i/o считаются как nr_iowait

да, но io_schedule() & friends появились сравнительно
недавно, а nr_interruptible как active со времен динозавров
(наверное).

к тому же, тут не обязательно i/o. тут, скорее, такое
рассуждение: если он D, то он ждет события, которое должно
наступить «скоро», а так-то он как бы и running, те готов
работать.

и вообще, D процессов, _по идее_, должно быть мало. если
это не так - сигнализируем через loadvg.

понятно, что все это «ненаучно», но эта метрика в любом
случае не может быть точной.

idle ★★★★★ ()
Ответ на: комментарий от Murr

> А что показывает grep procs /proc/stat?

вот. там как раз nr_iowait(). но он только показывает
сколько их «прямо сейчас».

к тому же ТС говорит, диск не используется.

но посмотреть, конечно, стоит.

idle ★★★★★ ()
Ответ на: комментарий от Murr

(root)-(jobs:0)-(~)
(! 506)-> egrep «cpu|cfs|nr_running|nr_unint» /proc/sched_debug
egrep: /proc/sched_debug: No such file or directory

al1as ()
Ответ на: комментарий от idle

>понятно, что все это «ненаучно», но эта метрика в любом

случае не может быть точной.

В каком смысле точной? Она может быть вполне точной (если считать не по стремной формуле, позаимствованной из BSD, а через среднее арифметическое с 15-минутной историей, например, а лучше обновлять при каждом изменении nr_running/nr_uninterruptible). Другое дело, что сейчас она не только криво считается, но и не имеет никакого разумного смысла.

Murr ★★ ()
Ответ на: комментарий от idle

>там как раз nr_iowait

Там «как раз» nr_running, который используется ядром при усреднении (а не просто получается подсчетом из /proc). А в sched_debug - помимо него еще и nr_uninterrutible.

Murr ★★ ()
Ответ на: комментарий от Murr

iostat 5

(root)-(jobs:0)-(~)
(! 509)-> iostat 5
Linux 2.6.36-gentoo-r5 (Superman)    03/04/11    _x86_64_   (16 CPU)

avg-cpu: %user %nice %system %iowait %steal %idle
0.42 0.00 0.14 0.19 0.00 99.25

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 6.66 150.96 541.25 29163928 104561248

avg-cpu: %user %nice %system %iowait %steal %idle
0.96 0.00 0.40 0.04 0.00 98.60

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 1.80 0.00 41.60 0 208

avg-cpu: %user %nice %system %iowait %steal %idle
0.77 0.00 0.04 0.05 0.00 99.14

Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn
cciss/c0d0 2.40 0.00 62.28 0 312

al1as ()
Ответ на: iostat 5 от al1as

>(! 509)-> iostat 5

Это не содержит интересной статистики. И не может, поскольку nr_uninterruptible «в чистом виде» экспортируется только через sched_debug, которого у вас нет.

Я сталкивался с ситуацией, когда nr_uninterruptible счетчики текли, но это было в ядрах, далеких от ванильных.

Murr ★★ ()
Ответ на: комментарий от Murr

> Она может быть вполне точной

ну, не согласен. очень сложно формально определить,
что такое «загруженность» системы.

те, это как раз очень просто, и можно дать сколько
угодно определений. вопрос только в полезности.

не имеет никакого разумного смысла.


это просто вот такая эвристика. она, скорее, historical.
спорить о ее разумности не буду.

по моему, менять ее смысла нет, никто этот loadavg всерьез
не воспринимает сегодня.

обновлять при каждом изменении nr_running/nr_uninterruptible).


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

idle ★★★★★ ()
Ответ на: комментарий от Murr

> > там как раз nr_iowait



Там «как раз» nr_running



да, nr_running тоже.

который используется ядром при усреднении


нет, это не так. rq->nr_running - это именно точное
количество runnable (те, не deactivated) tasks.

idle ★★★★★ ()
Ответ на: комментарий от idle

>да ну. наоборот, стараются минимизировать накладные расходы за счет точности.

Стараются - это не значит, что это правильно. Добавить в общую сумму по rq интервал с последнего изменения nr_running/nr_uninterruptible с весовым коэффициентом, равным их сумме, никаких особых накладных расходов не создаст.

Murr ★★ ()
Ответ на: комментарий от idle

>нет, это не так. rq->nr_running - это именно точное

количество runnable (те, не deactivated) tasks.

nr_running в конкретный момент времени - это точное значение, КОТОРОЕ УСРЕДНЯЕТСЯ СО ВРЕМЕНЕМ.

Murr ★★ ()
Ответ на: комментарий от Murr

> КОТОРОЕ УСРЕДНЯЕТСЯ СО ВРЕМЕНЕМ

а.. ты имел в виду, усредняется в loadavg?

да, конечно.

idle ★★★★★ ()
Ответ на: комментарий от idle

>по моему, менять ее смысла нет, никто этот loadavg всерьез

не воспринимает сегодня.

Ну да, пока там сотни не появляются (ну или десятки, как у автора). :-)

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

Murr ★★ ()
Ответ на: комментарий от Murr

> Добавить в общую сумму по rq интервал c последнего изменения

ну, оно где-то так и есть. или я не понял, что ты
имеешь в виду.

ладно, спор ни о чем. loadavg есть какой есть, вряд
ли существенно поменяют методику.

похоже, у ТС действительно проблемы с accounting и
loadavg просто врет.

я бы попробовал 2.6.37.

idle ★★★★★ ()
Ответ на: комментарий от idle

>ну, оно где-то так и есть.

Ну где-то так есть. С точности до огрубления, которое обусловлено замерами всего раз в 5 секунд. :-)

loadavg есть какой есть

Модуль нормального load average с «историей» - около 100 строк. Для интеграции с /proc/loadavg и sysinfo достаточно в код ядра вставить заглушку-флажок, отключающий встроенный подсчет.

Murr ★★ ()
Ответ на: комментарий от Murr

> пока там сотни не появляются

я ж не имел в виду, что не надо фиксить подсчет ;)

idle ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.