Кэш страниц файловой системы UNIX

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

Хотя кэш страниц файловой системы UNIX может оказаться достаточно эффективным для операций чтения, буферный кэш БД адекватного размера реализует более эффективную стратегию кэширования, чем та, которую обеспечивает кэш второго уровня, предоставляемый операционной системой. Аналогичное утверждение справедливо и для кэширования операций записи. Иногда в системах с большими объемами памяти может потребоваться 64-разрядная СУБД, чтобы установить буферные кэши соответствующего размера.

•             Некоторые приложения, такие как большие пакетные задания, от кэширования страниц памяти получают небольшие выгоды или вообще не получают никаких, к тому же применение UFS означает, что каждая страница памяти должна быть занесена в кэш UNIX прежде, чем она сможет быть использована. Как только все свободные страницы задействованы, в дело вступает демон страниц памяти, который выполняет поиск "чистых" страниц для использования их конкретным приложением. Если "чистые" страницы памяти не доступны, то "грязные" страницы должны быть отправлены на диск прежде, чем они будут готовы для использования приложением. Когда достигается эта точка, производительность может резко снизиться, особенно если данное приложение постоянно изменяет страницы памяти. При непосредственном использовании низкоуровневых устройств СУБД может более эффективно реализовать описанный процесс управления страницами.

•             Доступ к файлам UFS иногда влечет за собой двойное чтение. Страницы памяти считываются в буферный кэш БД через страничный кэш файловой системы. Если изменяется страница в буферном кэше БД, то может пройти некоторое время до того, как эта страница будет записана на диск, поскольку эта операция выполняется независимо посредством очистителей страниц памяти.

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

•             Выполнение многочисленных записей в файл UFS ограничивается единственной блокировкой механизма записи UFS, как это определено стандартом POSIX, которая препятствует любому процессу осуществлять чтение из файла или запись в файл, если какой-нибудь другой процесс уже выполняет запись в этот файл. Это ограничение может оказать основное негативное воздействие на производительность в том случае, если интенсивный ввод/вывод осуществляется с одним файлом UFS. Начиная с Solaris 8 1/01, проблема единственной блокировки механизма записи преодолевается посредством использования файловых систем UFS в сочетании с прямым вводом/выводом (флаг forcedirectio в конфигурационном файле /etc/vf sstab). Указанная проблема более подробно обсуждалась ранее в разделе "Расширения файловой системы UNIX" в главе 3.

•             Даже несмотря на то, что размер блока БД может быть равен 2 Кбайт, все операции ввода/вывода БД, размещенной на файловой системе UFS, выполняются блоками по 8 Кбайт, поскольку файлы открываются с флагом 0_DSYNC. Результатом может быть даже четырехкратное увеличение производительности чтения, если большинство операций чтения носят случайный характер. Точно так же все блоки записи размером 2 Кбайт превращаются в блоки размером 8 Кбайт; если страница размером 8 Кбайт в настоящее время отсутствует в памяти, то операции записи должна предшествовать операция чтения блока размером 8 Кбайт.

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

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


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