6.12 Оптимизация дисков

6.12.1.1 vfs.vmiodirenable

Значением переменной vfs.vmiodirenable может быть установлено в 0 (выключено) или 1 (включено); по умолчанию 1. Эта переменная отвечает за метод кэширования каталогов. Размер большинства каталогов невелик. Они могут поместиться в одном фрагменте (обычно 1K), и могут занимать ещё меньше места (обычно 512 байт) в кэше буфера. Однако, при работе в стандартном режиме буфер прокэширует только заданное число каталогов даже если у вас много памяти. Включение этого параметра sysctl позволит использовать страничное кэширование VM, делая доступным для кэширования каталогов весь объём памяти. Однако, минимальный объём памяти, используемой для кэширования каталогов стал равен объёму страницы (обычно 4 K) вместо 512 байт. Мы рекомендуем включить эту опцию, если ваш компьютер исполняет программы, манипулирующие значительным количеством файлов. Примером таких программ могут быть кэширующие прокси-серверы, большие почтовые серверы и серверы новостей. Обычно включение этой опции не понижает производительности, однако лучше поэкспериментировать, чтобы узнать оптимальное значение для вашей машины.

6.12.1.2 vfs.write_behind

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

6.12.1.3 vfs.hirunningspace

Переменная sysctl vfs.hirunningspace определяет число запросов записи на диск, которые могут быть поставлены в очередь. Значение по умолчанию обычно подходит, но на компьютерах с большим количеством дисков вы можете увеличить его до четырех или пяти мегабайт. Учтите, что установка слишком большого значения (превышающего размер буфера записи) может привести к очень значительному падению общей производительности. Не делайте это значение произвольно большим! Большие значения могут привести к задержкам чтения, выполняемого в то же время

Есть много других переменных sysctl, относящихся к кэшированию в буфер и страничному кэшированию VM. Мы не рекомендуем изменять эти значения. Начиная FreeBSD 4.3, система VM делает отличную работу по автоматической самонастройке.

6.12.1.4 vm.swap_idle_enabled

Переменная sysctl vm.swap_idle_enabled полезна в больших многопользовательских системах, где есть много пользователей, входящих и выходящих из системы, и множество ожидающих процессов. Такие системы обычно генерируют большое количество запросов на выделение памяти. Включение этой переменной и настройка задержки выгрузки (swapout hysteresis, в секундах) установкой переменных vm.swap_idle_threshold1 и vm.swap_idle_threshold2 позволит освобождать страницы памяти, занятые ожидающими процессами, более быстро, чем при нормальном алгоритме выгрузки. Это помогает даемону выгрузки страниц. Не включайте этот параметр, пока он на самом деле вам не понадобится, поскольку его действие в сущности заключается в более ранней выгрузке страниц из памяти; это повышает нагрузку на подкачку и диск. В малых системах эффект от включения этого параметра предсказуем, но в больших системах нагруженной на подкачкой этот параметр позволяет системе VM проще загружать и выгружать процессы из памяти.

6.12.1.5 hw.ata.wc

Во FreeBSD 4.3 кэширование записи на IDE диски было отключено. Это понижало производительность IDE дисков в тестах, но было необходимо для лучшей сохранности данных. Проблема состоит в том, что IDE диски неправильно указывают время завершения записи на диск. При включенном кэшировании IDE диски могут не только записать данные в неправильном порядке - при большой нагрузке на диск некоторые блоки могут задержаться до бесконечности. Сбой, или отключение питания могут могут стать причиной серьёзных повреждений в файловой системе. Поэтому для безопасности системы значение по умолчанию этого параметра было изменено. К сожалению, результатом этого стало столь значительная потеря производительности, что после выхода релиза значение этого параметра было возвращено в первоначальное состояние. Вам следует проверить значение переменной sysctl hw.ata.wc на вашей машине. Если кэширование выключено - вы можете включить его, установив значение переменной ядра, равное 1. Это должно быть сделано при помощи загрузчика при загрузке. Если вы сделаете это позже - изменения не будут иметь силы.

За более подробной информацией обращайтесь к ata(4).

6.12.1.6 SCSI_DELAY (kern.cam.scsi_delay)

Параметр настройки ядра SCSI_DELAY может использоваться для уменьшения времени загрузки системы. Значение по умолчанию велико и может составлять более 15 секунд в процессе загрузки. Уменьшение его до 5 секунд обычно работает (особенно с современными дисками). В новые версии FreeBSD (5.0+) должен использоваться параметр kern.cam.scsi_delay, настраиваемый во время загрузки. Этот параметр и параметр настройки ядра принимают значения в миллисекундах, а не в секундах.

6.12.2.1 Дополнительная информация о Soft Updates

Есть два традиционных способа записи метаданных файловых систем на диск. (Пример метаданных: индексные дескрипторы и каталоги.)

Исторически, поведение по умолчанию заключается в синхронном обновлении метаданных. Если каталог был изменен, система ждет, пока изменение не будет физически записано на диск. Содержимое файлов проходит через кэш и записывается на диск асинхронно. Преимущество этого способа в его надежности. При сбое во время обновления метаданные остаются в нормальном состоянии. Файл либо создается целиком, либо вообще не создается. Если блоки данных не были записаны в файл из буфера во время сбоя, fsck(8) сможет определить это и восстановить файловую систему, установив длину файла в 0. Кроме того, реализация этого способа проста и понятна. Недостаток в том, что обновление метаданных занимает много времени. Команда rm -r, например, последовательно удаляет все файлы в каталоге, и каждое изменение в каталоге (удаление файла) будет синхронно записано на диск. Сюда включаются обновления самого каталога, таблицы индексных дескрипторов, и возможно блоков, занятых файлом. Те же соглашения работают при распаковке больших иерархий (tar -x).

Другой вариант это асинхронное обновление метаданных. Это поведение по умолчанию для Linux/ext2fs и *BSD ufs с параметром mount -o async. Все обновления метаданных просто пропускаются через кэш буфера, как и содержимое файлов. Преимущество этой реализации в том, что нет необходимости ждать каждый раз, пока метаданные будут записаны на диск, поэтому все операции с большим объемом обновления метаданных будут происходить гораздо быстрее чем при синхронном обновлении. Кроме того, реализация все еще проста и понятна, поэтому риск появления ошибок в коде невелик. Недостаток в том, что нет никаких гарантий исправности файловой системы. Если во время во время обновления большого объема метаданных произойдет сбой (например, отключение питания, или нажатие кнопки reset), файловая система останется в непредсказуемом состоянии. Нет возможности определить состояние файловой системы после такого сбоя; блоки данных файла могут быть уже записаны на диск, а обновления таблицы индексных дескрипторов нет. Невозможно реализовать fsck, которая могла бы исправить получившийся хаос (поскольку необходимой информации нет на диске). Если файловая система была уничтожена во время восстановления, единственный способ восстановления -- запустить newfs(8) и воспользоваться резервной копией.

Обычное решение этой проблемы состояло в реализации протоколировании проблемной области (dirty region logging), известном как журналирование, хотя этот термин использовался неправильно и порой также применялся к другим формам протоколирования транзакций. Обновление метаданных как и прежде происходит синхронно, но в отдельную область диска. Позже они перемещаются туда, где должны быть. Поскольку область протоколирования это небольшая, последовательная область диска, головкам жесткого диска не приходится перемещаться на большие расстояния даже во время значительных обновлений, поэтому такой способ быстрее, чем синхронные обновления. Кроме того, сложность реализации довольно ограничена, поэтому риск внесения ошибок невелик. Недостаток в том, что все обновления метаданных записываются дважды (один раз в область протоколирования и один раз окончательно), поэтому при обычной работе производительность может понизиться. С другой стороны, в случае сбоя все незаконченные действия с метаданными могут быть быстро отменены, или завершены после загрузки системы, поэтому система после сбоя загружается быстрее.

Kirk McKusick, разработчик Berkeley FFS, решил эту проблему с помощью Soft Updates: все незавершенные обновления метаданных находятся в памяти и записываются на диск в упорядоченном виде (``упорядоченное обновления метаданных''). При значительных обновлениях метаданных более поздние обновления ``присоединяются'' к предыдущим, если они все еще находятся в памяти и еще не записаны на диск. Поэтому все операции, скажем, над каталогом, обычно выполняются в памяти перед записью обновления на диск (блоки данных сортируются в соответствии с их положением, так что они не будут записаны на диск до метаданных. При крахе операционной системы выполняется ``откат'': считается, что все операции, не записанные на диск, никогда не происходили. Файловая система находится в том состоянии, в котором она была за 30-60 секунд до сбоя. Используемый алгоритм гарантирует, что все используемые ресурсы маркированы соответствующим образом в своих областях: блоки и индексные дескрипторы. После сбоя могут остаться только ошибки, выделения ресурсов, они помечаются как ``используемые'', хотя на самом деле ``свободны''. fsck(8) разбирается в ситуации и освобождает более не используемые ресурсы. После сбоя система может быть безопасно смонтирована с опцией mount -f. Для освобождения ресурсов, которые могут не использоваться, в дальнейшем потребуется запустить fsck(8). Эта идея лежит в основе background (фоновая) fsck: во время запуска системы записывается только снимок файловой системы. Все системы могут быть смонтированы в ``грязном'' состоянии, и система загружается в многопользовательский режим. Затем, фоновые fsck ставятся в очередь для всех систем, где это требуется, чтобы освободить неиспользуемые ресурсы. (Файловые системы, где не используются Soft Updates, все еще требуют запуска fsck в обычном режиме).

Преимущество этого способа в том, что обновления метаданных происходят почти так же быстро, как при асинхронных обновлениях (т.е. быстрее, чем при журналировании, когда метаданные записываются дважды). Недостаток в сложности кода (подразумевающим больший риск появления ошибок в области, где вероятность потери данных пользователя особенно высока) и в более высоких требованиях к объему памяти. К тому же могут возникнуть некоторые странные на первый взгляд ситуации. После сбоя состояние файловой системы несколько более ``старое''. В ситуации, когда стандартный способ синхронизации оставит несколько файлов нулевой длины после выполнения fsck, в файловой системе с Soft Updates их не останется вовсе, поскольку ни метаданные, ни содержимое файлов не были записаны на диск. Дисковое пространство не будет освобождено пока обновления не будут записаны на диск, что может занять некоторое время после выполнения rm. Это может повлечь проблемы при установке большого количества файлов на файловую систему, где не хватает места для помещения всех файлов дважды.