[GrayMagellan]

Вот реальный пример:

[oracle@.!.]$ free -m
total | used | free | shared | buff/cache | available
Mem: 7710 | 7436 | 51 | 26 | 222 | 92
Swap: 8063 | 60 | 8003
[oracle@.!.]$

Спрашивается, какого рожна система выделила под файловый кэш 222 Мб ОЗУ, и при этом в своп улетела на 60!!! Гораздо логичнее было бы не выделять так много ОЗУ под файловый кэш, и тогда бы не пришлось залезать в своп.

[shisik]

GrayMagellan, а почему бы просто не вырубить swap? И проблемы не будет. Линукс под кеш не выделит памяти больше, чем есть свободно. А будет там гипотетически полезный дисковый кеш или просто абра-кадабра от ошмётков данных - кого это волнует?

[Busla]

У Оракла свои механизмы работы с кэшем базы данных, и buff/cache не кэширует потоки из кэша базы к/от файлам базы. »

какого рожна система выделила под файловый кэш 222 Мб ОЗУ »

AFAIK он не файловый, а страничный.
Кэш - это буфер, который не сразу освобождается. Чтобы что-то (oracle в том числе) могло работать с данными на диске, они должны лежать в кэше.

[GrayMagellan]

а почему бы просто не вырубить swap? И проблемы не будет »

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

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

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 вынуждена его сливать на диск, уходя в своп (наверное, все же не в своп, а в дисковый ввод-вывод), для того, чтобы освбодить память для запуска приложений.

[Busla]

GrayMagellan, можете считать меня хамом, но "Смотрю в книгу - вижу фигу":

cache (pages with actual contents of files or block devices »

так что кэш страничный, и следующей же главой по вашей ссылке идёт howto как им управлять

[GrayMagellan]

можете считать меня хамом »

Ни в коем случае! Я вам искренне благодарен. Я пришел сюда за знаниями, и буду благодарен любому, кто возьмет меня за шиворот и ткнет носом в знания . Так что спасибо вам. Я прочитал следующую главу. Но мне непонятны следующие слова - "...To control the percentage of total memory used for page cache in Red Hat Enterprise Linux 5, change the pagecache kernel parameter...". А процент от чего контролирует этот параметр? По умолчанию 100% ("...default value of 100..."), и если следовать статье, то получается все 100% моего ОЗУ должны по умолчанию пойти под страничный кэш? Как это? Только... Я сейчас пытался посмотреть действующее значение этого параметра, и выяснилось, что у меня в Oracle Linux 7.6 (он же Red Hat 7.6) такого параметра в /proc/sys/vm/ нету . Отменили его в последних версиях Линукса?

[Jula0071]

Из-за этого я не могу выделить памяти базе больше. »

Можете. Расценивайте buff/cache как свободную.

Но в мире Linux я новичок, а в "чужой монастырь со своим уставом не ходят". »

И сразу начинаете учить систему, как ей работать.

Отменили его в последних версиях Линукса? »

5-й RHEL вышел d 2007, много воды с тех пор утекло.

Если вам так уж хочется поучить систему (это иногда действительно нужно бывает в определённых ситуациях, но я не знаток Oracle и прямых рекомендаций дать не могу. разве что имхо памяти для большой БД, для чего обычно используют его, как-то уж очень мало), то можете покрутить эти гайки:
vm.swappiness – от 0 до 100, по умолчанию 60, чем выше число, тем охотнее система лезет в свап. Совсем свап выключать нельзя – чревато OOM киллами.
vm.vfs_cache_pressure – от 0 до не знаю какой величины, по умолчанию 100. Этот параметр отвечает, с какой скоростью освобождается кэш файлов/директорий. Чем больше число, тем чаще. Скажем при 1000 вместо 100 - в 10 раз чаще.
vm.dirty_background_ratio/vm.dirty_ratio - от 0 до 100, чем меньше, тем быстрее страничный кэш сбрасывается на диск.
Можете посмотреть все гайки vm.*, почитать про каждую по отдельности, покрутить, только осторожно, постепенно и при каждом изменении проводить тесты производительности и стабильности. В линуксе выстрелить себе в ногу кручением параметров ядра оч просто.

[GrayMagellan]

И сразу начинаете учить систему, как ей работать »

Не я учу. Документация по установке и настройке базы данных Оракл 12cR2 учит. Я 12cR1 ставлю уже на автомате, и с настройкой большой памяти там нет проблем - на слое ОС создал запись в fstab под shared memory tmpfs, на слое базы выделил память (общую, а дальше база сама делит внутри этого пула её между SGA и PGA), и все пучком. Но в 12cR2 Оракл решил отказаться от Shared Memory при необходимости выделить базе много памяти, и теперь требуется настройка только под HugePages. Это оказалось труднее понять и настроить, чем в случае с Shared Memory.

памяти для большой БД, для чего обычно используют его, как-то уж очень мало »

Так это тестовая виртуалка - захочу, и после очередного ребута на ней окажется 64 Гб ОЗУ . На уровне железа выделить X или Y ОЗУ в наше время - не проблема. Сложнее оказалось с настройкой этой памяти под софт (Oracle Database). Пока на тестовой виртуалке я использую 8 Гб ОЗУ. Для составления алгоритма выделения памяти больше, чем стандартные для Оракл Датабэйз 4 Гб ОЗУ этого количества вполне хватает. А дальше, вы сами понимаете, я в созданной инструкции только одни цифры на другие подменять буду, и всё.

С моделями памяти Linux в целом и в применении к Ораклу у меня после прочтения кучи литературы и интернета в голове уже полный хаос настал. Я уж и оракловый форум по Оракл Линукс помучал, и тех. поддержку ихнюю - нигде понятной для меня информации не получил . Но это в текущем контексте оффтоп.

[Jula0071]

требуется настройка только под HugePages »

Про это почитайте и покрутите при надобности.

Код:

vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0

Так это тестовая виртуалка - захочу, и после очередного ребута на ней окажется 64 Гб ОЗУ »

Так значит она и не отражает даже приблизительно поведения прода. Поведение кэша ооочень сильно меняется от размера доступной и реально занятой памяти, а не напугавшего вас кэша. Также латентность IO влияет очень сильно. На SSD одни настройки, на HDD другие, на iSCSI третьи, да ещё смотря по какому каналу оно ходит.
Например, если у вас мало памяти и быстрое IO – то скручивать в минимум vm.dirty полезно, если наоборот – то лучше увеличить, при этом принимая во внимание, что сбой может повлечь потерю данных. Да, всё непросто.