LINUX.ORG.RU

Ну это ж пипец (ядра 2.6.x)


0

0

Конфигурация машины такова: 256 Мб ОЗУ, 2 винта на 40 и 250 гиг соответственно, своп 2 гигабайта, намазанный почти со всем остальным на LVM2.

Проблема: при любом I/O scheduler'е, при любой модели преэмпшона, все процессы считают своим долгом жутко свопиться, причем работать во время этого своппинга фактически невозможно.

Как говорили мне утилиты, при средненькой загрузке машины своп пользовался на 15%. (Напомню, его 2 гига.)

Попробовал любопытства ради swapoff -a. Был жуткий вой, использование свопа на 100%, каждый байтик, наверно, облизывался раз по пять, после чего ядро, явно обидевшись, отвалило мне иксы и все, что в них запущено.

Это при том при всем, что до 2.6.12 ядра работали вполне корректно, этой шняги не наблюдалось. После съезда на 2.6.15 и LVM2 шняга начала наблюдаться.

Сейчас работаю на 2.4.32, так вот, там этих затыков нет, все работает как аццкие часы. Внимание, вопрос: чего такого там наколотили разработчики ядра и как с этим бороться? А то мне для счастья еще Suspend 2 нужен, коего для 2.4 нет.

★★★★★

может лучше в lkml спросить?

fghj ★★★★★
()

512 рамы, 2 Г своп, LVM2, прочитал два раза, оба раза удивился. За время миграции 2.6.11-12-14-15 такого не наблюдал. Вопрос соответственно такой: как конфигурировал ядра? У самого с 12 на 14 отламывались iptables при make oldconfig, а может жёсткий сыпаться начал?

Lumi ★★★★★
()

>Проблема: при любом I/O scheduler'е, при любой модели преэмпшона, все процессы считают своим долгом жутко свопиться, причем работать во время этого своппинга фактически невозможно.

echo 10 > /proc/sys/vm/swappiness
echo 1000 > /proc/sys/vm/vfs_cache_pressure
echo cfq > /sys/block/hda/queue/scheduler

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

Можешь навскидку сказать, где в Documentation/ имеется описание этого хозяйства? Я верю, что это может помочь, но хочу с пониманием дела, а не по вендузячьи :-).

Ага, кстати, я привык к тому, что память используется на 90-95%. Во время Больших Затыков ее использование падало до 40-50%, что нормальным назвать никак низзя -- ни тебе кэшей, ни тебе ни фига, да и впечатление такое, будто бы каждый malloc() сперва в свопе выделяет страницы, а потом уже перекачивает их наверх.

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

>Можешь навскидку сказать, где в Documentation/ имеется описание этого хозяйства?

К сожалению - нет. Но на первые два параметра найдёшь кучу ссылок хоть на этом форуме через поиск (вообще - копать в алгоритмы работы swap), последний (cfq io schedule) - опять же на форуме был предложен, но снижение тормозов системы на интенсивных дисковых операциях очень даже заметно. Т.е. вообще перестаёт тормозить :) (на сколько помню, cfq-шедулер обеспечивает таймслайсы дисковых операций для любых процессов независимо от загрузки дисковой системы).

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

>Ага, кстати, я привык к тому, что память используется на 90-95%. Во время Больших Затыков ее использование падало до 40-50%, что нормальным назвать никак низзя

Да, собственно, за такое поведение и отвечает vfs_cache_pressure

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

У меня там и был cfq. На anticipatory системе даже немного полегчало, должен заметить.

Бесит одно. Неужели так было сложно сделать умолчательные параметры аналогичными прекрасно работавшим в 2.4? Но это уже в Talks вопрос %)

Впрочем, лезть в ядро буду тогда, когда инет восстановится. Пока что всем отвечавшим большая спасиба (в т. ч. в linux-talks@c.j.r., где этот разговор начался).

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