 |
|
UNDERSTANDING ORACLE
RAM MEMORY PAGING
Oracle Database Tips by Donald Burleson
|
Большинство настройщиков
операционной системы правильно полагают, что столбец pi в утилите
vmstat сигнализирует, что сервер свопирует (swapping - обмен) RAM-память.
Однако, здесь есть свои ньюансы.
Нет такогого момента
времени, чтобы значение в столбце pi было равно нулю. Например, когда
стартует какой-либо процесс, первые две страницы программы загружаются в память.
Если стартует двадцати мегабайтный исполняемый модуль, вовсе не требуется
загружать все 20М в RAM-память. Нужно загрузить только используемые фрагменты. В
дальнейшем UNIX будет подгружать только необходимое, применяя принцип
пространственного расположения, чтобы минимизировать количество страниц,
используемых для организации набора работ.
Для того, чтобы управлять
сегментами памяти, для каждой программы, когда она стартует, ядро UNIX строит
полную карту памяти. В ней показывается, где находится страница: "в памяти" ("in
memory") или "на диске обмена" ("on swap disk").
Коль скоро программа
стартовала, она будет обращаться к тем страницам, которых нет в памяти, которые
вызываются по требованию. Таким образом, когда стартует большое число программ,
видно прирастание значения в столбце pi утилиты vmstat,.
В различные точки времени
нормального функционирования мы можем видеть, когда обмен страницами (paging -
пейджинг) совершается активно, и в этом нет проблем - стартует новая программа
или производится обращение к частям кода, которые до этого не были задействованы.
Выводной (Paging out -
po) обмен страницами в течение дня случается по причинам, определяемым ОС.
Если хватает памяти, то нет надобности в удалении страниц. Когда процесс
завершается (умирает), его страницы становятся свободными, и они могут быть
использованы для других процессов. И если мы видим, что пейджинг из системных
файловых буферов довольно невелик, то в повседневных ситуациях мы обычно
игнорируем выходной пейджинг.
Поэтому, если входной
пейджинг приемлен, а выходной - прекрасен, то как узнать, что заставляет сервер
занимается свопингом памяти?
Ответ в контроле
коэффициента сканирования (scan rate). Когда сервер начинает медленно
работать с памятью, видно, что бьеться (kick) с высокой скоростью
page-stealing (букв.: ворующий страницы) демон (daemon - системный
процесс), или, иначе, демон страничного сканирования (page-scanning daemon).
Когда достигается некий предопределенный порог объема свободной памяти (определенный
специальным параметром ядра), страничный демон начинает панику. Он стартует
выводной пейджинг всех типов страниц из списка NRU (или LRU).
Если мы увидим, что
страничный демон бьется со скоростью 200-300 сканирований в секунду, время
начинать волноваться. Связано ли это с увеличением выводного пейджинга (очевидно)
или (вероятно) с увеличением входного пейджинга, это состояние известно как
нехорошее (thrashing). Мы также можем увидеть нарастание количества системных
вызовов и высокий коэффициент системного использования CPU.
Если начинается обмен
(swap), это значит, что исчерпана вся RAM-память, которая может быть ассигнована
для нормального ведения дел - мы исчерпали ресурсы страничного демона и ушли за
второй порог, что означает: "stop taking tiny pieces and take this whole process
completely out." ("остановка действий малыми частями, оборот целыми
процессами"). Этот выводной обмен будет освобождать для кого-то еще пространство
RAM.
Итак, если администраторы
концентрируются только на пейджинге, чтобы определить проблемы с памятью, они
часто не могут сказать, функционирует ли пейджинг в нормальном режиме или
потенциально имеют место проблемы обмена.
Ответ подскажет значение
столбца sr утилиты vmstat, который определяет коэффициент
сканирования. Если мы видим, что значение sr устойчиво повышается, а
затем стремительно стремится к переполнению, то мы превысили первый порог. В
этом случае мы наблюдаем, что достигнут реальный свопинг (page-in операции).
UNIX-утилита sar -
это тот инструмент, который сообщает сведения об активности памяти. Она имеется
на многих ОС и вполне заменяет другие утилиты.
Приведем простой пример ее
запуска и выводного листинга
root>sar -w 5 5
HP-UX corp-hp B.11.00 U 9000/800 08/09/00
19:37:57 swpin/s bswin/s swpot/s bswot/s pswch/s
19:38:02 0.00 0.0 0.00 0.0 222
19:38:07 0.00 0.0 0.00 0.0 314
19:38:12 0.00 0.0 0.00 0.0 280
19:38:17 0.00 0.0 0.00 0.0 295
19:38:22 0.00 0.0 0.00 0.0 359
Average 0.00 0.0 0.00 0.0 294
Некоторые важные флажки
используются только в версиях Sun и не доступны на HP/UX. Для того, чтобы
использовать sar, надо запустить программу sadc, которая по
умолчанию собирает информацию за каждые пять минут. (Я обычно делаю раз в
минуту.) Затем используйте:
- sar -u, чтобы увидеть
статистику CPU за некоторый период времени,
- sar -w для получения
статистики обмена,
- sar -r для получения
статистики по памяти и
- sar -d для получения
статистики об использования диска.
Ускорение ORACLE-импорта
Когда импортируются
большие объемы промышленных данных, создайте работу (job), которая может быстро
сделать с большими различиями для ваших конечных пользователей. В Oracle мы
часто видим импорт, сделанный как часть реорганизации таблицы Oracle или как
часть перемещения данных.
Существует несколько
приемов, которые помогут вам повысить скорость выполнения утилиты Import.
Рекомендую попробовать некоторые приемы, приводимые ниже:
- Включите в
параметрический файл утилиты большого значения BUFFER. Это сократит
количество операций ввода/вывода базы данных, поскольку сокращается число
обращений Oracle к экспортному файлу. Можно установить это значение в
несколько мегабайтов (этого обычно достаточно), но только, если у вас
достаточно памяти для использования буфера такого большого объема. Опять же
проверьте пейджинг и свопинг на уровне операционной системы, чтобы увидеть,
не переборщили ли вы;
- Всегда используйте
фразу INDEXES=N. Индексы лучше (быстрее) создать после авершения импорта
таблицы;
- Используйте один
большой выделенный сегмент отката для импорта. Для того, чтобы сделать это,
переведите другие сегменты отката в offline. Одного сегмента отката,
размером приблизительно 50 поцентов от объема самой большой импортируемой
таблицы, будет достаточно;
- Включите в
параметрический файл фразу COMMIT=N. Это заставит утилиту Import выполнять
фиксирование (commit) после импорта каждого объекта (таблицы), а не после
каждого буфера, что сократит число операций COMMIT, но поэтому и требуется
большой сегмент отката;
- Запустите базу данных
в режиме NOARCHIVELOG, пока производится импорт. Это сократит издержки при
создании и управлении архивными файлами. После невосстановимых
(unrecoverable) операций, однако, должно немедленно сделать холодное
резервирование, чтобы гарантировать возможность наката (roll-forward).
Don Burleson - один
из ведущих экспертов по базам данных Oracle, написал 10 книг, опубликовал свыше
60 статей в национальных журналах. Работает Главным редактором ORACLE INTERNALS,
головного журнала по базам данных Oracle. Как ведущий консультант по
корпоративным базам данных, Don работал с многими корпорациями из списка
"Fortune 500 corporations", создавая надежные архитектуры баз данных для их
жизненно-важных систем.