ArchLinux? У меня было подобное, прошло с одним из обновлений.

Gentoo.

Linux Superman 2.6.36-gentoo-r5 #4 SMP Wed Mar 2 01:20:21 IST 2011 x86_64 Intel(R) Xeon(R) CPU E5620 @ 2.40GHz GenuineIntel GNU/Linux

Явно виноват софт. Ничего подозрительного в top не заметили?

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)

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

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

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

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

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

Как-то раз было подобное на OpenVZ впс'ке, просто свалил оттуда.

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

Вижу cs (context switch) высокий

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

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

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

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

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

Правильно. Загрузка CPU 0-1% а load average не спускается с 40-50. Процессов D нету.

IOWAIT 0-1%

Murr>ps -e...

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

Tasks: 298 total, 1 running, 297 sleeping, 0 stopped, 0 zombie

Собери стандартный кернел (минимум твоих настроек)

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

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

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

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

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

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

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

Процессов D как таковых нету. Так что не понимаю причину повышенного Load Average.

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

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

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

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

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

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

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

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

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

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

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

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

И вот такое:

egrep «cpu|cfs|nr_running|nr_unint» sched_debug

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

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

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

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

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

(root)-(jobs:0)-(~)
(! 501)-> grep procs /proc/stat
procs_running 6
procs_blocked 0

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

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

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

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

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

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

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

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

>там как раз nr_iowait

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

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

>(! 509)-> iostat 5

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

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

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

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

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

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

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

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

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

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

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

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

да, nr_running тоже.

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

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

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

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

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

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

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

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

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

да, конечно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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