суббота, 30 мая 2009 г.

Oracle, Solaris, ZFS и свободная память

Насколько в действительности велики требования по оперативной памяти у ZFS при реальной работе?

Sun говорит, что нужно впридачу к требованиям системы и приложений еще минимум 1 Гб.

В принципе, верно. На машинах всего с 1 Гб оперативной памяти действительно ZFS хорошо не работает, а с Ораклом есть недурные шансы вообще что-то не запустить.

Впрочем, "Вж-ж-ж-ж-ж! - сказала пила, - Ага-а-а-а! - сказали мужики" - надо быть полным 8-5, чтобы, вопреки законам сохранения реального мира пытаться заставить работать подобное при практическом отсутствии ресурсов (хотя, как ни странно, такие находятся с завидной регулярностью, пытаясь пилить пилой, например, лом - и исходя криком "Мастдай!" когда выясняется, что это невозможно. Откуда берутся такие личности - сие мне неведомо, по идее, рождаться они не должны вообще - однако их, видимо, просто мечут как икру).

Давайте немного разберемся, как и почему ZFS используем память и - самое главное - как много?

Если Солярис стоит на UFS, то память, которая идентифицируется системой как свободная, в действительности занята - кэшами файловых систем. Если только они не смонтированы с опцией direct IO.

Оракл в этом случае при малейших огрехах в конфигурации инстанса работает достаточно медленно - и это мягко сказано.

Хотя двойное кэширование и считается злом, прямое монтирование (либо использование raw devices) либо дает мизерный выигрыш (в сравнении с очень осложненным администрированием) либо не дает его, а иногда и вовсе выигрыш оборачивается проигрышем.

Чекпойнтинг кэшей UFS выполняется достаточно часто, чтобы не беспокоиться о целостности БД. Причем планировщиком ZFS выполняется аггрегация записей в кэше, и сброс множества мелких записей одной пачкой, как во многих реляционных СУБД (хочу напомнить параметр db_file_multiblock_read_count в Оракле. От его максимизации растут ноги у уменьшения отклика БД в определенных конфигурациях - что физически не знают большинство DBA).

Что до памяти, кажущейся свободной - и в действительности занятой кэшами файловой системы - то она освобождается по первому требованию, так как страницы процессов имеют в ядре Солярис безусловный приоритет над кэшем.

В случае с ZFS кэши нужны в значительно большей степени.

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

Ключевым словом является термин ARC. Цитирую дословно один из первоисточников: The ZFS adaptive replacement cache (ARC) tries to use most of a system's available memory to cache file system data. The default is to use all of physical memory except 1 Gbyte. As memory pressure increases, the ARC relinquishes memory.

Замечание: Сразу становится понятно, откуда взялось требование +1 Гб.

Фактическое двойное кэширование в данном случае во-первых, не ведет к повышению вероятности нарушения целостности БД в силу транзакционной семантики ZFS и наличию ZFS Intent Log – ZIL), а во-вторых, не снижает производительности, так как даже на UFS/JFS отключение write behind кэша фактически зарезает производительность записи до абсолютного минимума. Посему кэширование напротив способствует повышению скорости записи или чтения.

Тем, у кого проблемы с пониманием принципов и наличествуют неумные вопросы - предлагаю все же попрактиковаться в чтении концепций, которые содержат ответы на большинство вопросов и с чего, собственно, надо начинать, приступая к играм с любыми новинками. Дабы после не стонать, что его обманули, обещали бешеную производительность - а не получилось!

Замечание: Некоторые трахнутые маньяки почему-то считают, что полное отсутствие дополнительного кэширования, особенно в сочетании с raw devices, имеет бешеное преимущество по скорости. Тут следует заметить, что, во-первых, не бешеное, а всего лишь 10-15%. Интересующихся, кто это сказал, отсылаю читать трахнутый оракловый мануал Performance Tuning Guide, особенно его приложения. Во-вторых, такие джентльмены волокут БД на raw devices, напрочь игнорируя тот факт, что даже эти 15% они могут получить лишь при адекватном тюнинге инстанса и, в особенности, при выставлении величины предвыборки Оракла в максимум, и, перед этим, такой же установки на уровне ОС и ее драйверов SCSI. В остальных случаях маньяки по заслугам получают усложнение администрирования до предела, холодный физический бэкап средствами dd а также отсутствие сверхзвукового выигрыша и, благодаря этому, проводят время не за пивом-ца-ца, а за консолью, в ожидании завершения процесса. :) Ах, обманули! Где быстрая работа баз данных? Где вообще скорость дисковой системы? Как посекторно? Ой, восстанавливать физический бэкап посекторно?! Нам не сказали! То есть как ASM и RMAN? Мама, роди-ка меня обратно!

Вернемся к нашей теме.

Итак, при использовании ZFS свободная память остается в разных количествах.

Если, например, использовать кучу мелких файлов, то, как ни странно, свободной памяти более, чем достаточно.

Взгляните на прокси-сервер, который находится исключительно на ZFS и у которого кэшируется огромное количество мелких файлов:

last pid: 430; load avg: 0.00, 0.00, 0.00; up 0+02:15:52 15:52:39
40 processes: 39 sleeping, 1 on cpu
CPU states: 99.2% idle, 0.2% user, 0.6% kernel, 0.0% iowait, 0.0% swap
Kernel: 96 ctxsw, 320 intr, 171 syscall
Memory: 2043M phys mem, 1640M free mem, 2048M total swap, 2048M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
247 root 4 54 0 25M 21M sleep 0:02 0.29% named
430 root 1 1 0 2992K 1828K cpu 0:04 0.07% top
382 squid 1 1 0 16M 13M sleep 0:04 0.05% squid
401 root 1 100 -20 2556K 1296K sleep 0:00 0.01% xntpd
398 root 1 59 0 7884K 3400K sleep 0:00 0.00% sshd
7 root 12 29 0 11M 8820K sleep 0:02 0.00% svc.startd
383 root 1 1 0 11M 4788K sleep 0:00 0.00% httpd
109 root 1 1 0 2700K 708K sleep 0:00 0.00% ipmon
9 root 14 29 0 10M 9192K sleep 0:08 0.00% svc.configd
235 root 1 1 0 1432K 640K sleep 0:00 0.00% utmpd
236 root 18 1 0 12M 9124K sleep 0:01 0.00% fmd
404 root 1 1 0 3056K 2072K sleep 0:00 0.00% bash
65 root 6 1 0 3620K 2036K sleep 0:00 0.00% devfsadm
378 root 12 1 0 4016K 1872K sleep 0:00 0.00% syslogd
1 root 1 1 0 2492K 1428K sleep 0:00 0.00% init

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

Что касается кэширования крупных файлов при небольшом их количестве, например, оракловые БД, то здесь картина другая. Свободной памяти реально мало:

load averages: 0.05, 0.07, 0.10; up 0+02:43:14 15:54:49
73 processes: 72 sleeping, 1 on cpu
CPU states: 99.3% idle, 0.3% user, 0.4% kernel, 0.0% iowait, 0.0% swap
Kernel: 205 ctxsw, 443 intr, 174 syscall
Memory: 4096M phys mem, 147M free mem, 8192M total swap, 8192M free swap

PID USERNAME LWP PRI NICE SIZE RES STATE TIME CPU COMMAND
7124 root 1 59 0 3912K 2224K cpu/0 0:00 0.13% top
494 oracle 1 59 0 0K 0K sleep 0:07 0.10% oracle
4837 oracle 1 59 0 0K 0K sleep 0:02 0.06% oracle
4839 oracle 1 59 0 0K 0K sleep 0:07 0.05% oracle
4814 oracle 32 29 10 268M 146M sleep 6:08 0.05% java
490 oracle 11 59 0 0K 0K sleep 0:12 0.04% oracle
474 oracle 1 59 0 0K 0K sleep 0:06 0.03% oracle
484 oracle 20 59 0 0K 0K sleep 0:14 0.03% oracle
5131 oracle 1 59 0 0K 0K sleep 0:08 0.01% oracle
203 root 13 59 0 164M 30M sleep 0:04 0.01% java
480 oracle 200 59 0 0K 0K sleep 1:59 0.01% oracle
136 root 6 59 0 4736K 2280K sleep 0:01 0.01% picld
5104 oracle 7 29 10 38M 29M sleep 0:16 0.01% emagent
482 oracle 15 59 0 0K 0K sleep 0:59 0.00% oracle
512 oracle 3 59 0 0K 0K sleep 0:01 0.00% tnslsnr

Но при этом - внимание! - спокойно запускаются процессы и практически полностью отсутствует подкачка, что говорит о том, что и кэши ZFS убираются из памяти по первому запросу на память.

Как и было сказано у первоисточника: The ARC is where ZFS caches data from all active storage pools. The ARC grows and consumes memory on the principle that no need exists to return data to the system while there is still plenty of free memory. When the ARC has grown and outside memory pressure exists, for example, when a new application starts up, then the ARC releases its hold on memory. ZFS is not designed to steal memory from applications. A few bumps appeared along the way, but the established mechanism works reasonably well for many situations and does not commonly warrant tuning.

Более того, данную машину крайне сложно заставить свопиться. Хотя EM на ней и ругается на то, что память занята по самые не улыбайся и шлет алерты почтой:

Name=hostname.domain.com
Type=Host
Host=hostname.domain.com
Metric=Memory Utilization (%)
Timestamp=May 30, 2009 3:43:29 PM ALMT
Severity=Critical
Message=Memory Utilization is 95.78%
Rule Name=Host Availability and Critical States
Rule Owner=SYSMAN

Ну, коль скоро нетрудно убедиться, что этот алерт в случае ZFS вовсе не повод для тревоги, стоит повысить величину metric thresholds, чтобы не беспокоил:


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

При этом прошу также обратить внимание, что Оракловая БД работает как часы - без единой задержки.

Напоследок обращаю внимание маньяков, что в обеих вышеприведенных примерах не используется raidz или, тем более, raidz2. Здесь это говорится буквально: For better performance, a mirrored configuration is strongly favored over a RAID-Z configuration particularly for large, uncacheable, random read loads. А здесь объяснено в деталях, почему. Не менее внятно объяснено у первоисточника.

PS. Настоятельно советую маньякам прочесть также здесь, здесь и здесь.