Как ограничить объем памяти, используемый Linux под buff/cache память?
Всем привет! Очень мне не нравится, что в Линукс так свободно (как гно в проруби) болтается память, выделяемая под кэширование файловых операций ввода-вывода. У меня все жестко в системе - в ящике столько-то ОЗУ, из него столько-то памяти выделено под базу данных (Оракл), и все было бы хорошо, если бы не прыгающий туда-сюда buff/cache!!! То он 100 Мб, то 900 Мб, то опять 600. Из-за этого я не могу выделить памяти базе больше. Ибо если я пытаюсь это сделать, косвенно требуя от Линукс передать память от файловых буферов базе данных, то кажется мне, что это не срабатывает, и buff/cache начинает дико свопить, сливая накопленные в файловом кэше данные на диск, и упорно считая, что под buff/cache должно выделяться от 0 до 1 Гб ОЗУ. А если это не получается разместить в ОЗУ, то оно прет в своп. Я бы хотел в ОС память жестко под buff/cache выделить (скажем, 50 Мб), а освободившуюся память отдать базе. У Оракла свои механизмы работы с кэшем базы данных, и buff/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." я уже читал. Не всем и не всегда такая политика подходит. В ситуации, когда ты вручную конфигурируешь память туда, сюда и вооон туда, неподдающийся управлению компонент в виде самовольно растущей или сжимающейся buff/cache памяти очень сильно раздражает и сковывает. |
Вот реальный пример:
[oracle@.!.]$ free -m total | used | free | shared | buff/cache | available Mem: 7710 | 7436 | 51 | 26 | 222 | 92 Swap: 8063 | 60 | 8003 [oracle@.!.]$ Спрашивается, какого рожна система выделила под файловый кэш 222 Мб ОЗУ, и при этом в своп улетела на 60!!! Гораздо логичнее было бы не выделять так много ОЗУ под файловый кэш, и тогда бы не пришлось залезать в своп. |
GrayMagellan, а почему бы просто не вырубить swap? И проблемы не будет. Линукс под кеш не выделит памяти больше, чем есть свободно. А будет там гипотетически полезный дисковый кеш или просто абра-кадабра от ошмётков данных - кого это волнует?
|
Цитата:
Цитата:
Кэш - это буфер, который не сразу освобождается. Чтобы что-то (oracle в том числе) могло работать с данными на диске, они должны лежать в кэше. |
Цитата:
Но знаете... В принципе я думаю что своп тут не причем - у меня вопрос об ограничении выделяемого ОС объема памяти под buff/cache, проходящего по строке Mem. А это ведь исключительно ОЗУ? Ну отключу я своп. А это приведет к тому, что Linux по строке Mem прекратит выделять такие гигантские объемы памяти? И станет ли он выделять память в том объеме, как я хочу, а не как он решит? Цитата:
А, блин :). Только сейчас понял, что вы имели ввиду :). А что такое тогда страничный кэш?! Для чего он? Память, насколько я понял из документации на 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, можете считать меня хамом, но "Смотрю в книгу - вижу фигу":
Цитата:
|
Цитата:
Ни в коем случае! Я вам искренне благодарен. Я пришел сюда за знаниями, и буду благодарен любому, кто возьмет меня за шиворот и ткнет носом в знания :). Так что спасибо вам. Я прочитал следующую главу. Но мне непонятны следующие слова - "...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/ нету :(. Отменили его в последних версиях Линукса? |
Цитата:
Цитата:
Цитата:
Если вам так уж хочется поучить систему (это иногда действительно нужно бывает в определённых ситуациях, но я не знаток 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.*, почитать про каждую по отдельности, покрутить, только осторожно, постепенно и при каждом изменении проводить тесты производительности и стабильности. В линуксе выстрелить себе в ногу кручением параметров ядра оч просто. |
Цитата:
Цитата:
С моделями памяти Linux в целом и в применении к Ораклу у меня после прочтения кучи литературы и интернета в голове уже полный хаос настал. Я уж и оракловый форум по Оракл Линукс помучал, и тех. поддержку ихнюю - нигде понятной для меня информации не получил :(. Но это в текущем контексте оффтоп. |
Цитата:
Код:
vm.hugepages_treat_as_movable = 0 Цитата:
Например, если у вас мало памяти и быстрое IO – то скручивать в минимум vm.dirty полезно, если наоборот – то лучше увеличить, при этом принимая во внимание, что сбой может повлечь потерю данных. Да, всё непросто. |
Цитата:
Цитата:
|
Цитата:
|
Цитата:
Linux-x86_64 Error: 1: Operation not permitted" :). Цитата:
|
Цитата:
|
Цитата:
Цитата:
"...The term "swappiness" refers to the likeliness of the system to use swap. This works on a scale of 0-100 where zero means indicates the swap will never be used and 100 is excessive use. Most Linux distros have a default of about "60"...". Хотя наверное этот параметр не совсем то, что мне нужно. Во-первых, я не хочу ограничивать своп, т.к. я и так ограничиваю систему по ОЗУ. Если я ограничу систему по свопу, то у нее не останется пространства для маневра памятью и она должна просто рухнуть. Во-вторых, это согласно перевода "желание" использовать операционкой своп. А мне не своп, а страничный кэш ограничить надо. |
Цитата:
|
Вложений: 1
Все-таки я пока хочу решить частную задачу - ограничить страничный кэш объемом 50 Мб. Все, что в него не поместится - пусть через дисковый ввод-вывод проходит.
|
How to control the size of page cache in RHEL
How to control the size of page cache in RHEL? Solution Проверено - Обновлено March 15 2018 at 9:32 PM - English Окружение Red Hat Enterprise Linux 7 Red Hat Enterprise Linux 6 Red Hat Enterprise Linux 5 Red Hat Enterprise Linux 4 Вопрос How to control the size of the page cache in Red Hat Enterprise Linux? Решение In RHEL 4, 5, 6 and 7 the page cache is dynamically adjusted. There is no kernel parameter to control its size directly. However, it is possible to indirectly influence the page cache size via tuning of the virtual memory settings. The primary sysctl tunables (along with their default values) for controlling the behaviour of the page cache are as follows: vm.vfs_cache_pressure (default = 100) At the default value of vfs_cache_pressure=100 the kernel will attempt to reclaim dentries and inodes at a "fair" rate with respect to pagecache and swapcache reclaim. Controls the tendency of the kernel to reclaim the memory which is used for caching of directory and inode objects. Decreasing vfs_cache_pressure causes the kernel to prefer to retain dentry and inode caches. Increasing vfs_cache_pressure beyond 100 causes the kernel to prefer to reclaim dentries and inodes To limit the size of page cache, you would want to increase this value so the kernel will be more likely to reclaim these objects. vm.dirty_background_ratio (default = 10) Contains, as a percentage of total system memory, the number of pages at which the pdflush background writeback daemon will start writing out dirty data. To limit the size of page cache, decrease this number so the pdflush daemon will start writing out dirty data sooner. vm.dirty_ratio (default = 20) Contains (as a percentage of total system memory) the number of pages at which a process which is generating disk writes will itself start writing out dirty data. To limit the size of page cache, decrease this number so processes will start writing out dirty data sooner. vm.dirty_writeback_centisecs (Red Hat Enterprise Linux 4 & 5: default = 499, Red Hat Enterprise Linux 6 and 7: default = 500) The pdflush writeback daemons will periodically wake up and write "old" data out to disk. This tunable expresses the interval between those wakeups, in 100'ths of a second. Setting this to zero disables periodic writeback altogether. To limit the size of page cache, decrease this value so the pdflush daemon will wake up more often and write dirty data out to disk. vm.dirty_expire_centisecs (Red Hat Enterprise Linux 4 and 5: default = 2999, Red Hat Enterprise Linux 6 and 7: default = 3000) This tunable is used to define when dirty data is old enough to be eligible for writeout by the pdflush daemons. It is expressed in 100ths of a second. Data which has been dirty in-memory for longer than this interval will be written out next time a pdflush daemon wakes up. To limit the size of page cache, decrease this value so data will be considered dirty sooner and will be written out by pdflush. vm.swappiness (RHEL 5 and 6:default = 60, RHEL 7:default = 30) This controls how likely the vm is to swap out inactive memory pages (the higher the value, the more likely it is to swap). To limit the size of page cache, decrease this value so the kernel is less likely to swap and thus more likely to drop pages from the page cache. A value of zero here does not prevent the system from swapping. You do not need to reboot for sysctl changes to take effect. Modifications to these values could effect a significant change in behavior and performance of the system (positive or negative). It is highly recommended that you modify them slightly at first and test each change thoroughly to ensure they do not have any negative effects in your environment. For further details please check the following documents that are contained in the kernel-doc package: /usr/share/doc/kernel-doc-$VERSION/Documentation/{filesystems/proc.txt, sysctl/vm.txt}. Цитата:
Скрытый текст
# sysctl settings are defined through files in # /usr/lib/sysctl.d/, /run/sysctl.d/, and /etc/sysctl.d/. # # Vendors settings live in /usr/lib/sysctl.d/. # To override a whole file, create a new file with the same in # /etc/sysctl.d/ and put new settings there. To override # only specific settings, add a file with a lexically later # name in /etc/sysctl.d/ and put new settings there. # # For more information, see sysctl.conf(5) and sysctl.d(5). Цитата:
|
Цитата:
Цитата:
Цитата:
А не наступил ли у меня пипец? AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 3268 HugePages_Free: 3097 HugePages_Rsvd: 2286 HugePages_Surp: 0 Hugepagesize: 2048 kB Если я сложу Free+Rsvd, то получится 5383 страницы. Что явно больше заданного мной 3268 шт. Гм... Пока писал, показания стали такие: AnonHugePages: 0 kB ShmemHugePages: 0 kB HugePages_Total: 3268 HugePages_Free: 816 HugePages_Rsvd: 5 HugePages_Surp: 0 Hugepagesize: 2048 kB Вот последние цифры уже похожи на правду. Я планировал под SGA отдать 4902 Мб. Если посчитать, то получается близкая величина: (3268шт.-816шт.)*2Мб=4094Мб. Гм... Ровно на 2 Мб больше, чем я планировал. Где у меня косяк вкрался? И меня смущает, что 816 страниц болтаются во Free. За счет чего же тогда PGA взяла память?! Должна была за счет этих 816 страниц взять. |
В общем... Я не стал разбивать себе голову (вернее, у меня не получилось), пытаясь косвенными параметрами ограничить объем страничного кэша. Вместо этого я пошел по другому пути и базу настроил по-другому. Вроде работает... Пока, по крайней мере... Пока база пустая. Дальше буду восстанавливать схемы и пробовать её в работе. Всем откликнувшимся спасибо за советы!
|
Время: 06:02. |
Время: 06:02.
© OSzone.net 2001-