Re: оптимизация дисковой подсистемы (linux multi-disk server howto)
crosspost
On Tue, Dec 25, 2007 at 01:45:46PM +0200, Alexander Vlasov wrote:
> > PreScriptum: раз уж написалось -- даю копию в sysadmins@l.a.o,
> > просьба отвечать (при необходимости) в ту рассылку, где прочитали.
> > > из-за не совсем грамотной настройки - письма не сразу
> > > отвергаются при ошибках во время SMTP сессии (не тот юзер,
> > > переполнен ящик), а сначала получаются а потом отлупливаются
> > > обратно. Load Average поднимается до 1000-1500
> > Насколько помню, на kernel.org проверяли, что на 1024 оно
> > обнуляется, на собственном опыте... ;)
> По моему опыту -- не обнуляется...
Видимо, уже после того, как обнаружили :)
Дровишки времён 2.2, что ли. Или 2.4.
> > [ sdc, sdd: высокая скорость, умеренная ёмкость]
> > sdc1 своп (pri=75)
> > sdd1 своп (pri=75)
> > sdc2 sdd2 спул (RAID1, xfs, noatime?)
> >
> > [ sde, sdf: средняя скорость, повышенная надёжность]
> > sde1 своп (pri=50)
> > sdf1 своп (pri=50)
> > sde2 sdf2 maildirs (RAID1, ext3/xfs, !noatime)
> Это значит смерть машины в случае вылета одного из дисков.
Спасибо, что отрезал про зеркальный своп первого эшелона:
sda1 sdb1 своп (RAID1, pri=100)
> Я зеркалирую своп.
Забыл обратить внимание. Я зеркалирую его тогда, когда совсем не
хочется до машинки добираться по любому чиху бегом (это относится
к критичным или труднодоступным). На остальных обычно всё-таки
стараюсь более приоритетный выносить на менее загруженные диски.
Если шпинделей много, то перечитай полную картинку внимательно.
Подразумевается, что гиг или два или сколько там свопа первой
партии обычно не забиты полностью, а полоски по полгига-гигу ещё
на четырёх дисках лежат на всякий случай: если что-то капитально
протечёт (mailman там), то будет чуть больше времени/возможности
заметить и зафиксить проблему, причём система получит больший
шанс снижаться, а не пикировать.
И заодно -- делать своп по правилу "2*RAM" скорее нет смысла:
если система среднесовременная, _достаточно_ обычно 1*RAM,
а если специфическая (активно используется tmpfs или тот же
контейнерный хостинг с кучей всего, чему в RAM при нормальной
работе болтаться незачем) -- коэффициент может быть много больше
двойки. При этом стоит помнить, что пропускная способность
дисков не поспевает за объёмом их же и RAM => лучше параллелить,
если уж посвапливать.
--
---- WBR, Michael Shigorin <mike@altlinux.ru>
------ Linux.Kiev http://www.linux.kiev.ua/
Reply to: