Оценка необходимого объема ОЗУ
Оценка необходимого объема ОЗУ
Для оценки необходимого объема ОЗУ, необходимо провести инвентаризацию всех процессов-потребителей.
Типовые потребители ОЗУ базирующихся на платформе OpenEdge систем :
- Память операционной системы
- Процессы операционной системы
- Буферная память операционной системы
- Исполняемые процессы OpenEdge
- Память выделяемая процессам Openedge для работы
- Брокеры БД
- Сервера удаленных клиентов (remote clients)
- Другие сервера OpenEdge (например, сервера приложений)
- Клиентские процессы (пакетные (batch)процессы, самообслуживающиеся клиенты (self-service clients))
- Определение памяти для операционной системы
Требования к памяти со стороны операционной системы
Требования операционной системы весьма различны. Можно поделить системы на
- Маленькие – занимаемая память от 32мб до 64мб
- Большие — 128 и выше.
Как правило, маленькие системы обслуживают до 100 пользователей, а большие – сотни. Эти цифры — примерные, так как существуют системы, которые обслуживают маленькое количество пользователей, но исполняют внутри себя большое количество процессов, что как раз и характерно для больших систем.
Размер буферной памяти операционной системы зависит от физического размера ОЗУ. Большинство систем резервируют от 10 до 15 процентов ОЗУ для такой памяти. Этот параметр является настраиваемым для большинства операционных систем. Хорошим тоном считается выставление лимита для буферной памяти в 10% от физической, остальную память необходимо распределить для процессов OpenEdge. О том, как выставить такие лимиты смотрите в документации вашей операционной системы.
Использование ОЗУ процессами OpenEdge
OpenEdge использует технологию совместного доступа к исполняемым файлам (shared executables). В оперативной памяти резервируется место под статические данные исполняемого процесса и оно является общим для каждого пользователя запустившего данный исполняемый файл. Область данных у каждого процесса — своя.
Требования к памяти у процессов OpenEdge зависит от количества пользователей и от параметров, задаваемых при запуске.
Параметры брокера
Для определения количества памяти, которое использует брокер БД необходимо добавить 10-15 процентов к параметру запуска «количество буферов БД» (-B). Если у вас таблица блокировки имеет большой размер ( задается параметром запуска –L) или велико количество индексных курсоров (задается параметром запуска -с), то оценка корректируется в сторону увеличения. На каждую запись в таблице блокировки тратится в среднем от 14 до 18 байт, а на один индексный курсор — 64 байта. К тому же, если у нас выделено очень малое количество буферов БД (меньше чем 2000), то перерасход памяти на другие параметры будет иметь совсем другую пропорцию относительно параметра -B. Он будет гораздо больше, чем 15 процентов.
К примеру, возьмём базу данных с размером блока 8K. Если установить значение -B равным 20000, то под буферный пул БД будет выделено 160000KB. Если мы добавим 10 процентов к этому значению, то получим 176000KB или 176MB. Примерно столько и будет потреблять памяти брокер БД.
Память сервера для удаленных клиентов оценить довольно просто — каждый сервер использует в среднем от 4 до 5MB. Количество серверов для удаленных клиентов ограничивается параметром –Mn (в оригинале стоит -Mm, что странно) Значение по умолчанию = 4.
Клиентские или пользовательские параметры.
Клиентские процессы всегда отличаются разнообразием и зависят от выбранных парметров запуска. Например, с настройками по умолчанию для -mmax и -Bt память выделяемая каждому новому процессу будет от 5 до 10 Мб. Такие значения справедливы и для серверов приложений. Удаленные пользователи используют, в основном, больше памяти (10-20мб на процесс) так как им нужны большие значения –mmax и –Bt для приемлимого уровня производительности. Требования удаленных клиентов к памяти никак не влияет на память сервера.
Планируем ОЗУ
Приведем пример сервера с 1Гб ОЗУ, 50 локальными пользователями и одной базой данных с размером блока в 8K. Значение -B возьмем равным 10000
- Память операционной системы:
- 28 MB ОС
- 100 MB выделено на буферную память БД
- память процессов OpenEdge
- 16 MB для исполняемых файлы
- 88 MB брокер базы данных (8KB * 10000 *1.1)
- от 250мб до 500мб для пользователей.
Итого занимаемая память – от 582 до 832 MB
Система при таких настройках может работать без заметного использования подкачки и позволит использовать память либо для других приложений либо для OpenEdge (после увеличения значений стартовых параметров брокера, например таких как –B). После того как брокер настроен наиболее эффективно можно подумать об увеличении клиентских параметров -mmax или –Bt.
В большинстве случаев на сервере запускаются и другие приложения. При расчетах необходимо учитывать и их требования.
Анализируем потребление ОЗУ
Ключ к эффективному использованию памяти — наблюдение за потреблением памяти в течении некоторого времени и прогнозирование потребностей. При длительном наблюдении (дни и недели) за системой необходимо отмечать пиковое потребление памяти. Как только пик найден — следует провести более детальное расследование его причин.
Можно написать свое приложение для мониторинга использования памяти или воспользоваться любым существующим. Главное быть уверенным — что для запускаемых задач сейчас и в будущем будет достаточно памяти. Существуют утилиты операционной системы, позволяющие видеть в реальном времени количество используемой памяти системы. Например, команда sar в Unix позволяет периодически собирать показатели утилизации памяти. В Windows этим занимается утилита Performance Monitor. Наряду с разнообразной информацией о производительности системы она позволяет посмотреть и использование памяти. Для запуска необходимо набрать perfmon в командной строке.
На основе только лишь количества доступной “свободной” памяти (free memory) сложно делать какие-либо выводы. Большинство операционных систем не освобождают занятую какими-либо процессами оперативную память до тех пор, пока есть еще какое-то пусть даже самое ничтожное количество свободной ОЗУ. И отсутствие свободной памяти не говорит нам ни о чем. Важно обратить внимание на другие показатели – reclaims (перемещения страниц), scan rate (частота сканирования страниц), physical page faulting (ситуация, когда запрашиваемая страница не в ОЗУ, а сброшена на диск) и swapping (использование подкачки). Реальное положение дел можно оценить только после анализа всех этих параметров.
Важно правильно анализировать пики при наблюдениях на экране. Если эти всплески короткие (меньше одной минуты) на них можно и не обращать внимания. Большинство утилит мониторинга работают с коротким периодом сбора показателей (от 5 до 10 секунд), так как на экран интереснее всего смотреть, если он активно меняется. Лучше всего увеличить интервал сбора статистики от 1 до 5 минут. Это даст более точную картину производительности.
На UNIX системах можно посмотреть на память процесса из команды process status — ps. Результат вызова не будет являться точным, так как в результат будет включена не только локальная, но и разделяемая (shared) память процесса. Это может привести к неверным выводам. Так что по показателю scan rate будет намного лучше понять — эффективно или нет мы используем память сервера.