Низкоуровневые устройства или UFS?

Оценить
(0 голоса)

Хорошей отправной точкой для начала планирования эффективного размещения данных является принятие одного из наиболее фундаментальных решений в этой области: выбор между низкоуровневыми устройствами и файлами UFS.

В каких случаях следует использовать файлы UFS в качестве файлов БД, а в каких - низкоуровневые устройства? Ответ на этот вопрос довольно прост: если основной целью является достижение высокой производительности, всегда используйте низкоуровневые устройства. Это простое эмпирическое правило является справедливым для любых файлов баз данных, и прежде всего - для файлов журналов БД. Максимальное повышение производительности достигается при перемещении журналов с файловой системы UFS на низкоуровневые устройства (или на файлы прямого ввода/вывода), даже если остальные файлы БД остаются в файловой системе UFS. Можно пойти еще дальше и сказать, что файлы UFS никогда не должны использоваться для журналов БД за исключением, возможно, небольших баз данных, в которых производительность не является важным требованием, а во всех остальных случаях файлы низкоуровневых устройств или прямого ввода/вывода являются гораздо более удачным решением.

Размещение файлов БД на низкоуровневых устройствах обеспечивает в целом ее наилучшую производительность в силу следующих причин:

•             Все основные СУБД для получения доступа к страницам БД применяют асинхронный ввод/вывод, хотя не все они используют исключительно асинхронный ввод/вывод. Когда асинхронный ввод/вывод выполняется на низкоуровневых устройствах, Solaris автоматически вызывает КАЮ (Kernel Asynchronous I/O -асинхронный ввод/вывод ядра). Использование КАЮ уменьшает количество машинных команд, необходимых для завершения ввода/вывода, и исключает взаимодействие между привилегированным (ядра) и пользовательским режимами библиотеки libaio. В результате операции ввода/вывода завершаются быстрее, и при этом используется меньшее количество ресурсов ЦП. В результате повышается производительность. Для файловых систем также поддерживается асинхронный ввод/вывод, однако он реализуется с помощью пользовательской библиотеки libaio; КАЮ не доступен для файлов UFS даже в том случае, когда используется асинхронный ввод/вывод.

•             При работе с низкоуровневыми устройствами "маршрут программного кода" в ядре Solaris становится намного короче (иными словами, чтобы завершить операцию ввода/вывода, требуется меньшее количество машинных команд), чем при работе с файлами UFS. Это связано с организацией кэширования на уровне UNIX, выполняемого ядром со стороны файлов UFS. Этот более короткий маршрут программного кода означает, что низкоуровневые операции ввода/ вывода не только завершаются быстрее, но и для их выполнения расходуется меньшее количество ресурсов ЦП.

•             Кэш страниц файловой системы UFS может негативно влиять на производительность, особенно для пакетных заданий с большим количеством операций вставки или обновления данных.

•             При выполнении загрузки системы должна быть проверена целостность файловых систем (с использованием утилиты f sck), что приводит к увеличению времени восстановления системы после отказа. Тем не менее, протоколирование UFS, которое поддерживается, начиная с Solaris 7, существенно уменьшает время восстановления файловой системы. Для получения дополнительной информации по этому вопросу обратитесь к разделу "Протоколирование файловой системы UFS" в главе 3.

Кэш страниц файловой системы UNIX
Операции записи в журнал
Альтернативные варианты файловых систем
Достижение оптимальной производительности в файловых системах
Правильный и неправильный способы расслоения

Добавить комментарий


Защитный код
Обновить