Имя пользователя:
Пароль:  
Помощь | Регистрация | Забыли пароль?  

Показать сообщение отдельно

Новый участник


Сообщения: 28
Благодарности: 2

Профиль | Отправить PM | Цитировать


Цитата shisik:
а почему бы просто не вырубить swap? И проблемы не будет »
С Windows я в таком режиме уже 15 лет работаю, и вырубаю файл подкачки на всех подконтрольных мне машинах - домашних/личных, рабочих станциях, и даже на некоторых серверах на работе (там, где я хорошо знаю работающий софт и уверен, что он не вылетит за границы имеющегося ОЗУ). Но в мире Linux я новичок, а в "чужой монастырь со своим уставом не ходят". Раз положено своп - я его сделал. К тому же наличие свопа на машине - одно из предваритварительных требований установки Oracle Database. Хотя я полагаю, что база, в принципе, хоть и требует наличия свопа, при достаточном объеме ОЗУ будет нормально работать. Но, в целом, я пока из-за недостаточности опыта администрирования Linux и Oracle Database боюсь отказываться от свопа в этой ОС.

Но знаете... В принципе я думаю что своп тут не причем - у меня вопрос об ограничении выделяемого ОС объема памяти под buff/cache, проходящего по строке Mem. А это ведь исключительно ОЗУ? Ну отключу я своп. А это приведет к тому, что Linux по строке Mem прекратит выделять такие гигантские объемы памяти? И станет ли он выделять память в том объеме, как я хочу, а не как он решит?

Цитата Busla:
AFAIK он не файловый, а страничный »
Да, насколько я понял из документации на Oracle Database, у базы данных свои механизмы работы с памятью и диском. В моем случае я имею на сервере 8 Гб ОЗУ, из которых 6 хочу отдать под базу данных. Эти отданные базе 6 Гб я хочу поделить на 3/4 под SGA и 1/4 под PGA. База будет 12cR2, там полного автомата управления памятью как в 12cR1 нет, и придется делать так. На уровне ОС я HugePages сконфигурировал под 6 Гб, потом на уровне базы задал SGA auto memory management SGA_TARGET=4608M, для PGA тоже включил PGA auto memory management и выделил под нее PGA_AGGREGATE_TARGET=1536M. Тут вроде бы все под контролем, да и не о конфигурировании базы речь в этой теме . Но когда я вижу, как на уровне ОС в таких широких пределах болтается Mem buff/cache, загоняя всю систему в своп - это удивляет, раздражает, и хочется наложить ограничения на такое поведение. И я ОС прекрасно понимаю - куда же ей деваться, если со стороны базы все жестко, и память там отобрать для текущих потребностей ОС взять нельзя. Из 8 Гб под ОС осталось 2, и если она выделила под buff/cache 1 Гб ОЗУ, а ей для запуска приложений нужно 1,5 Гб, то конечно она на 0,5 Гб уйдет в своп!

А, блин . Только сейчас понял, что вы имели ввиду . А что такое тогда страничный кэш?! Для чего он? Память, насколько я понял из документации на Linux, там всегда делится на страницы - 4 Кб стандартные и 2 Мб для режима HugePages. Нет, вроде как память buff/cache - это файловый кэш. По крайней мере, я так понял эту статью с RedHat, поскольку Oracle Linux - это Red Hat с переклеенной наклейкой . Вот там даются такие слова:
"...most of the memory use is for buffers and cache. Linux always tries to use RAM to speed up disk operations by using available memory for buffers (file system metadata) and cache (pages with actual contents of files or block devices). This helps the system to run faster because disk information is already in memory which saves I/O operations. If space is needed by programs or applications like Oracle, then Linux will free up the buffers and cache to yield memory for the applications..." Вот у меня, похоже, это и происходит - перевыделив памяти под файловый кэш, Linux вынуждена его сливать на диск, уходя в своп (наверное, все же не в своп, а в дисковый ввод-вывод), для того, чтобы освбодить память для запуска приложений.

Последний раз редактировалось GrayMagellan, 16-12-2018 в 10:05.


Отправлено: 09:49, 16-12-2018 | #5