Назад | Перейти на главную страницу

Oracle 10g на RHEL - вся память съедается каждую ночь в 20.15

Хорошо, для начала, я новичок в Oracle DB. Большой опыт работы с продуктами Microsoft (boo) и Ubuntu linux, но RHEL и Oracle для меня совсем новые.

Среда ... Oracle DB 10g Standard v10.2.0.1.0 - 64-разрядная версия, на RedHat Enterprise Linux 5. Общий размер базы данных менее 8 ГБ.

Проблема ... Каждую ночь в 20.15 на точка, память сервера упадет до НУЛЯ. Раньше у нас на сервере было 4 ГБ ОЗУ, поэтому наша статистика памяти всегда показывала ~ 100 МБ. До недавнего времени мы не знали, что существует проблема, помимо недостаточного объема оперативной памяти. На днях мы обновили 4 ГБ до 12 ГБ и увидели, что доступна легальная память. Пожалуйста, обратитесь к приложенным изображениям для получения подробной информации.

Ежедневное использование памяти : На этом графике показан период в 24 часа, где с начала до 20.15 показано использование памяти в течение дня (когда пользователи сильно загружают сервер). В 20.15, после того как все пользователи ушли из здания более чем на 2 часа, память практически исчезла, пока сервер не будет перезагружен.

Еженедельное использование памяти : На этом графике показан период времени до обновления памяти и три дня с момента обновления. Как видите, перед обновлением практически нет доступной физической оперативной памяти, хотя для кеширования используется память. После обновления у нас есть огромный кусок доступной оперативной памяти и кеша - до 20.15, когда оба исчезнут. Каждый раз, когда вы видите скачок объема ОЗУ, происходит сразу после перезагрузки. Этой доступной оперативной памяти хватит, как вы уже догадались, до 20.15.

Поставщик, который построил этот сервер, абсолютно нет ответь за нас. На самом деле то, что они говорят нам, абсолютно смешно и заставляет их выглядеть в высшей степени неспособными. Они действительно ни о чем не догадываются, и это очевидно. Так что мы никак не сможем получить ответ таким образом. Около недели назад мы были уверен что серверу не нужно больше ОЗУ и у него более чем достаточно ресурсов. Он также был построен всего с двумя физическими жесткими дисками (2x146 ГБ, 15K об / мин), я думаю, настроен как RAID1.

Я проверил (как мне кажется) все задания планировщика, все задания cron и любые другие задания / задания, которые я могу найти. Я отключил все незанятые сеансы базы данных безрезультатно. Единственное свидетельство, которое я могу найти, указывающее на виновника, - это процесс Oracle, который начинает занимать ~ 50% ЦП после 20.15. В течение дня существует несколько десятков (~ 40+) процессов Oracle, каждый из которых показывает использование виртуальной машины объемом около 2,2 ГБ - это верно и сразу после перезагрузки, а также после «события» 20,15.

Я в тупике. А наш поставщик программного и аппаратного обеспечения ничего не стоит.

Любые предложения или помощь будут сильно оценил! Спасибо! ~ Лаз Петерсон

Сделайте два снимка Statspack, 20:00 и 00:00. Создайте отчет между ними. Он скажет вам, что вызывает высокую нагрузку. Особенно обратите внимание на «5 самых популярных событий по времени», а затем на запросы SQL, вызывающие рассматриваемое некорректное поведение. Кроме того, ознакомьтесь с дополнительными предложениями в разделе Oracle Memory "Advisories".

Основываясь на доступных в настоящее время подробностях, я считаю, что потребление памяти само по себе не является проблемой. Что-то потребляющие нагрузку транзакции начинаются в 20:15, что приводит к извлечению буферизованных данных из свопа.

Взгляните на рекомендации Red Hat для Oracle в http://www.redhat.com/f/pdf/rhel/Oracle-10-g-recommendations-v1_2.pdf. В частности, установите для параметра swappiness значение 0 (или близкое) и используйте Huge Pages.

Во-первых, то, что люди Oracle говорят, не является «нелепым ответом», просто Oracle выполняет некоторые служебные задачи в то время, вероятно, через cron. Если это время неудобно, спросите, как их перенести.

Графики использования памяти выглядят нормально. Когда Linux загружает данные в память, они остаются там до тех пор, пока пространство не понадобится для чего-то еще (вот что free(1) отчеты как кеш / буферы). Логика заключается в том, что его удаление - явная работа; если данные понадобятся снова, они доступны бесплатно. Там действительно бесплатно 2GiB. Если это не изменится (то есть где-то утечка памяти), я бы не беспокоился сейчас.