Недавно я затрагивал темы загруженности устройств ввода-вывода Oracle и создания Ram-дисков.
Итак, в системе есть достаточно свободной памяти, менеджер томов — vxvm и есть приложение с высокой нагрузкой по вводу-выводу (например Oracle). А если у нас современный сервер, а Oracle standard edition, то так оно и будет (так как standard edition не может использовать более 2Гб памяти). Такая ситуация часто возникает, например на SAP серверах, когда используются 32-разрядные приложения.
Итак, идея такая:
- создаем ram-диск
- отдаем его под управление vxvm
- зеркалим на него наиболее загруженные по чтению тома vxvm
Попробуем это реализовать (в теории).
ramdiskadm -a mydisk 8g
ln /dev/ramdisk/mydisk /dev/dsk/mydisk
ln /dev/rramdisk/mydisk /dev/rdsk/mydisk
vxdisk define mydisk type=nopriv volatile
vxdg -g DG01 adddisk RAMDSK01=mydisk
vxassist -g DG01 mirror volume VOL01 RAMDSK01
vxvol -g DG01 rdpol prefer VOL01 VOL01-02
Что нам дает такая схема:
- при чтении с тома — данные читаются из ram-диска (значительно поднимается скорость операций ввода-вывода, снижается количество обращений к физическим дискам)
- при записи — пишутся одновременно на оба зеркала (надежность записи не уменьшается)
- более эффективное использование оборудования и ПО
Можно использовать данное решение не для Oracle, а для любого тома с высокой загрузкой.
PS. так как сейчас нет возможности проверить самому — был бы рад, если кто-нибудь решит попробовать это решение и напишет в комментарии о результатах ;)
19.11.2008 в 12:35
Автора необходимо лечить электричеством :)))))))
Если есть достаточно памяти, чтобы зазеркалить на нее диски %), лучше просто отдать ее Oracle под кэш — кэш существует в том числе и для того, чтобы ускорять чтение. Невозможность использовать под Oracle Standard Edition более 2 ГБ RAM — сугубо личная проблема автора, т.к. такого ограничения не существует.
а особо здорово будет работать предложенная автором схема, когда дисковая составляющая зеркала отвалится, а Oracle этого не заметит усилиями vxvm. До перезагрузки ;)
19.11.2008 в 16:51
электричеством уже лечусь ;)
я так понимаю, что имеется в виду buffer cache? довожу до вашего сведения, что больше 1.75 гб на 32-битном оракле отдать под sga не получится, а oracle standard edition под Solaris бывает только 32 битный.
По поводу vxvm — ну если если не следить за системой, то никакое зеркалирование, ни какие дополнительные дисковые массивы, ни какой мультпатинг не помогут. В такой ситуации и нужен админ. Но, на всякий случай, резервное копирование и редологи никто не отменял.
Вероятность того, что отвалится один из 50 дисков, например, при том, что именно том на нем был зазеркален на ram-диск, скажем так, очень низкая.
И еще, как бы эта идея не позиционируется как универсальное лекарство. Это просто идея, а кто из нее что вынесет и как будет использовать — личное дело каждого ;)
19.11.2008 в 23:04
Лечение электичеством отменить как неэффективное, назначить чтение мануалов. Прочитать о use_indirect_data_buffers и вытекающей возможности использовать большие объемы памяти под 32 бита. Использовать, наслаждаться.
По поводу «какой бывает Oracle».Standard Edition — это не какой-то особенный дистрибутив. Бинарники те же, что и для EE, просто фичи можно использовать не все. Отсюда мораль: Standard Edition 64-bit для Solaris вполне себе есть. Мало того, Oracle 32-bit для Solaris SPARC нет, начиная с версии 10g, а для Solaris x86 — начиная с 11g. Смотреть тут: http://www.oracle.com/technology/software/products/database/index.html
По поводу vxvm — конечно мониторить систему необходимо и должен быть грамотный админ, а бэкапы ОБЯЗАНЫ быть (мы же строим профессиональное решение, правда?). Но вот «Вероятность того, что отвалится один из 50 дисков» — поверьте отвалится именно ТОТ и админ не успеет отреагировать. (поверьте, случаи бывают такие невероятные, примеров тому в инете масса)
Если серьезно — идею перед опубликованием нужно прорабатывать. Тогда она, возможно, будет вызывать меньше смеха и больше конструктива. А может быть даже и не опубликуется ;)
20.11.2008 в 01:19
я так понимаю, что вас смутил именно оракл? ну он здесь использован просто как универсальная нагрузка.
ок, с ораклом уговорил, параметр use_indirect_data_buffers никогда раньше не попадался под руку (может потому что ораклом не занимаюсь :) а вот ситуации, когда на серверах стоит oracle 8-9, и используется всего 2гб рамы — навалом.
А решение можно использовать, например, во время пиков нагрузки — во время биллинга, бухгалерских отчетных периодов, итд. Когда на 1-2-3 дня в месяц нагрузка на оборудование возрастает многократно. Увидел, что массив начал задыхаться — создал скриптом ram-диск, отзеркалил, нагрузка упала — удалил.
Ну что еще — можно использовать такой подход не только для оракла, а для любого высокозагруженного тома, создания инстансов тестирования , для создания временных копий данных , снэпшотов, массовой параллельной записи (с отрывом физического диска, а потом репликации) ну итд.