[Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Michael Shigorin]

PreScriptum: раз уж написалось -- даю копию в sysadmins@l.a.o,
просьба отвечать (при необходимости) в ту рассылку, где прочитали.


On Sun, Dec 23, 2007 at 03:01:09PM +0500, Timur S. Sattarov wrote:
> > Мысль была банальная -- грамотная разводка I/O способна
> > помочь ощутимо сильнее крутых рейдов и быстрых дисков самих
> > по себе.  Примеры тому наблюдаю с незавидной регулярностью.
> А где можно почитать про грамотную разводку I/O ?

В т.ч. в Multi-Disk HOWTO.

> может есть примеры из собственного прошлого ?

Разумеется.

> почему спрашиваю - сейчас стоит задача оптимизировать это самое
> I/O некоторое время назад в соседней ветке я  описывал проблему
> с медленными дисками на сервере.

См. ниже.


On Sun, Dec 23, 2007 at 03:43:46PM +0300, Alexey Pechnikov wrote:
> Оптимизация - это настройка СУБД, оптимизация медленных
> запросов.

Ой зависит.  Для рассылочного сервера (с СУБД!) это не даст вааще
ничего ;-)

> На примере постгреса - ставим логирование всех запросов,
> которые выполняются дольше 400 мс (я выбрал такое значение,
> диски SATA) и избавляемся от них. Для того же постгреса
> рекомендуют разделять базы и журналы, но после выполнения
> вышеописанной оптимизации это может и не требоваться. Ну и логи
> отключите (реверс-прокси, веб-сервер...) - можно логировать
> что-то очень нужное, но сохранять все запросы слишком дорогое
> удовольствие.

Это решение "от софта" -- его танцевать полезно, но не всегда
возможно (например, эти самые логи могут быть нужны).  Тогда надо
понимать сильные и слабые стороны используемых ФС и RAID -- и всё
равно при необходимости плясать ещё и от железа.

В случае базы и веб-сервера может иметь смысл для начала
отбросить логи на отдельный диск или массив (физически отдельные
шпиндели).  В зависимости от используемой шины -- возможно, на
отдельный канал или контроллер (для IDE-дисков, где остались --
правило как для SATA: "один шлейф, один девайс").

С файловыми системами тоже не всё просто: из тех, на которых
нормально происходит двустороннее движение, знаю только XFS.
Это на которой элементарно можно потерять данные при внезапном
сбое.  А вот ext3, на которой нет такой security feature, при 
активном r/w способна заткнуться с взлётом LA в небеса и падением
пропускной в моём случае на два порядка (от ~50Mb/s до ~500Kb/s,
это ещё ниже, чем просто разрывающиеся диски).

Для файловых систем, на которых ничто не закладывается на время
доступа к данным (спулеры могут и почто-ньюсочиталки) -- показано
применять опцию монтирования noatime, которая сокращает
количество операций записи на ФС (той же ext3 неплохо помогает).

Про dir_index уже рассказали, на ядрах 2.4 этого не было и с ext3 
на толстых каталогах было просто печально.  Поэтому там жили xfs
с reiserfs.

Журналируемым файловым системам, по крайней мере xfs, по
доверенным слухам здорово помогает вынос журнала на отдельный
шпиндель -- мне тут mithraen@altlinux рассказывал, да всё никак
руки не дойдут попробовать.

> Некорректно сформированные запросы должен блокировать
> реверс-прокси, чтобы они не грузили веб-сервер.

Или mod_security.  Хотя для веба там, где некритично -- может
куда больше помочь инструктирование гугля ходить со средней
частотой (при помощи google webmaster tools), вот кто бы ещё
яндексам рассказал про существующие расширения robots.txt насчёт
частоты... (inktomi, msn, northernlight проще рубить на файрволе
-- всё равно у нас они никому по существу не упали, а тот же msn 
был замечен в игнорировании robots.txt)

> P.S. Настройка системы для "черного ящика" (чужого ПО) весьма
> неблагодарное занятие... По-хорошему, надо настраивать и ПО и
> систему совместно.

Разумеется.  Но есть и относительно общие места.


On Sun, Dec 23, 2007 at 06:35:24PM +0500, Timur S. Sattarov wrote:
> Спасибо за ответ, уточню - есть система, прищедшая по
> наследству, основная задача которой - почта, количество
> пользователей - порядка 20 тысяч, сколько из них активных не
> знаю, может 6-7 тыс.

Есть знакомые провайдеры -- в sysadmins@lists.altlinux...


> свои проблемы со скоростью винтов (20-30 мегабайт в секунду,
> даже с кэшем) я уже выкладывал в соседней ветке.

Дисков-то много и в каком уровне RAID? (сорри, ветку искать лень,
а эту мож ещё почитаю на неделе по скорингу)

> из-за не совсем грамотной настройки - письма не сразу
> отвергаются при ошибках  во время SMTP сессии (не тот юзер,
> переполнен ящик), а сначала получаются а потом отлупливаются
> обратно. Load Average поднимается до 1000-1500

Насколько помню, на kernel.org проверяли, что на 1024 оно
обнуляется, на собственном опыте... ;)

> проц в большинстве своем занят iowait.

Да-да, типичная i/o bound задача.

> после установки валидации пользователей - ситуация улучшилась,
> но бэкап периодически грузит машину, если в это время есть
> приличное количество писем на отправку - то висит куча
> процессов ожидающих ответа от дисковой системы.  Я прекрасно
> понимаю что надо реорганизовывать дисковую подсистему и даже
> уже наметил что-то в качестве решения. И тут поднимается вопрос
> о грамотной разводке I/O, поэтому очень хотелось бы послушать,
> что именно делают другие специалисты для того чтобы *грамотно*
> организовать дисковую подсистему.

Спул в одну сторону (на что-то вроде RAID10 или несколько RAID1
-- у RAID5/6 всё грустно при записи), mailbox'ы или то, куда
почта доставляется -- в другую, логи -- в третью, бэкап -- в
четвёртую.

Здесь речь о физических шпинделях (предположительно зеркалах),
а не о разделах.  Таким образом, на данные получается от 6HDD,
при этом спул может иметь смысл положить на SAS или быстрые SATA
вроде WD Raptor, а доставочные -- а, maildir -- на просто 7200
вроде WD Raid Edition или Hitachi.

Логи можно класть и не на зеркало; бэкап -- если не хватает
посадочных мест, то можно попробовать тоже (и вынимать, когда
не пишется, на другую машинку с более надёжным местом).

Систему можно поставить на тот же диск (или диски), где логи
и бэкап.  Если вжиматься в 6HDD и всовывать их в один ящик,
то это похоже на такой вариант (воспринимать не буквально):

[ sda, sdb: средняя скорость, повышенная надёжность]
sda1	sdb1	своп (RAID1, pri=100)
sda2	sdb2	система (RAID1, ext3, noatime)
sda3		логи (ext3, noatime)
	sdb3	бэкап (ext3, noatime)

[ 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)

Насколько понимаю, на maildir noatime лучше не ставить.

Меньше чем на 4HDD я бы строить не стал.

Про приоритеты свопов (больше=выше) -- см. swapon(2).

Может оказаться хорошо поставить жёсткие квоты на 90--95% 
каждой файловой системы -- в этих пределах наступает затык
по производительности всех известных мне ФС.

Если дисков на самом деле понадобится больше -- стоит озадачиться
материнкой, на которой разведено I/O в плане дисковых
контроллеров и слотов, в которые его можно воткнуть, и сети:
зачастую в недорогих даже серверных платах всё валят на одну
шину, которой быстро плохеет.

Например, ftp.linux.kiev.ua сейчас работает на Foxconn
NFPIK8AA-8EKRS (nForce Pro 2200), где основная шина попросту
продублирована и картинка по части I/O выглядит так:

00:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
00:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
00:09.0 PCI bridge: nVidia Corporation CK804 PCI Bridge (rev a2)
00:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
00:0c.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
00:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

80:00.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:01.0 Memory controller: nVidia Corporation CK804 Memory Controller (rev a3)
80:07.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:08.0 IDE interface: nVidia Corporation CK804 Serial ATA Controller (rev a3)
80:0a.0 Bridge: nVidia Corporation CK804 Ethernet Controller (rev a3)
80:0d.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)
80:0e.0 PCI bridge: nVidia Corporation CK804 PCIE Bridge (rev a3)

Т.е. набортные 8 каналов SATA разбросаны по двум шинам.
Соответственно болтающиеся на них 8HDD друг другу особо 
не мешают (кажется, они разбрасывались вперехлёст, но 
точно уже не помню).

> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6,

Что, ещё не взрывалась?  Хороший повод съехать, рано или поздно 
склонна взрываться (редко, но метко).  Хотя данные обычно
вытаскивали по крайней мере при участии namesys'овского народа.

> я же привык работать с ext3, так как кажется она мне более
> надежной и удобной. Как вы думаете - стоит ли оставаться на
> reieser и, если да, стоит ли переезжать на 4-ю версию ? Почта
> хранится в maildir - при обращении к ящику с большим
> количеством сообщений  система притормаживает.

Если хотите, можете попробовать пойти по такому пути -- насколько
понимаю, выкатывается более другая система взамен существующей?

- протестировать надёжность нового железа, включая диски и память
  (bonnie++ + cpuburn, memtest86, stresslinux...);
- протестировать имеющийся или приходящий бесперебойник, в т.ч. 
  на корректность выключения системы при конце батарейки;
- спланировать дисковую подсистему, глядя в Multi-Disk HOWTO
  и картинку выше;
- собрать серверную часть и попробовать проверить её на стенде
  сгенерированными потоками по SMTP и по возможности -- POP3/IMAP
  (про бенчмарки или load generator'ы тут не знаю, сам бы слал
  муттом, боюсь);
- сбэкапить полученную систему;
- постараться смоделировать нештатные ситуации -- забивание
  разных ФС, отключение питания (как с бесперебойником, так
  и без него -- батареи тоже дохнут) -- контролируя целостность
  пользовательских данных при помощи чего-нить вроде md5deep.

Если всё в порядке -- тогда уже приниматься за перенос данных.


On Sun, Dec 23, 2007 at 06:05:23PM +0300, Alexey Pechnikov wrote:
> А вот бэкап надо реорганизовывать или "размазывать" во времени.
> Например, rsync имеет опцию
> --bwlimit=KBPS          limit I/O bandwidth; KBytes per second
> Может быть, это то, что вам нужно? 

Если у вас уже работает ionice, может иметь смысл пускать сразу
nice rsync -- при этом будет мягче по дискам.  Если не работает
-- может иметь смысл озадачиться своим ядром.

Правда, бэкапы при этом плавно теряют когерентность -- но чтоб
её обеспечить, надо что-то вроде LVM и/или XFS snapshots, а их
мне применять не доводилось.

> Выбираю ext3 за ее надежность; reiserfs имеет иные настройки по
> умолчанию, потому часто рекомендуется для соответствующих задач

Нет.  reiserfs -- другая файловая система, никакими настройками
разницу с ext3 не нивелировать (ни для одной из этих ФС).

Я обычно применяю reiserfs в паре с RAID0, ext3 -- с RAID1, 
xfs -- с RAID1/5.

> но чтение манов по ext3 позволит настроить как минимум не хуже.

Простите, но это попросту не соответствует действительности.

> Для начала на ext3 отключите atime, 

Для rfs оно тоже отключается.  И для xfs -- тоже.

> Еще для вашей задачи стоит попробовать опцию data=journal (в
> /etc/fstab использовать нельзя, надо указывать как параметр
> загрузки)

Это для корня -- Вы держите на корне что-либо критичное к I/O?

> для конкурентного ввода-вывода может оказаться очень полезной.

См. выше про XFS.  В ext3 (и рейзере) нет delayed block
allocation и по словам разработчиков -- непонятно, когда
ещё появится.  Ну и xfs -- extent-based filesystem, в отличие
от ext3, которая оперирует одним экстентом на весь block device,
насколько вообще понимаю.  Это тоже помогает [xfs] прилично
работать в условиях жёсткой конкуренции за i/o.

> P.S. Утилита rm отвратительно работают с большим числом файлов
> в директории.

Ну-ну.


On Sun, Dec 23, 2007 at 09:19:28PM +0300, Alexey Pechnikov wrote:
> > надо будет проследить какое количество одновременных запросов
> > сейчас оптимально, хотя сейчас я думаю не о старой машине а о
> > том как буду организовывать новую.
> Зато у вас есть возможность потестировать на уже работающей
> системе, это полезно.

Полезно -- на стенде.  На старой лучше аккуратно noatime добавить
(mount -o remount,noatime), куда безопасно.


On Sun, Dec 23, 2007 at 09:58:45PM +0300, Alexey Pechnikov wrote:
> Время было около 5 утра, уже сил не было разбираться :-)

Ой, если сил нет -- надо лочить консоль и валить от неё
высыпаться.  Можно ж и не разгрести потом последствия одной
очепяточки, хотя мне пока скорее везло -- даже chown -R .*
небезболезненно, но вышло починить когда-то (дома :).

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Denis Smirnov]

25.12.07, Michael Shigorin<mike@osdn.org.ua> написал(а):

> > На примере постгреса - ставим логирование всех запросов,
> > которые выполняются дольше 400 мс (я выбрал такое значение,
> > диски SATA) и избавляемся от них. Для того же постгреса
> > рекомендуют разделять базы и журналы, но после выполнения
> > вышеописанной оптимизации это может и не требоваться. Ну и логи
> > отключите (реверс-прокси, веб-сервер...) - можно логировать
> > что-то очень нужное, но сохранять все запросы слишком дорогое
> > удовольствие.
> Это решение "от софта" -- его танцевать полезно, но не всегда
> возможно (например, эти самые логи могут быть нужны).  Тогда надо
> понимать сильные и слабые стороны используемых ФС и RAID -- и всё
> равно при необходимости плясать ещё и от железа.

На всякий случай напоминаю любителям пораскидывать все по разным
шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
разным шпинделям может быть ой как полезно.

Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
наследникам конкретной таблицы (необходимо для unique значений), когда
это появится, будет вообще чудесная возможность практически не трогая
frontend выкидывать редко используемые _отдельные row_ на другой
шпиндель.

> В случае базы и веб-сервера может иметь смысл для начала
> отбросить логи на отдельный диск или массив (физически отдельные
> шпиндели).  В зависимости от используемой шины -- возможно, на
> отдельный канал или контроллер (для IDE-дисков, где остались --
> правило как для SATA: "один шлейф, один девайс").

Это вообще святое. Сколько раз на это забивал, и сколько раз это
забивание било граблями очень метко по лбу.

> Для файловых систем, на которых ничто не закладывается на время
> доступа к данным (спулеры могут и почто-ньюсочиталки) -- показано
> применять опцию монтирования noatime, которая сокращает
> количество операций записи на ФС (той же ext3 неплохо помогает).

Это вообще must have.

> Про dir_index уже рассказали, на ядрах 2.4 этого не было и с ext3
> на толстых каталогах было просто печально.  Поэтому там жили xfs
> с reiserfs.
> Журналируемым файловым системам, по крайней мере xfs, по
> доверенным слухам здорово помогает вынос журнала на отдельный
> шпиндель -- мне тут mithraen@altlinux рассказывал, да всё никак
> руки не дойдут попробовать.

По крайней мере везде, где идет работа с большим количеством мелких
файлов помогает просто волшебно.

Самое простое обоснование -- экономия лишних seek, ибо журнал обычно
далеко от того места куда пишем данные :) На xfs еще некоторые
операции могут ограничиваться записью только у журнал (AFAIR если
временный файлик создали, записали в него и быстро прибили до того как
он успел реально отправиться на диск, все эти операции отразятся
только в журнале).

>> Некорректно сформированные запросы должен блокировать
>> реверс-прокси, чтобы они не грузили веб-сервер.
> Или mod_security.  Хотя для веба там, где некритично -- может
> куда больше помочь инструктирование гугля ходить со средней
> частотой (при помощи google webmaster tools), вот кто бы ещё
> яндексам рассказал про существующие расширения robots.txt насчёт
> частоты... (inktomi, msn, northernlight проще рубить на файрволе
> -- всё равно у нас они никому по существу не упали, а тот же msn
> был замечен в игнорировании robots.txt)

Реверс-сервер сам по себе не просто экономит, а ЭКОНОМИТ ресурсы.
Уменьшение требований к ресурсам на порядок я своими глазами видел. Но
это там в оперативку а не диски упирались.

> Спул в одну сторону (на что-то вроде RAID10 или несколько RAID1
> -- у RAID5/6 всё грустно при записи), mailbox'ы или то, куда
> почта доставляется -- в другую, логи -- в третью, бэкап -- в
> четвёртую.

В случае с RAID надо еще не забывать чтобы размер блока у RAID и FS
совпадали. Для RAID0/5 критично.

> Систему можно поставить на тот же диск (или диски), где логи
> и бэкап.  Если вжиматься в 6HDD и всовывать их в один ящик,
> то это похоже на такой вариант (воспринимать не буквально):

Я, кстати, так и делал. Только журнал клал туда же куда и систему (там
машинка маленькая была -- 2 HDD).

> Может оказаться хорошо поставить жёсткие квоты на 90--95%
> каждой файловой системы -- в этих пределах наступает затык
> по производительности всех известных мне ФС.

С квотами я не подружился, а вот приучить мониторинг ругаться
нехорошими словами уже на 80% было полезно.

У меня квоты разве что на vz.

>> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6,
> Что, ещё не взрывалась?  Хороший повод съехать, рано или поздно
> склонна взрываться (редко, но метко).  Хотя данные обычно
> вытаскивали по крайней мере при участии namesys'овского народа.

Там где на данные до такой степени пофиг чтобы ставить reiser уж лучше
xfs. reiser хорошо для кэша squid'а, например. И то это для меня
сейчас скорее теория -- давно с reiser предпочитал не связываться.

> - протестировать надёжность нового железа, включая диски и память
>   (bonnie++ + cpuburn, memtest86, stresslinux...);

wtf stresslinux?

> - собрать серверную часть и попробовать проверить её на стенде
>   сгенерированными потоками по SMTP и по возможности -- POP3/IMAP
>   (про бенчмарки или load generator'ы тут не знаю, сам бы слал
>   муттом, боюсь);

apt-cache show postal

> - сбэкапить полученную систему;
> - постараться смоделировать нештатные ситуации -- забивание
>   разных ФС, отключение питания (как с бесперебойником, так
>   и без него -- батареи тоже дохнут) -- контролируя целостность
>   пользовательских данных при помощи чего-нить вроде md5deep.
> Если всё в порядке -- тогда уже приниматься за перенос данных.

Кстати отключение питание хорошо моделировать с одновременно запущеным
бенчмарком на дисковую. У меня ext3 с data=journal всю жизнь
великолепно выживала резеты. А тут за полгода два фатальных сбоя...

> Правда, бэкапы при этом плавно теряют когерентность -- но чтоб
> её обеспечить, надо что-то вроде LVM и/или XFS snapshots, а их
> мне применять не доводилось.

XFS snapshots лучше применять именно что одновременно с LVM. Некоторое
время назад использовал эту схему -- был очень доволен.

Надо не забывать что при бэкапе некоторых приложений (например СУБД)
этого мало, надо еще их предупреждать заранее что хотим такое
проделать, чтобы их файлы были в когерентном состоянии.

> > Еще для вашей задачи стоит попробовать опцию data=journal (в
> > /etc/fstab использовать нельзя, надо указывать как параметр
> > загрузки)
> Это для корня -- Вы держите на корне что-либо критичное к I/O?

man tune2fs до просветления. В том числе на предмет дефолтов при монтировании.
data=journal, к тому же, не только для экономии на I/O. Скорее
наоборот (хотя на БД действительно почему-то дает и экономию на I/O).

> > для конкурентного ввода-вывода может оказаться очень полезной.
> См. выше про XFS.  В ext3 (и рейзере) нет delayed block
> allocation и по словам разработчиков -- непонятно, когда
> ещё появится.  Ну и xfs -- extent-based filesystem, в отличие
> от ext3, которая оперирует одним экстентом на весь block device,
> насколько вообще понимаю.  Это тоже помогает [xfs] прилично
> работать в условиях жёсткой конкуренции за i/o.

Если я правильно понимаю, то у ext3 "экстентов" именно что нет. Там
блоки. Экстент это нечто вроде "блока переменной длины". Я бы обозвал
даже скорее "кластером переменной длины".

> Ой, если сил нет -- надо лочить консоль и валить от неё
> высыпаться.  Можно ж и не разгрести потом последствия одной
> очепяточки, хотя мне пока скорее везло -- даже chown -R .*
> небезболезненно, но вышло починить когда-то (дома :).

Подтверждаю. Да, вплоть до того что в случае аварийной ситуации гасить
нафиг сервер и идти спать оставив записку и выключив мобильник. Ибо от
того что можно натворить будучи невменяемым за консолью уволят куда
скорее (да и побьют больнее) чем за такую выходку.

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Michael Shigorin]

On Tue, Dec 25, 2007 at 11:39:00AM +0200, I wrote:
> > > Мысль была банальная -- грамотная разводка I/O способна
> > > помочь ощутимо сильнее крутых рейдов и быстрых дисков самих
> > > по себе.  Примеры тому наблюдаю с незавидной регулярностью.
> > А где можно почитать про грамотную разводку I/O ?
> В т.ч. в Multi-Disk HOWTO.

http://tldp.org/HOWTO/Multi-Disk-HOWTO.html

PS: к нему в пару хорошо идёт Partition HOWTO:
http://tldp.org/HOWTO/Partition/index.html

ещё:
http://www.freesource.info/wiki/HCL/XranenieDannyx/SravnenieFajjlovyxSistem
http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID
http://www.freesource.info/wiki/RazbienieDiska

и (несколько устарело, но):
http://people.redhat.com/alikins/system_tuning.html

И вот ещё письмо mithraen@:

---
Date: Tue, 25 Dec 2007 13:14:10 +0300
From: Denis Smirnov
Subject: Re: оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

> > На примере постгреса - ставим логирование всех запросов,
> > которые выполняются дольше 400 мс (я выбрал такое значение,
> > диски SATA) и избавляемся от них. Для того же постгреса
> > рекомендуют разделять базы и журналы, но после выполнения
> > вышеописанной оптимизации это может и не требоваться. Ну и логи
> > отключите (реверс-прокси, веб-сервер...) - можно логировать
> > что-то очень нужное, но сохранять все запросы слишком дорогое
> > удовольствие.
> Это решение "от софта" -- его танцевать полезно, но не всегда
> возможно (например, эти самые логи могут быть нужны).  Тогда надо
> понимать сильные и слабые стороны используемых ФС и RAID -- и всё
> равно при необходимости плясать ещё и от железа.

На всякий случай напоминаю любителям пораскидывать все по разным
шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
разным шпинделям может быть ой как полезно.

Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
наследникам конкретной таблицы (необходимо для unique значений), когда
это появится, будет вообще чудесная возможность практически не трогая
frontend выкидывать редко используемые _отдельные row_ на другой
шпиндель.

> В случае базы и веб-сервера может иметь смысл для начала
> отбросить логи на отдельный диск или массив (физически отдельные
> шпиндели).  В зависимости от используемой шины -- возможно, на
> отдельный канал или контроллер (для IDE-дисков, где остались --
> правило как для SATA: "один шлейф, один девайс").

Это вообще святое. Сколько раз на это забивал, и сколько раз это
забивание било граблями очень метко по лбу.

> Для файловых систем, на которых ничто не закладывается на время
> доступа к данным (спулеры могут и почто-ньюсочиталки) -- показано
> применять опцию монтирования noatime, которая сокращает
> количество операций записи на ФС (той же ext3 неплохо помогает).

Это вообще must have.

> Про dir_index уже рассказали, на ядрах 2.4 этого не было и с ext3
> на толстых каталогах было просто печально.  Поэтому там жили xfs
> с reiserfs.
> Журналируемым файловым системам, по крайней мере xfs, по
> доверенным слухам здорово помогает вынос журнала на отдельный
> шпиндель -- мне тут mithraen@altlinux рассказывал, да всё никак
> руки не дойдут попробовать.

По крайней мере везде, где идет работа с большим количеством мелких
файлов помогает просто волшебно.

Самое простое обоснование -- экономия лишних seek, ибо журнал обычно
далеко от того места куда пишем данные :) На xfs еще некоторые
операции могут ограничиваться записью только у журнал (AFAIR если
временный файлик создали, записали в него и быстро прибили до того как
он успел реально отправиться на диск, все эти операции отразятся
только в журнале).

>> Некорректно сформированные запросы должен блокировать
>> реверс-прокси, чтобы они не грузили веб-сервер.
> Или mod_security.  Хотя для веба там, где некритично -- может
> куда больше помочь инструктирование гугля ходить со средней
> частотой (при помощи google webmaster tools), вот кто бы ещё
> яндексам рассказал про существующие расширения robots.txt насчёт
> частоты... (inktomi, msn, northernlight проще рубить на файрволе
> -- всё равно у нас они никому по существу не упали, а тот же msn
> был замечен в игнорировании robots.txt)

Реверс-сервер сам по себе не просто экономит, а ЭКОНОМИТ ресурсы.
Уменьшение требований к ресурсам на порядок я своими глазами видел. Но
это там в оперативку а не диски упирались.

> Спул в одну сторону (на что-то вроде RAID10 или несколько RAID1
> -- у RAID5/6 всё грустно при записи), mailbox'ы или то, куда
> почта доставляется -- в другую, логи -- в третью, бэкап -- в
> четвёртую.

В случае с RAID надо еще не забывать чтобы размер блока у RAID и FS
совпадали. Для RAID0/5 критично.

> Систему можно поставить на тот же диск (или диски), где логи
> и бэкап.  Если вжиматься в 6HDD и всовывать их в один ящик,
> то это похоже на такой вариант (воспринимать не буквально):

Я, кстати, так и делал. Только журнал клал туда же куда и систему (там
машинка маленькая была -- 2 HDD).

> Может оказаться хорошо поставить жёсткие квоты на 90--95%
> каждой файловой системы -- в этих пределах наступает затык
> по производительности всех известных мне ФС.

С квотами я не подружился, а вот приучить мониторинг ругаться
нехорошими словами уже на 80% было полезно.

У меня квоты разве что на vz.

>> Попутно пара вопросов - в текущей системе стоит reiserfs V3.6,
> Что, ещё не взрывалась?  Хороший повод съехать, рано или поздно
> склонна взрываться (редко, но метко).  Хотя данные обычно
> вытаскивали по крайней мере при участии namesys'овского народа.

Там где на данные до такой степени пофиг чтобы ставить reiser уж лучше
xfs. reiser хорошо для кэша squid'а, например. И то это для меня
сейчас скорее теория -- давно с reiser предпочитал не связываться.

> - протестировать надёжность нового железа, включая диски и память
>   (bonnie++ + cpuburn, memtest86, stresslinux...);

wtf stresslinux?

> - собрать серверную часть и попробовать проверить её на стенде
>   сгенерированными потоками по SMTP и по возможности -- POP3/IMAP
>   (про бенчмарки или load generator'ы тут не знаю, сам бы слал
>   муттом, боюсь);

apt-cache show postal

> - сбэкапить полученную систему;
> - постараться смоделировать нештатные ситуации -- забивание
>   разных ФС, отключение питания (как с бесперебойником, так
>   и без него -- батареи тоже дохнут) -- контролируя целостность
>   пользовательских данных при помощи чего-нить вроде md5deep.
> Если всё в порядке -- тогда уже приниматься за перенос данных.

Кстати отключение питание хорошо моделировать с одновременно запущеным
бенчмарком на дисковую. У меня ext3 с data=journal всю жизнь
великолепно выживала резеты. А тут за полгода два фатальных сбоя...

> Правда, бэкапы при этом плавно теряют когерентность -- но чтоб
> её обеспечить, надо что-то вроде LVM и/или XFS snapshots, а их
> мне применять не доводилось.

XFS snapshots лучше применять именно что одновременно с LVM. Некоторое
время назад использовал эту схему -- был очень доволен.

Надо не забывать что при бэкапе некоторых приложений (например СУБД)
этого мало, надо еще их предупреждать заранее что хотим такое
проделать, чтобы их файлы были в когерентном состоянии.

> > Еще для вашей задачи стоит попробовать опцию data=journal (в
> > /etc/fstab использовать нельзя, надо указывать как параметр
> > загрузки)
> Это для корня -- Вы держите на корне что-либо критичное к I/O?

man tune2fs до просветления. В том числе на предмет дефолтов при монтировании.
data=journal, к тому же, не только для экономии на I/O. Скорее
наоборот (хотя на БД действительно почему-то дает и экономию на I/O).

> > для конкурентного ввода-вывода может оказаться очень полезной.
> См. выше про XFS.  В ext3 (и рейзере) нет delayed block
> allocation и по словам разработчиков -- непонятно, когда
> ещё появится.  Ну и xfs -- extent-based filesystem, в отличие
> от ext3, которая оперирует одним экстентом на весь block device,
> насколько вообще понимаю.  Это тоже помогает [xfs] прилично
> работать в условиях жёсткой конкуренции за i/o.

Если я правильно понимаю, то у ext3 "экстентов" именно что нет. Там
блоки. Экстент это нечто вроде "блока переменной длины". Я бы обозвал
даже скорее "кластером переменной длины".

> Ой, если сил нет -- надо лочить консоль и валить от неё
> высыпаться.  Можно ж и не разгрести потом последствия одной
> очепяточки, хотя мне пока скорее везло -- даже chown -R .*
> небезболезненно, но вышло починить когда-то (дома :).

Подтверждаю. Да, вплоть до того что в случае аварийной ситуации гасить
нафиг сервер и идти спать оставив записку и выключив мобильник. Ибо от
того что можно натворить будучи невменяемым за консолью уволят куда
скорее (да и побьют больнее) чем за такую выходку.
---

BTW в т.ч. ругаться на забитые ФС умеет monit.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

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/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Eugene Prokopiev]

> На всякий случай напоминаю любителям пораскидывать все по разным
> шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
> разным шпинделям может быть ой как полезно.

А раскидывать отдельно данные и индексы?

Есть у меня железка, в которую можно воткнуть не более 2-х
SATA-дисков, и требуется поднять на ней постгрес. Сама система вместе
со всеми скриптами ценнее, чем данные, которые лежат еще и в сейфе на
DVD-R и которые можно залить повторно, но желательно в БД держать как
можно больше данных и делать выборки из них как можно быстрее.
Соотвественно, систему планируется держать на RAID1, а вот данные
непонятно. Т.е. альтернативы XFS нет, а вот что ниже? Варианты:

1) RAID0
2) данные на одном диске, логи на другом - но логи занимают
значительно меньше места, чем данные - а места жалко
3) данные на одном диске, индексы на другом - куда тогда девать логи?
размазывать по двум дискам в виде RAID0?

Если делать то же на трех дисках, то на третий лучше выносить логи
постгреса и логи XFS одновременно?

> Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
> наследникам конкретной таблицы (необходимо для unique значений), когда
> это появится, будет вообще чудесная возможность практически не трогая
> frontend выкидывать редко используемые _отдельные row_ на другой
> шпиндель.

Можно чуть подробнее: как формулируется задача и что хочется получить?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Michael Shigorin]

On Tue, Dec 25, 2007 at 06:51:51PM +0300, Eugene Prokopiev wrote:
> > На всякий случай напоминаю любителям пораскидывать все по
> > разным шпинделям о tablespaces в постгресе. Раскидывать
> > отдельные таблички по разным шпинделям может быть ой как
> > полезно.
> А раскидывать отдельно данные и индексы?
> 
> Есть у меня железка, в которую можно воткнуть не более 2-х
> SATA-дисков, и требуется поднять на ней постгрес. Сама система
> вместе со всеми скриптами ценнее, чем данные, которые лежат еще
> и в сейфе на DVD-R и которые можно залить повторно, но
> желательно в БД держать как можно больше данных и делать
> выборки из них как можно быстрее.  Соотвественно, систему
> планируется держать на RAID1, а вот данные непонятно. Т.е.
> альтернативы XFS нет, а вот что ниже? Варианты:
> 
> 1) RAID0

Для SATA? (да и вообще для дисков, на которых данные)

> 2) данные на одном диске, логи на другом - но логи занимают
> значительно меньше места, чем данные - а места жалко
> 3) данные на одном диске, индексы на другом - куда тогда девать логи?
> размазывать по двум дискам в виде RAID0?
> 
> Если делать то же на трех дисках, то на третий лучше выносить
> логи постгреса и логи XFS одновременно?

Вот тут экспериментируй, но вполне может быть.  Я бы ещё на
WD Raptor тогда посмотрел (пока себе раскачивался взять -- 
пробежали 15kRPM SAS).

> > Жаль в постгресе до сих пор нельзя делать индексы сразу по
> > всем наследникам конкретной таблицы (необходимо для unique
> > значений), когда это появится, будет вообще чудесная
> > возможность практически не трогая frontend выкидывать редко
> > используемые _отдельные row_ на другой шпиндель.
> Можно чуть подробнее: как формулируется задача и что хочется
> получить?

Эт к mithraen@, он сюда не подписан AFAIK.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Eugene Prokopiev]

> > > На всякий случай напоминаю любителям пораскидывать все по
> > > разным шпинделям о tablespaces в постгресе. Раскидывать
> > > отдельные таблички по разным шпинделям может быть ой как
> > > полезно.
> > А раскидывать отдельно данные и индексы?
> >
> > Есть у меня железка, в которую можно воткнуть не более 2-х
> > SATA-дисков, и требуется поднять на ней постгрес. Сама система
> > вместе со всеми скриптами ценнее, чем данные, которые лежат еще
> > и в сейфе на DVD-R и которые можно залить повторно, но
> > желательно в БД держать как можно больше данных и делать
> > выборки из них как можно быстрее.  Соотвественно, систему
> > планируется держать на RAID1, а вот данные непонятно. Т.е.
> > альтернативы XFS нет, а вот что ниже? Варианты:
> >
> > 1) RAID0
>
> Для SATA? (да и вообще для дисков, на которых данные)

А причем тут именно SATA? Ну а данных, как я выше сказал, не жалко ...

> > 2) данные на одном диске, логи на другом - но логи занимают
> > значительно меньше места, чем данные - а места жалко
> > 3) данные на одном диске, индексы на другом - куда тогда девать логи?
> > размазывать по двум дискам в виде RAID0?
> >
> > Если делать то же на трех дисках, то на третий лучше выносить
> > логи постгреса и логи XFS одновременно?
>
> Вот тут экспериментируй, но вполне может быть.  Я бы ещё на
> WD Raptor тогда посмотрел (пока себе раскачивался взять --
> пробежали 15kRPM SAS).

Про то, что там стоит, dmesg говорит WDC WD2500KS-00M. Не годится?

С логами и третьим диском такой еще вопрос: логи XFS - это как я
понимаю, отдельный раздел, логи простгреса - тоже раздел, но уже с ФС,
а куда складывать логи этой ФС? ;)

Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД) на
отдельный диск увеличивает скорость записи, а на скорость чтения
особого влияния не оказывает? Мне-то именно скорость чтения критична.

> > > Жаль в постгресе до сих пор нельзя делать индексы сразу по
> > > всем наследникам конкретной таблицы (необходимо для unique
> > > значений), когда это появится, будет вообще чудесная
> > > возможность практически не трогая frontend выкидывать редко
> > > используемые _отдельные row_ на другой шпиндель.
> > Можно чуть подробнее: как формулируется задача и что хочется
> > получить?
>
> Эт к mithraen@, он сюда не подписан AFAIK.

Так мы же вроде в sysadmins@ или нет?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Michael Shigorin]

On Wed, Dec 26, 2007 at 09:38:51AM +0300, Eugene Prokopiev wrote:
> > > 1) RAID0
> > Для SATA? (да и вообще для дисков, на которых данные)
> А причем тут именно SATA? Ну а данных, как я выше сказал, не жалко ...

Они менее, чем SCSI/SAS, умеют разбрасывать параллельную нагрузку
-- что не добавляет надёжности.  Помимо "не жалко" тут есть
и обсуждавшийся в d-r@ (насчёт свопа) вопрос того, охота ли
идти/ехать поднимать тазик, как только помрёт один из дисков.

С производительностью тоже могут быть нюансы: когда-то (в 2.4?)
md умел использовать RAID1 как страйп при наличии одного
читателя, бишь вытаскивать максимум из дисков, по словам нашего
техдира; он же досадовал, что в 2.6 это разломали.  Бишь если ты
собираешься RAID0 именно ради пропускной способности использовать 
-- попробуй прогнать при разном количестве читателей RAID0 и
RAID1 (необязательно с базой, думаю, хватит и bonnie++).

> > Вот тут экспериментируй, но вполне может быть.  Я бы ещё на
> > WD Raptor тогда посмотрел (пока себе раскачивался взять --
> > пробежали 15kRPM SAS).
> Про то, что там стоит, dmesg говорит WDC WD2500KS-00M. Не годится?

Это 7200RPM, а то 10000.  Хотя даже просто отдельный шпиндель,
по словам mithraen@, журналу сильно помогает.

> С логами и третьим диском такой еще вопрос: логи XFS - это как
> я понимаю, отдельный раздел, логи простгреса - тоже раздел, но
> уже с ФС, а куда складывать логи этой ФС? ;)

Делать internal, вестимо.  Или там логов валится маманегорюй? :)

> Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД)
> на отдельный диск увеличивает скорость записи, а на скорость
> чтения особого влияния не оказывает? Мне-то именно скорость
> чтения критична.

Скорее да, но не бенчмаркал.

> > Эт к mithraen@, он сюда не подписан AFAIK.
> Так мы же вроде в sysadmins@ или нет?

Угу.  Только его предыдущие Cc: до архива без особого разрешения 
не долетали.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 3684 bytes --]

On Tue, Dec 25, 2007 at 06:51:51PM +0300, Eugene Prokopiev wrote:

>> На всякий случай напоминаю любителям пораскидывать все по разным
>> шпинделям о tablespaces в постгресе. Раскидывать отдельные таблички по
>> разным шпинделям может быть ой как полезно.
EP> А раскидывать отдельно данные и индексы?

Разумеется тоже полезно :)
Кстати я об этом почему-то не задумывался, а результат-то достигается
элементарно и, как мне кажется, во многих случаях существенный...

EP> Есть у меня железка, в которую можно воткнуть не более 2-х
EP> SATA-дисков, и требуется поднять на ней постгрес. Сама система вместе
EP> со всеми скриптами ценнее, чем данные, которые лежат еще и в сейфе на
EP> DVD-R и которые можно залить повторно, но желательно в БД держать как
EP> можно больше данных и делать выборки из них как можно быстрее.
EP> Соотвественно, систему планируется держать на RAID1, а вот данные
EP> непонятно. Т.е. альтернативы XFS нет, а вот что ниже? Варианты:

Для БД ext3 с data=journal работает очень даже замечательно. Я не пробовал
проводить тестирование что реально лучше.

EP> 2) данные на одном диске, логи на другом - но логи занимают
EP> значительно меньше места, чем данные - а места жалко

У тебя два диска. Раскидвай данные по ним так, чтобы нагрузка была
более-менее равномерная. То есть логи да, на один. Можно еще что-то на
него же.

Логи, кстати, лучше всего действительно на XFS.

EP> 3) данные на одном диске, индексы на другом - куда тогда девать логи?
EP> размазывать по двум дискам в виде RAID0?

Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не тормоза еще тюнить
надо. Для логов у меня есть сомнения в пользе такого действия.

EP> Если делать то же на трех дисках, то на третий лучше выносить логи
EP> постгреса и логи XFS одновременно?

Хороший вопрос. Я не знаю на него ответа, к сожалению.

>> Жаль в постгресе до сих пор нельзя делать индексы сразу по всем
>> наследникам конкретной таблицы (необходимо для unique значений), когда
>> это появится, будет вообще чудесная возможность практически не трогая
>> frontend выкидывать редко используемые _отдельные row_ на другой
>> шпиндель.
EP> Можно чуть подробнее: как формулируется задача и что хочется получить?

Краткая вводная:
В постгресе есть зачатки объектно-ориентированности. В том числе
"наследование".

Так вот, к примеру, можно сделать табличку:
CREATE TABLE blabla (
	blabla_id	SERIAL PRIMARY KEY,
	cooldata VARCHAR,
	is_old	BOOLEAN NOT NULL
	CHECK(is_old == 'f')
);

CREATE TABLE blabla_old LIKE blabla(
	CHECK(is_old == 't')
);

Реально создалось две таблицы. Самое интересное в этом то, что если мы
заполним их данными, а дальше выполним команду:

SELECT * FROM blabla*;
то мы получим данные из обеих (!) таблиц.

А если:

SELECT * FROM blabla* WHERE is_old = 'f';

То никаких обращений к второй таблице не будет вообще.

Собственно описание достаточно краткое, там надо еще чуточку с бубном
поплясать чтобы это заработало, но потенциал у этого решения огромный.

А вот засада следующая -- blabla_id не уникален для этой группы таблиц, он
уникален только в пределах одной таблицы. При этом благодаря тому что он
SERIAL он при заполнении будет вроде как казаться уникальным (на все
таблицы будет одна sequence), но insert/update с указанием конкретного
значения для blabla_id эту идиллию разрушат.

Все что я сейчас рассказываю описано в документации на постгрес гораздо
подробнее, с описанием множества подводных граблей и прочих приятностей.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Старый глюк лучше новых двух.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Denis Smirnov]

[-- Attachment #1: Type: text/plain, Size: 858 bytes --]

On Wed, Dec 26, 2007 at 09:38:51AM +0300, Eugene Prokopiev wrote:

EP> Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД) на
EP> отдельный диск увеличивает скорость записи, а на скорость чтения
EP> особого влияния не оказывает? Мне-то именно скорость чтения критична.

Сомневаюсь что этот трюк поможет с чтением (если действительно речь о
ситуации где много-много операций чтения и практически нет операций
записи). 

>> Эт к mithraen@, он сюда не подписан AFAIK.
EP> Так мы же вроде в sysadmins@ или нет?

У меня эти письма попадали на другой мыльник, с которого я на sysadmins не
подписан, и отвечал я не подумав об этом.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
IDE -- это "один шлейф, один диск", иначе гайки.
		-- mike in community@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Eugene Prokopiev]

> EP> Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД) на
> EP> отдельный диск увеличивает скорость записи, а на скорость чтения
> EP> особого влияния не оказывает? Мне-то именно скорость чтения критична.
>
> Сомневаюсь что этот трюк поможет с чтением (если действительно речь о
> ситуации где много-много операций чтения и практически нет операций
> записи).

Т.е. поможет лишь разнесение данных и индексов да и то не факт? Ведь
постгрес при будет читать сначала индексы с одного диска, а потом
данные с другого и операцию чтения распараллелить не получится. Т.е.
полезным это окажется только для нескольких читателей?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Eugene Prokopiev]

> Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не тормоза еще тюнить
> надо. Для логов у меня есть сомнения в пользе такого действия.

А что именно там нужно тюнить?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

On Wed, Dec 26, 2007 at 01:38:43PM +0300, Eugene Prokopiev wrote:
> > Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не
> > тормоза еще тюнить надо. Для логов у меня есть сомнения в
> > пользе такого действия.
> А что именно там нужно тюнить?

Подозреваю, что подразумевался stripe size по какой-то корреляции
со средним размером записи.  Поскольку сам RAID0 применял
считанные разы, соответственно тоже бы гуглил...

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

On Wed, Dec 26, 2007 at 01:37:36PM +0300, Eugene Prokopiev wrote:
> Т.е. поможет лишь разнесение данных и индексов да и то не факт?
> Ведь постгрес при будет читать сначала индексы с одного диска,

И если другой == один, то здесь <seek>

> а потом данные с другого и операцию чтения распараллелить не
> получится.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 629 bytes --]

On Wed, Dec 26, 2007 at 01:38:43PM +0300, Eugene Prokopiev wrote:

>> Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не тормоза еще тюнить
>> надо. Для логов у меня есть сомнения в пользе такого действия.
EP> А что именно там нужно тюнить?

Как минимум размер блока у FS, и не забывать про выравнивание. Да и
выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
сожалению.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<gns> а если сизиф в микроволновку сунуть, он разморозится?
<Lost> gns: угу, и начнет вонять

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

On Wed, Dec 26, 2007 at 01:37:36PM +0300, Eugene Prokopiev wrote:

> EP>> Кстати, я правильно понимаю, что вынесение любых логов (ФС, БД) на
> EP>> отдельный диск увеличивает скорость записи, а на скорость чтения
> EP>> особого влияния не оказывает? Мне-то именно скорость чтения критична.
>> Сомневаюсь что этот трюк поможет с чтением (если действительно речь о
>> ситуации где много-много операций чтения и практически нет операций
>> записи).
EP> Т.е. поможет лишь разнесение данных и индексов да и то не факт? Ведь
EP> постгрес при будет читать сначала индексы с одного диска, а потом
EP> данные с другого и операцию чтения распараллелить не получится. Т.е.
EP> полезным это окажется только для нескольких читателей?

Когда читатель/писатель _один_ это совсем-совсем другая задача. И
оптимизируется совсем-совсем по-другому. 

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
<vsu> Lost: тогда надо делать более развесистый патч
<Lost> vsu: да я забил в общем ;)

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Eugene Prokopiev]

> Когда читатель/писатель _один_ это совсем-совсем другая задача. И
> оптимизируется совсем-совсем по-другому.

А есть ли вообще в распространенных СУБД/ФС/ОС возможность оптимизации
под одного читателя?

-- 
С уважением,
Прокопьев Евгений

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

Денис Смирнов пишет:
> On Wed, Dec 26, 2007 at 01:38:43PM +0300, Eugene Prokopiev wrote:
> 
>>> Нафиг-нафиг! RAID0, кстати, чтобы давал ускорение а не тормоза еще тюнить
>>> надо. Для логов у меня есть сомнения в пользе такого действия.
> EP> А что именно там нужно тюнить?
> 
> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
> сожалению.

А есть какие-то рекомендации по выбору размер блока?
Кроме как погонять bonnie++ с разными параметрами и посмотреть что
получится.

Chunk Size у raid гораздо больше чем block size у FS
У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto) (was: OpenVZ, VServer и полудесяток)

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

On Sat, Dec 29, 2007 at 10:40:15AM +0300, Eugene Prokopiev wrote:

>> Когда читатель/писатель _один_ это совсем-совсем другая задача. И
>> оптимизируется совсем-совсем по-другому.
EP> А есть ли вообще в распространенных СУБД/ФС/ОС возможность оптимизации
EP> под одного читателя?

Задачу опиши, да?
Оптимизировать можно все что угодно.

Но, IMHO, многие задачи "одного читателя" лучше всего оптимизируются таки
распараллеливанием. Не все, конечно.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
Все программы содержат ошибки, просто о некоторых мы не догадываемся.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Денис Смирнов]

[-- Attachment #1: Type: text/plain, Size: 971 bytes --]

On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:

>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>> сожалению.
MT> А есть какие-то рекомендации по выбору размер блока?

Мне неизвестны :(

MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
MT> получится.

Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
будет.

MT> Chunk Size у raid гораздо больше чем block size у FS
MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.

Это меня переклинило.
Я имел в виду две проблемы:
 - выравнивание блока (если не дай бой используется софтрейд на разделах)
 - размеры файла.

-- 
С уважением, Денис

http://freesource.info
----------------------------------------------------------------------------
И не говорите потом, что я вас не предупреждал.
		-- ldv in sisyphus@

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 1156 bytes --]

Денис Смирнов пишет:
> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
> 
>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>> сожалению.
> MT> А есть какие-то рекомендации по выбору размер блока?
> 
> Мне неизвестны :(
> 
> MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
> MT> получится.
> 
> Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
> будет.

Лучше конечно погонять конечный демон под нагрузкой.
Но по результатам многопоточного bonnie++ вполне можно составить
представление о будущей производительности.

> MT> Chunk Size у raid гораздо больше чем block size у FS
> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
> 
> Это меня переклинило.
> Я имел в виду две проблемы:
>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>  - размеры файла.

Ну что разделы "плюсового размера" делать не следует это ИМХО
общеизвестно :)
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1259 bytes --]

Maxim Tyurin пишет:
> Денис Смирнов пишет:
>> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
>>
>>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>>> сожалению.
>> MT> А есть какие-то рекомендации по выбору размер блока?
>>
>> Мне неизвестны :(
>>
>> MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
>> MT> получится.
>>
>> Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
>> будет.
> 
> Лучше конечно погонять конечный демон под нагрузкой.
> Но по результатам многопоточного bonnie++ вполне можно составить
> представление о будущей производительности.
> 
>> MT> Chunk Size у raid гораздо больше чем block size у FS
>> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
>>
>> Это меня переклинило.
>> Я имел в виду две проблемы:
>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>  - размеры файла.
> 
> Ну что разделы "плюсового размера" делать не следует это ИМХО
> общеизвестно :)

  Что именно имеется в виду?

PS: Я кажется не в теме, а она (тема) кажется важна...

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 1919 bytes --]

Aleksey Avdeev writes:

> Maxim Tyurin пишет:
>> Денис Смирнов пишет:
>>> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
>>>
>>>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>>>> сожалению.
>>> MT> А есть какие-то рекомендации по выбору размер блока?
>>>
>>> Мне неизвестны :(
>>>
>>> MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
>>> MT> получится.
>>>
>>> Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
>>> будет.
>> 
>> Лучше конечно погонять конечный демон под нагрузкой.
>> Но по результатам многопоточного bonnie++ вполне можно составить
>> представление о будущей производительности.
>> 
>>> MT> Chunk Size у raid гораздо больше чем block size у FS
>>> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
>>>
>>> Это меня переклинило.
>>> Я имел в виду две проблемы:
>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>>  - размеры файла.
>> 
>> Ну что разделы "плюсового размера" делать не следует это ИМХО
>> общеизвестно :)
>
>   Что именно имеется в виду?
>
> PS: Я кажется не в теме, а она (тема) кажется важна...

bungarus:~#  fdisk -l /dev/hda

Disk /dev/hda: 80.0 GB, 80026361856 bytes
240 heads, 63 sectors/track, 10337 cylinders
Units = cylinders of 15120 * 512 = 7741440 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/hda1   *           1         416     3144928+  83  Linux
...
вот так делать не следует (обрати внимание на размер в блоках)
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
   ___                                 
  / _ )__ _____  ___ ____ _______ _____
 / _  / // / _ \/ _ `/ _ `/ __/ // (_-<
/____/\_,_/_//_/\_, /\_,_/_/  \_,_/___/
               /___/  

[-- Attachment #2: Type: application/pgp-signature, Size: 188 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

On Thu, Jan 03, 2008 at 12:42:23PM +0300, Aleksey Avdeev wrote:
> >> Я имел в виду две проблемы:
> >>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
> >>  - размеры файла.
> > Ну что разделы "плюсового размера" делать не следует это ИМХО
> > общеизвестно :)
>   Что именно имеется в виду?
> PS: Я кажется не в теме, а она (тема) кажется важна...

Для RAID5 -- да.

http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

Maxim Tyurin пишет:
> Aleksey Avdeev writes:
> 
>> Maxim Tyurin пишет:
>>> Денис Смирнов пишет:
>>>> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
>>>>
>>>>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>>>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>>>>> сожалению.
>>>> MT> А есть какие-то рекомендации по выбору размер блока?
>>>>
>>>> Мне неизвестны :(
>>>>
>>>> MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
>>>> MT> получится.
>>>>
>>>> Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
>>>> будет.
>>> Лучше конечно погонять конечный демон под нагрузкой.
>>> Но по результатам многопоточного bonnie++ вполне можно составить
>>> представление о будущей производительности.
>>>
>>>> MT> Chunk Size у raid гораздо больше чем block size у FS
>>>> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
>>>>
>>>> Это меня переклинило.
>>>> Я имел в виду две проблемы:
>>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>>>  - размеры файла.
>>> Ну что разделы "плюсового размера" делать не следует это ИМХО
>>> общеизвестно :)
>>   Что именно имеется в виду?
>>
>> PS: Я кажется не в теме, а она (тема) кажется важна...
> 
> bungarus:~#  fdisk -l /dev/hda
> 
> Disk /dev/hda: 80.0 GB, 80026361856 bytes
> 240 heads, 63 sectors/track, 10337 cylinders
> Units = cylinders of 15120 * 512 = 7741440 bytes
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/hda1   *           1         416     3144928+  83  Linux
> ...
> вот так делать не следует (обрати внимание на размер в блоках)

  Имеется в виду "+"?

  У меня сложилось впечатление, возможно не правильное, что этот "+"
появляется, когда раздел крайний и его можно увеличивать... И как это
связано с выравниванием -- не понимаю.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 662 bytes --]

Michael Shigorin пишет:
> On Thu, Jan 03, 2008 at 12:42:23PM +0300, Aleksey Avdeev wrote:
>>>> Я имел в виду две проблемы:
>>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>>>  - размеры файла.
>>> Ну что разделы "плюсового размера" делать не следует это ИМХО
>>> общеизвестно :)
>>   Что именно имеется в виду?
>> PS: Я кажется не в теме, а она (тема) кажется важна...
> 
> Для RAID5 -- да.
> 
> http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID
> 

  <http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux> читал,
но не уверен, что понял правильно... :-(

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 2328 bytes --]

Aleksey Avdeev пишет:
> Maxim Tyurin пишет:
>> Aleksey Avdeev writes:
>>
>>> Maxim Tyurin пишет:
>>>> Денис Смирнов пишет:
>>>>> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
>>>>>
>>>>>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>>>>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>>>>>> сожалению.
>>>>> MT> А есть какие-то рекомендации по выбору размер блока?
>>>>>
>>>>> Мне неизвестны :(
>>>>>
>>>>> MT> Кроме как погонять bonnie++ с разными параметрами и посмотреть что
>>>>> MT> получится.
>>>>>
>>>>> Гонять, боюсь, надо не bonnie++, а тесты с эмуляцией той нагрузки, которая
>>>>> будет.
>>>> Лучше конечно погонять конечный демон под нагрузкой.
>>>> Но по результатам многопоточного bonnie++ вполне можно составить
>>>> представление о будущей производительности.
>>>>
>>>>> MT> Chunk Size у raid гораздо больше чем block size у FS
>>>>> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
>>>>>
>>>>> Это меня переклинило.
>>>>> Я имел в виду две проблемы:
>>>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>>>>  - размеры файла.
>>>> Ну что разделы "плюсового размера" делать не следует это ИМХО
>>>> общеизвестно :)
>>>   Что именно имеется в виду?
>>>
>>> PS: Я кажется не в теме, а она (тема) кажется важна...
>> bungarus:~#  fdisk -l /dev/hda
>>
>> Disk /dev/hda: 80.0 GB, 80026361856 bytes
>> 240 heads, 63 sectors/track, 10337 cylinders
>> Units = cylinders of 15120 * 512 = 7741440 bytes
>>
>>    Device Boot      Start         End      Blocks   Id  System
>> /dev/hda1   *           1         416     3144928+  83  Linux
>> ...
>> вот так делать не следует (обрати внимание на размер в блоках)
> 
>   Имеется в виду "+"?
> 
>   У меня сложилось впечатление, возможно не правильное, что этот "+"
> появляется, когда раздел крайний и его можно увеличивать... И как это
> связано с выравниванием -- не понимаю.

Это совсем не значит что раздел крайний.
В моем случае он первый, а разделов у меня 4. Я их просто не показывал
ибо к делу не относится.

Это уже давно красиво описали:
http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID

-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Aleksey Avdeev]

[-- Attachment #1: Type: text/plain, Size: 3538 bytes --]

Maxim Tyurin пишет:
> Aleksey Avdeev пишет:
>> Maxim Tyurin пишет:
>>> Aleksey Avdeev writes:
>>>
>>>> Maxim Tyurin пишет:
>>>>> Денис Смирнов пишет:
>>>>>> On Sat, Dec 29, 2007 at 05:45:54PM +0200, Maxim Tyurin wrote:
>>>>>>
>>>>>>>> Как минимум размер блока у FS, и не забывать про выравнивание. Да и
>>>>>>>> выбирать грамотно этот размер блока. Далеко не всегда RAID0 хорош, к
>>>>>>>> сожалению.
...
>>>>>
>>>>>> MT> Chunk Size у raid гораздо больше чем block size у FS
>>>>>> MT> У ext3 block size это 1k, 2k или 4k, а chunk size с 64k только начинаются.
>>>>>>
>>>>>> Это меня переклинило.
>>>>>> Я имел в виду две проблемы:
>>>>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
>>>>>>  - размеры файла.
>>>>> Ну что разделы "плюсового размера" делать не следует это ИМХО
>>>>> общеизвестно :)
>>>>   Что именно имеется в виду?
>>>>
>>>> PS: Я кажется не в теме, а она (тема) кажется важна...
>>> bungarus:~#  fdisk -l /dev/hda
>>>
>>> Disk /dev/hda: 80.0 GB, 80026361856 bytes
>>> 240 heads, 63 sectors/track, 10337 cylinders
>>> Units = cylinders of 15120 * 512 = 7741440 bytes
>>>
>>>    Device Boot      Start         End      Blocks   Id  System
>>> /dev/hda1   *           1         416     3144928+  83  Linux
>>> ...
>>> вот так делать не следует (обрати внимание на размер в блоках)
>>   Имеется в виду "+"?
>>
>>   У меня сложилось впечатление, возможно не правильное, что этот "+"
>> появляется, когда раздел крайний и его можно увеличивать... И как это
>> связано с выравниванием -- не понимаю.
> 
> Это совсем не значит что раздел крайний.
> В моем случае он первый, а разделов у меня 4. Я их просто не показывал
> ибо к делу не относится.

  Похоже да (посмотрел внимательно: у меня тоже самое), но что именно
этот "+" значит?

> 
> Это уже давно красиво описали:
> http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID

  Повторюсь: данную статью читал, но не уверен что Aligning ASM Disks on
Linux (<http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux>)
понял правильно.

  Последняя система, поднятая после прочтения, развита так (4 идентичных
диска):

$ sudo -H fdisk -l /dev/sda
Password:

Disk /dev/sda: 500.1 GB, 500107862016 bytes
255 heads, 63 sectors/track, 60801 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes

   Device Boot      Start         End      Blocks   Id  System
/dev/sda1   *           1          17      131040+  fd  Linux raid
autodetect
Partition 1 does not end on cylinder boundary.
/dev/sda2              17          82      524288   fd  Linux raid
autodetect
Partition 2 does not end on cylinder boundary.
/dev/sda3              82       16791   134217728   fd  Linux raid
autodetect
/dev/sda4           16791       60802   353513496   fd  Linux raid
autodetect

$ cat /proc/mdstat
Personalities : [raid1] [raid6] [raid5] [raid4] [raid0]
md3 : active raid0 sdb3[1] sda3[0]
      268435200 blocks 128k chunks

md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
      524224 blocks [4/4] [UUUU]

md4 : active raid0 sdd3[1] sdc3[0]
      268435200 blocks 128k chunks

md2 : active raid5 sdd4[3] sdc4[2] sdb4[1] sda4[0]
      1060540032 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU]

md0 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0]
      130944 blocks [4/4] [UUUU]

unused devices: <none>

  Правильно ли я сделал?

PS: Разделы входящие в md0 (sd*1) не выровнены сознательно: это /boot.

-- 

С уважением. Алексей.



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 544 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Maxim Tyurin]

[-- Attachment #1: Type: text/plain, Size: 1693 bytes --]

Aleksey Avdeev пишет:
\skip
>   Последняя система, поднятая после прочтения, развита так (4 идентичных
> диска):
> 
> $ sudo -H fdisk -l /dev/sda
> Password:
> 
> Disk /dev/sda: 500.1 GB, 500107862016 bytes
> 255 heads, 63 sectors/track, 60801 cylinders
> Units = cylinders of 16065 * 512 = 8225280 bytes
> 
>    Device Boot      Start         End      Blocks   Id  System
> /dev/sda1   *           1          17      131040+  fd  Linux raid
> autodetect
> Partition 1 does not end on cylinder boundary.
> /dev/sda2              17          82      524288   fd  Linux raid
> autodetect
> Partition 2 does not end on cylinder boundary.
> /dev/sda3              82       16791   134217728   fd  Linux raid
> autodetect
> /dev/sda4           16791       60802   353513496   fd  Linux raid
> autodetect
> 
> $ cat /proc/mdstat
> Personalities : [raid1] [raid6] [raid5] [raid4] [raid0]
> md3 : active raid0 sdb3[1] sda3[0]
>       268435200 blocks 128k chunks
> 
> md1 : active raid1 sdd2[3] sdc2[2] sdb2[1] sda2[0]
>       524224 blocks [4/4] [UUUU]
> 
> md4 : active raid0 sdd3[1] sdc3[0]
>       268435200 blocks 128k chunks
> 
> md2 : active raid5 sdd4[3] sdc4[2] sdb4[1] sda4[0]
>       1060540032 blocks level 5, 128k chunk, algorithm 0 [4/4] [UUUU]
> 
> md0 : active raid1 sdd1[3] sdc1[2] sdb1[1] sda1[0]
>       130944 blocks [4/4] [UUUU]
> 
> unused devices: <none>
> 
>   Правильно ли я сделал?
> 
> PS: Разделы входящие в md0 (sd*1) не выровнены сознательно: это /boot.

md0 это raid1
Выравнивание по цилиндру для него не критично.
Вот для raid5 другое дело.
-- 

With Best Regards, Maxim Tyurin
JID:	MrKooll@jabber.pibhe.com
			


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

On Sat, Jan 05, 2008 at 04:40:55PM +0300, Aleksey Avdeev wrote:
> >> PS: Я кажется не в теме, а она (тема) кажется важна...
> > bungarus:~#  fdisk -l /dev/hda
> > Disk /dev/hda: 80.0 GB, 80026361856 bytes
> > 240 heads, 63 sectors/track, 10337 cylinders
> > Units = cylinders of 15120 * 512 = 7741440 bytes
> >    Device Boot      Start         End      Blocks   Id  System
> > /dev/hda1   *           1         416     3144928+  83  Linux
> > ...
> > вот так делать не следует (обрати внимание на размер в блоках)
>   Имеется в виду "+"?

Угу.

> У меня сложилось впечатление, возможно не правильное, что этот
> "+" появляется, когда раздел крайний и его можно увеличивать...
> И как это связано с выравниванием -- не понимаю.

В случае dos disklabel у нас перед разделом 63 сектора идёт на
таблицу разделов.  Это едва ли не худший возможный вариант -- 
ничему разумному не кратен.

Подробнее -- на wiki, ссылку дал (и там по ссылкам).  
Или google://raid5+alignment

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/

Re: [Sysadmins] оптимизация дисковой подсистемы (linux multi-disk server howto)

[Michael Shigorin]

On Sat, Jan 05, 2008 at 04:44:02PM +0300, Aleksey Avdeev wrote:
> >>>> Я имел в виду две проблемы:
> >>>>  - выравнивание блока (если не дай бой используется софтрейд на разделах)
> >>>>  - размеры файла.
> >>> Ну что разделы "плюсового размера" делать не следует это ИМХО
> >>> общеизвестно :)
> >>   Что именно имеется в виду?
> >> PS: Я кажется не в теме, а она (тема) кажется важна...
> > Для RAID5 -- да.
> > http://www.freesource.info/wiki/HCL/XranenieDannyx/SoftwareRAID
> <http://www.pythian.com/blogs/411/aligning-asm-disks-on-linux>
> читал, но не уверен, что понял правильно... :-(

Ну ты спрашивай, если что ;-)  Напрягусь да вспомню.

Вообще хорошо бы, чтоб это у нас умела делать разбивалка дисков 
в инсталяторе.  Цены бы ей не было.

-- 
 ---- WBR, Michael Shigorin <mike@altlinux.ru>
  ------ Linux.Kiev http://www.linux.kiev.ua/