ext4 отключить кэш диска

На нём расположены файлы БД, и кэш обеспечивается самой СУБД

use raw devices, Luke

1. В ФС нет кэша по сути, есть page cache данных с диска, он независим от FS.

2. Выставь vm.swappiness=0 и кеш ни при каких условиях не будет вызывать своппинг т.к. будет очищаться при первом требовании.

В общем проблема надуманная.

1. В ФС нет кэша по сути, есть page cache данных с диска, он независим от FS.

значит я неверно диагностировал причину своппинга, но для СУБД я выделяю буфер 32 гига (из семидесяти), что-то же «отжирает остальное...» может быть как раз page cache

2. Выставь vm.swappiness=0 и кеш ни при каких условиях не будет вызывать
своппинг т.к. будет очищаться при первом требовании

выставлял 1-ку, попробую 0

Спасибо!

Имеется ли возможность отключения кэширования для раздела с файловой системой ext4 ?

man chattr

...
When a directory with the `D' attribute set is modified, the changes are written synchronously on the disk;  this is equivalent to the `dirsync' mount option applied to a subset of the files.
...
When a file with the `S' attribute set is modified, the changes are written synchronously on the  disk;  this  is equivalent to the `sync' mount option applied to a subset of the files.

man mount

...........
 dirsync
              All directory updates within the file system should be done synchronously.   This  affects  the  following  system calls: creat, link, unlink, symlink, mkdir, rmdir, mknod and rename.
......
 sync
              All  I/O  to  the  file system should be done synchronously. In case of media with limited number of write   cycles (e.g. some flash drives) "sync" may cause life-cycle shortening.

Но, насколько я понимаю, это не отменяет кеш чтения, хотя при записи кеширования не будет.

сейчас стоИт RAID из четырёх дисков SSD.

И что?

База лежит на раиде ssd, операционка на раиде SAS. Оперативки 72 гига, размер базы 460 гигов, клиентских подключений 600. Для буфера СУБД выделяю половину от оперативки. Все прекрасно работает, пока не появляется своп (расположен на SAS). Предположил, что причиной свопа явился кэш файловой системы. Иными словами цель - определить что занимает оставшуюся оперативку и прекратить своппинг. Нууу, и совсем шикарно было бы использовать под буфер СУБД не половину оперативы, а бОльшую ее часть.

Отключи своп вообще, если он тебе мешает.

думал над этим, но не решился использовать, т.к. не знаю как себя поведет сервер

Отлично себе поведёт, это же не винда.

Предположил, что причиной свопа явился кэш файловой системы.

кэш в своп ???

тут http://www.sql.ru/forum/actualtopics.aspx?bid=7 неплохо отвечают по постгресу, только вопрос задай правильно, а не как ты сделал щас

Речь идёт о другой СУБД, не о postgress

ах блин, замылился глаз )

да, все сходу путают. «вещь спсфищиская»(С) :-)

я думаю postgres сам по себе умеет O_DIRECT, погугли

vm.swappinness позволяет предпочесть сохранение кэша свопанию других процессов, так что косвенно получается что да - кэш в своп :)

если говорить о собственном кэше субд, то да, он может попасть в своп (тут ТС следует курить маны по своей БД)
если говорить о кэше ФС, то он не должен попадать в своп никогда при работе ОС

Кэш - не попадает. Но когда некоему процессу понадобится память, ядро может решить засвопить какой-нибудь редко используемый процесс вместо того, чтобы сбросить часть кэша. За эту вероятность и отвечает параметр vm.swappiness

да, согласен

Отключил своп вообще. Буду наблюдать.

значит я неверно диагностировал причину своппинга, но для СУБД я выделяю буфер 32 гига (из семидесяти), что-то же «отжирает остальное...»

32 Гб на один процесс м.б. ? man ipcs

Но, насколько я понимаю, это не отменяет кеш чтения, хотя при записи кеширования не будет.

Так и есть. Но в случае ssd, я бы не советовал так делать :)

Отключил своп вообще. Буду наблюдать.

Зря. ООМ при аварии может прибить (и скорее всего прибьёт) ни какое-то глючное приложение(быдлопхпскрипт к примеру), а СУБД. И это будет видимо печально. Потому-как быдлоскрипт можно и ещё раз запустить, а СУБД придётся ручками подымать. А вот если у тебя sshd сдохнет... Ну ты понял...

Тебе уже подсказали, как сделать, чтоб кеш не свопился.

Но, насколько я понимаю, это не отменяет кеш чтения, хотя при записи кеширования не будет.

Так и есть. Но в случае ssd, я бы не советовал так делать :)

+1

32 гига под буфер СУБД, а не на один процесс.

отключение свопа на начальном этапе привело к увеличению производительности, но к сожалению потом - «OUT OF MEMORY» и остановка СУБД.

кэш записи не мешает. своп лезет при запуске отчетов, когда пользователи лезут в старые периоды накопленных данных.

отключение свопа на начальном этапе привело к увеличению производительности, но к сожалению потом - «OUT OF MEMORY» и остановка СУБД.

значит для этой задачи не хватает RAM.

Купи ещё, и сделай небольшой своп на случай аварии (в нормальных условиях там должно быть ~0 занятого, если своп растёт, это говорит об утечках в каком-то приложении).

«OUT OF MEMORY»

you do it wrong

в теч. рабочего дня он может увеличиваться до семи гигов, падая ночью до полутора. В качестве костыля можно ночью его совсем очищать swapoff -a && swapon -a , но все равно основные тормоза возникают в момент его роста, когда операционка активно сливает туда данные.

в теч. рабочего дня он может увеличиваться до семи гигов, падая ночью до полутора.

ну как-нибудь ограничь число клиентов и/или объём памяти для каждого. Что-бы больше RAM не требовалось.

Иначе никак. Использование свопа == тормоза. Это не значит, что своп нужно отключать.

попробую сменить тип файловой системы.