суббота, 6 июня 2009 г.

RAM-диски в Solaris, часть II

Ранее я уже писал об опытах с RAM-дисками в Solaris. К сожалению, на тот момент у меня не было времени довести работы до конца и, в частности, написать сервис SMF, позволяющий автоматически создавать RAM-диски в момент старта системы.

Собственно, и необходимости особой на тот момент в этом не было.

Однако времена меняются, и такая задача возникла.

Возникла, как ни странно, в связи с ZFS.

Как известно, ZFS в текущей версии может быть кэширована (что используется в иерархических системах хранения) и имеет ZIL - ZFS Intent Log, журнал намерений, который можно размещать на сверхбыстродействующих устройствах, что позволяет очень сильно ускорить синхронную запись на ZFS в некоторых применениях.

Некоторые джентльмены жалуются, что ZFS сильно проигрывает UFS в синхронной записи в определенных приложениях. Более того, они жалуются, что сырые устройства (raw devices) по-прежнему впереди и на лихом коне в плане производительности.

Собственно, данное исследование (тюнинг синхронной записи на ZFS при размещении ZIL на отдельном скоростном устройстве) еще впереди, а пока речь пойдет о завершенной наконец работе с RAM-дисками.

Собственно, примерно за четыре дня был написан SMF-сервис RAM-диска, аналогичный данному скрипту, только в современном исполнении и для SMF (а не скриптов rc).

По различным причинам я не посчитал целесообразным делать поддержку множественных RAM-дисков и конфигурационных файлов. Вместо этого добавлена поддержка:

- Только создания RAM-диска как сырого устройства, без форматирования и автоматического монтирования.

- Форматирования RAM-диска не только в UFS, но и в ZFS, с автоматическим монтированием и поддержкой особых случаев: например, аварийного падения системы бывает трудновато запустить систему с отсутствием ZFS-пулов, которые система считает своей частью.

Разумеется, раз используется ZFS, есть возможность задавать или менять несколько особенно сильнодействующих параметров (в readme описано, каких именно и почему) файловой системы (пула).

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

Практика показала, что иметь автоматически создаваемый RAM-диск с автосохранением его данных весьма полезно в целом ряде случаев.

Следует иметь в виду одну особенность RAM-дисков в Solaris.

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

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

Например, маньяки, которые любят заниматься сексом в трех-четырех презервативах ;) и гоняющие Солярис в виртуальной машине под WinXP на ноутбуках, выделив Солярису 512 Мб памяти (если им вообще удастся его запустить на таком количестве), будут стонать, что не могут вообще создать никакой RAM-диск.

Разумеется, не могут. Законы сохранения действуют в IT так же, как и в остальном физическим мире. Мегабайты и мегагерцы ничем не заменишь.

В случае же, если вышеупомянутые маньяки таки сумеют выделить Солярису гигабайт и отрезать от него 128 Мб под RAM-диск, они также взвоют, что, вопреки всем публикациям и здравому смыслу, RAM-диск работает ужасающе медленно.

На мой взгляд, выполнение ОС в виртуальной машине вообще противоречит здравому смыслу в большинстве случаев (исключения чрезвычайно редки), и, на мой же взгляд, в подобном случае все справедливо. В трех презервативах ничего чувствовать нельзя - уж не обессудьте. ;)