Update 1. disk_asynch_io=true (значение по умолчанию) рекомендуется для любых вариантов установки Oracle on AIX.
Update 2. AIX6 + 10GR2 все в порядке, детали в комментариях. Кажется проблема только с 11gR2 .
Если вы эксплуатируете Oracle on AIX вы обязаны прочитать вот эту
whitepaper. Замечательный документ. Однако в нем есть несколько тонких моментов. Один из них - рекомендации по монтированию файловой системы для файлов данных. Стр 55 в частности сообщает:
Это абсолютно правильное сообщение.
Oracle Support также согласен с вышеприведенной рекомендацией (MOS
ID 960055.1)
Здесь нужно сделать маленькое отступление, чтобы понять, почему так много уделяется внимания этому вопросу. Без указание опции cio производительность СУБД Oracle во многих слуаях была неудовлетворительной. C опциями монтирования по умолчанию происходило двойное кэшировние данных, в кэше файловой системы и buffer cache Oracle. Дополнительно. такая конструкция потребляет лишнее процессорное время. Кстати, это же справедливо и для СУБД DB2 -). Многие заказчики почему-то забывали про это, и данная рекомендация всегда была одной из первых которая выдавалась в случае наличия проблем.
Итак - вывод очевиден, теперь filesystemio_options=setall и никаких больше cio?
Однако инженеры IBM из Montpelier, считают по другому, их строгая рекомендация использовать filesystemio_options=async и строго cio. Один из заказчиков попросил аргументировать. Пожалуйста !
Итого, рассматриваем конфигурации:
#1, filesystemio_options=setall, опция монтирования rw
#2, filesystemio_options=async, опция монтирования cio
Использовалась Oracle Database 11.2.0.2, AIX 7. Для начала мы провели эксперимент используется ли кэш файловой системы. Оказалось, что в обоих случаях он не использовался. Т.е. кажется что рекомендация #1 имеет право на жизнь. Правда при более внимательном рассмотрении оказалось, что при использовании рекомендации #1 ...не используется Async I/O. Мониторинг проводился командой:
iostat -A 1 | awk '/avg/ {if(x!=1){print; getline; print; x=1}else{getline; print}}'
aio: avgc avfc maxgc maxfc maxreqs avg-cpu: % user % sys % idle % iowait physc % entc
0.0 0.0 0 0 48 0.3 1.8 97.9 0.0 0.0 4.4
0.0 0.0 0 0 48 0.2 1.8 97.9 0.0 0.0 4.5
Данная команда показывает кол-во асинхронных операций ввода-вывода. Опять нужно сделать небольшое отступление, что в AIX есть несколько вариантов Async I/O. Исторически в AIX существали async I/O сервера и async I/O шел черех них (AIX 5). Однако позже (AIX 6) сделали kernel async I/O для сырых устройств и, главное файловой системы. Так вот оказывается, если у вас идет async I/O для сырых устройств то не нулевые значения появляются в колонке avfc, а если kernel file system asycn I/O то в колонке avgc. В обоих случаях, если async I/O - kernel, то async I/O сервера (процессы
aioserver) не поднимаются. Мониторить кол-во aio серверов удобно в nmon, там показывают пиковое кол-во активных (в идеальном случае должно быть близким к 0).
При помощи команды lsof удалось выяснить, как именно открывает Oracle файлы данных в варианте #1:
oracle 39846142 oracle 12u VREG R,W,CIO,DSYN,LG,0x800000000;CX 39,1 1069555712 33 /oradata/data (/dev/dsvolkssdlv)
grep -i "0x800" vmount.h
#define VFS_DIO 0x80000000 /* O_DIRECT mount */
На мой взгляд это объясняет все происходящее: вариант #1 работает с direct I/O, что для AIX не слишком оптимально. Это значит, что все описанное в IBM whitepaper и MOS верно, но не самый оптимальный вариант. Вариант #2 сохраняет оптимальный ввод-вывод, формально называемый file system fast patch async I/O.
Резюме: пожалуйста продолжайте использовать опции монтирования cio для размещения файлов данных Oracle на AIX.
Сообщения
