Разбивка HDD корректировка Swap и диагностика дисковой системы.

Автор: Raven2000.

Дисковая подсистема - узкое место системы и грамотная разбивка HDD + выделение
оптимального Swap во многом определяет производительность.

Интерфейсы
SCSI - Хотелось, конечно, поработать на таких HDD т.к. там довольно мощный планировщик
запросов соответственно в SCSI компиляция шустрее и т.д. не говоря о скорости этих
устройств, но стоит неплохих денег.

SATA - для SATA контроллеры еще сыроваты, содержат  некоторые ошибки, которые приводят
иногда к интересным артефактам, например, некоторые контроллеры бывают, теряют пару
последних байт в последнем переданном блоке в результате некорректная запись и он занимает весь кластер и первое время ошибка незаметна… Это в основном касается только
производителей дешевых чипсетов с интегрированным SATA контроллером типа VIA, SIS и т.д.
которые предпочитают потом исправлять эти ошибки в своих драйверах которые выпускают
только под Windows :).Бери SATA для *BSD если уверенны в его стабильности
(т.е. дешевые не берите или протестируйте)

IDE - Если вы собираетесь часто и много компилировать лучше брать IDE.
Т.к. тут все стандартизировано и главное проверенно временем и ошибок в этом стандарте вы вряд ли встретите. Да и мы народ простой и $ мало значит берем за основу IDE HDD :)

Разметка
В идеале лучше иметь 2 диска подвешенные на различных IDE-каналах на первый под временные файлы [Swap, /var,etc] второй под файлы системы и свои домашние. Некоторые материнки держат 3 IDE-канала, что позволяет выделить под Swap отдельное делопроизводство :) что очень хорошо, но довольно расточительно:).
Возьмем конфигурацию ПК с 20Гб HDD и 256 RAM (я бы так разметил :))


/ 512Mb UFS2 Y /swap 256Mb SWAP #желательно на 2 IDE диске /usr 9488Mb UFS2+S Y #лучше /usr держать плотнее к корневой /var 9232Mb UFS2+S Y #желательно на 2 IDE диске размер можно 256 мег. /tmp 512Mb UFS2+S Y #желательно на 2 IDE диске размер можно >512 мег.

Я ставил систему на один HDD и закомментировал, что желательно перенести на второй диск.
Начнем с того, почему именно так разбил HDD и в таком порядке, а не по ханбуку.
Итак, почему /tmp должен идти после /var, а не наоборот? Т.к. если сделать наоборот, то головка диска будет сильно порхатся ей будет нужно при каждом обращении к /var пересекать весь /tmp. В некоторых системах можно настроить каталог /tmp как “резидентную” файловую систему – это фактически тоже что и виртуальный диск ПК. Специальный драйвер выдает себя за драйвер диска,но на самом деле записывает данные в память, что приводит к значительному ускорения чтения и записи временных файлов. Для этого смотрим #man mfs
Теперь /usr его желательно держать плотнее к корневой. А /swap лучше расположить в начале диска выделив сколько ни будь под него памяти :) (исходя из RAM это рассмотрим ниже) А корневой "/"  я выделил 512Mb хотя в хенбуке цитирую


100 MB Корневая файловая система. Любая другая файловая система будет смонтирована на эту. 100 MB это подходящий размер для этой файловой системы. Вы не будете хранить на ней слишком много данных, а обычная установка FreeBSD разместит здесь около 40 MB данных. Оставшееся пространство используется для временных файлов, а также оставляет возможность расширения для будущих версий FreeBSD, которым может понадобиться больше места в /.

Я пару раз сталкивался с тем, что 100Mb у меня забивались, что доставляло мне некоторые неудобства. Можно конечно и 256 поставить, но конкретно для меня я ставлю 512Mb или 256Mb, если HDD маленький или знаю, что будет на сервере.

Swap
Теперь поговорим о Swap, сколько же в действительности нужно *BSD с N количеством RAM и как она желает с ним работать и главное во сколько эффективно? Если у вас есть хотя бы 512 RAM то у *BSD будет мало желания работать со  Swap (во всяком случае, в нетрудоемких задачах и компиляции). В ханбуке написано следующее.


От 2-3 x RAM Если у вас больше одного диска, можно расположить подкачку на каждом диске. FreeBSD будет использовать каждый диск, что серьезно увеличит скорость подкачки. В этом случае, определите общий размер подкачки, который вам нужен (например, 128 MB), и поделите его на число имеющихся дисков (например, два) для определения размера разделов подкачки, которые нужно разместить на каждом вашем диске, в этом примере 64 MB на диск.

Исходя из текста выводим следующее, чем больше у меня RAM, тем больше мне надо Swap, а не наоборот (что-то в жизни я не понимаю :)) это совершенно нелогично!
Следуя  если у меня 2 гига утрирую RAM, то нужно 4-6 гигов свопа! %0 нежизнеспособно все это полный бред! А если у меня 512 RAM 512*2=1024 свопа ставить совершенно нецелесообразно. Но помните, если виртуальной памяти не хватит и приложение, которое затребовало ее просто завершится с ошибкой, так что думайте. Но в ханбуке есть пару дельных мыслей это расположить Swap на отдельном (втором HDD об этом я говорил выше) и распределить на 2 HDD. Максимальная производительность подкачки достигается в случае распределения области подкачки между несколькими дисками (или еще лучше, между несколькими шинами SCSI)
Т.е. сделать два Swap на каждом из HDD, что в идеале увеличит быстродействие.

Теперь к делу в реале рассчитываем Swap и так.


RAM Swap 128=1*2= 256 256=1:1= 256 512=0.5:1=256 512=1:1= 512 # Это уже круто для навороченного сервис центра :) 1024=0.5:1=512 # Аналогично выше сказуемому да еще RAM много.

Обычно добавляется к конечному свопу еще дополнительно 20-30 Mb
Если у вас еще больше RAM, то уменьшаем далее своп, т.е. можно 256 Mb Swap или вообще, сколько ни будь ыделить, ну идея ясна. Со свопом разобрались, посмотрим, как система будет с ней управляться.

Статистика виртуальной памяти
Если HDD трещит часто и надоедливо это свидетельствует о высокой интенсивности операций подкачки.
Использование свопа можно узнать командами swapinfo или pstat -s
Смотрим степень использования свопа


#swapinfo Device 1K-blocks Used Avail Capacity /dev/ad0s1b 262144 0 262144 0%

Как видим своп отдыхает :) заполненность его нулевое.
А для получение подробной статистики работы swap используют vmstat.


#vmstat procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad2 in sy cs us sy id 1 0 0 394516 66264 11 0 0 0 14 2 0 0 140 113 361 1 1 98

Эта команда есть во всех UNIX подобных системах от HP-UX до Linux.
Vmstat раскладывает на 6 тематических разделов.

procs - информация о процессах
r - кол-во готовых к запуску процессов
b - кол-во заблокированных в ожидании ресурсов ввода/вывода
w - кол-во готовых к запуску, но перемещенных в своп процессов

memory - кол-во доступной RAM
avm - объем доступной виртуальной памяти в килобайтах
fre - объем свободной памяти (в килобайтах)

page - активность страничной подкачки
flt - кол-во "промахов" те обращение к страницам, которых в RAM на данный момент нет
re - число возвращенных страниц (восстановленных из списка неиспользуемых)
pi - кол-во подкаченных страниц
po - кол-во выгруженных страниц
fr - кол-во освобожденных страниц
sr - число страниц обработанные по алгоритму "часы" (алгоритм пометки давно неиспользовавшихся страниц)

disks - операции с HDD (число в секунду)
Число операций с дисками (в данном примере два диска ad0 и ad2)

faults - переключение контекста и прерываний (число в секунду)
in - число прерываний
sy - число системных вызовов
cs - число переключений контекста

cpu - использование CPU
us - время, потраченное на исполнение кода программ
sy - время, потраченное на исполнение кода ядра (системные вызовы, ввод\вывод)
id - время простоя

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


vmstat <интервал (секунды)> <количество повторов>

Вот типичный листинг


#vmstat 1 3 procs memory page disks faults cpu r b w avm fre flt re pi po fr sr ad0 ad2 in sy cs us sy id 1 1 0 395856 64772 11 0 0 0 14 2 0 0 140 112 360 1 1 98 0 1 0 395856 64772 3 0 0 0 0 0 0 0 145 188 371 0 1 99 0 1 0 395856 64772 0 0 0 0 0 0 8 0 177 170 440 0 0 100

Так что, понаблюдав за этим можно выявить, например такое, если в  procs в колонке w часто становится больше 0 то системной памяти не хватает. Далее смотрим в page колонка fr если значение слишком высокое то значит завершилась какая то программа либо памяти просто не хватает (при условии числа не достигают 3% от общего обьема системной памяти).
Полную статистику за все время непрерывной работы BSD можно узнать указать флаг -s
Этот флаг выдает статические данные не по страничным операциям, а по перекачке процессов.


#vmstat -s

Статистика кол-ва прерываний поступивших от устройств флагом -i


#vmstat -i

И для интересующихся ядром есть флаг -m это количество памяти, выделенное ядром под свои нужды.


#vmstat -m

Для начала хватит, чтобы разобраться со своим домашним сервачком :) и диагностировать проблемы со свопом и многим другим vmstat очень универсальная вещь для диагностики проблем.

Анализ операций обмена с диском. Статистика ввода/вывода
Для наблюдения за пропускной способностью HDD есть команда iostat


#iostat tty ad0 ad2 cpu tin tout KB/t tps MB/s KB/t tps MB/s us ni sy in id 0 1 14.43 2 0.03 18.41 0 0.01 1 0 0 0 98

Статистика похожа на vmstat
tty - число введенных и выведенных символах в сек.
tin - с терминала
tout - с псевдотерминала
(tty - ничем неинтересен)

ad0 - соб-но HDD  тут их два ad0 и ad2
KB/t - объем инфы в килобайтах переданных за 1 пересылку данных
tps - кол-во переданных данных в секунду
MB/s - объем данных  в мегах переданных в секунду

cpu – Это хар-ки  CPU (см выше также как в vmstat)

К счастью iostat можно запускать с флагом –d Что исключит ненужные tty и cpu :)
Чтобы полностью просмотреть статистику за все время работы системы по HDD запускаем с -I


#iostat -I -d ad0 ad2 KB/t xfrs MB KB/t xfrs MB 14.39 75730 1064.27 18.41 14278 256.71

KB/t - объем инфы в килобайтах переданных за 1 пересылку данных
xfrs - общее количество пересылок
MB - общий объем переданных данных

Я не рассматривал разные примеры разбивки систем. Я например для FTP беру 250Gb HDD и подрубаю /ftp
со всеми вытекающими плюсами :). На ответственных серверах люди делают что-то типа /data т.е. отделяют мух от котлет ;) и ставя туда нужные сервисы для повышения стабильности и безопастности(типа апача,сквид,mysql). Размеры и резка на слайсы решает только сам админ исходя из своих нужд и задач. А здесь описано общая схема работы, так что в путь.

Литература
1) FreeBSD Энциклопедия пользователя Майкл Эбен Брайан Таймэн - стр.54,55,354-358,730
2) UNIX руководство системного администратора 3е изд. - стр.158,796-804,
3) Handbook - 2.5.5., 11.2.1.2.
4) Хакер Спец 08/69/август 2006 - стр. 24, 46-48,
5) Гугления всея сети + свои испытания :)

Вроде все указал где смотрел :)
Продолжение следует...

размещено: 2007-03-31,
последнее обновление: 2007-04-11,
автор: Raven2000

  Этот информационный блок появился по той простой причине, что многие считают нормальным, брать чужую информацию не уведомляя автора (что не так страшно), и не оставляя линк на оригинал и автора — что более существенно. Я не против распространения информации — только за. Только условие простое — извольте подписывать автора, и оставлять линк на оригинальную страницу в виде прямой, активной, нескриптовой, незакрытой от индексирования, и не запрещенной для следования роботов ссылки.
  Если соизволите поставить автора в известность — то вообще почёт вам и уважение.

© lissyara 2006-10-24 08:47 MSK