Как с кешем побороться?
olegon 19 Августа, 2008 - 09:57
И все таки, в серваке 6Гб памяти, 4 я отвел под БД, как уговорить, что не надо 4Гб кеша делать? Он на 4Гб наливает кеша (по htop), после чего база при бекапе кричит "could'nt allocate memory"...
vm.vfs_cache_pressure=100000 поставил, вроде бы прошел бекап... Все ли сделал?
»
- Для комментирования войдите или зарегистрируйтесь
.
Я в не курсе подробностей, но я предполагал, что кеш в нужные моменты времени уменьшается, освобождая память. Ведь иначе не было бы возможности запустить ни одного нового процесса - вся память уже занята. Хотелось бы разобраться... ссылки приму с благодарностью.
Вообще странно... Что же это такое творится, если нужно вручную кэшем управлять. Ужос.
По всей
По всей видимости имеется ввиду дисковый кеш, а он должен "умно" сбрасываться по первому требованию о выделении памяти.
Хотя в теории, из-за использования какой-то необычной процедуры выделения памяти приложением (либо некорретной проверки доступной памяти), может возникнуть подобная ошибка.
Попробуй выполнить:
echo 1 > /proc/sys/vm/drop_cachesкогда памяти будет якобы нехватать и отпишись, что получилось.
проблема в том,
проблема в том, что меня может не быть, когда это случится и вообще то, что ты предлагаешь просто выкидывает кеш, не интересуясь, сделал ли я sync, хочу разобраться... Пока не смог. То, что сделал выше привело к периодическому подвисанию системы в целом... За счет чего - не понял. А на занимаемый кешем объем памяти практически не повлияло :( Но и бекап не падал...
Я не предлагаю
Я не предлагаю это как решение, это только лишь способ проверки, в кеше ли дело.
Если по "echo 1 > /proc/sys/vm/drop_caches" картина не меняется, то есть подозрение, что кеш тут не причём. Возможно что-то другое сильно хавает память.
Я бы рад
Я бы рад проверить, но база рабочая и сбросить кеш без sync - самоубийство :)
чесно говоря
чесно говоря вот этого я не понял. это на 99% кэш для чтения, да и если и на запись - какой идиот его просто выкидывать будет? он просто принудельно сбрасывается этой командой. помоему кэши записи ФС это тема отдельная, и у каждой ФС своя политика их сброса.
А почему на
А почему на каждом углу пишут, что надо sync делать?
"Writing to this will cause the kernel to drop clean caches, dentries and inodes from memory, causing that memory to become free.
To free pagecache:
* echo 1 > /proc/sys/vm/drop_caches
To free dentries and inodes:
* echo 2 > /proc/sys/vm/drop_caches
To free pagecache, dentries and inodes:
* echo 3 > /proc/sys/vm/drop_caches
As this is a non-destructive operation, and dirty objects are not freeable, the user should run "sync" first in order to make sure all cached objects are freed."
Гуру, выручайте :( Сегодня опять бекап свалился "Linux-x86_64 Error: 12: Cannot allocate memory"
oracle@kk ~ $ free
total used free shared buffers cached
Mem: 6124124 6081548 42576 0 34152 5408192
-/+ buffers/cache: 639204 5484920
Swap: 1823368 244940 1578428
вилы. тут
вилы. тут написано что "так как это неразрушающаяя операция, чтобы очистить весь кэш нужно сделать sync" как я понимаю он кэш записи просто нетрогает.
Это, наверное,
Это, наверное, не самый удачный пример. Было где-то более однозначное. Что содержимое просто выкидывается. Впрочем, может, это все отсюда же... А у меня рабочая база, куча народу работает...
я не понимаю, ты
я не понимаю, ты и правда вериш что какойто невменяемый програмист будет делать функцию которая будет тупо выбрасывать кэш на запись? это легко убьёт ФС, по крайней мере данные потеряются. где ты этот бред вообще вычитал??? эта команда сбрасывает кэши - ничего опасного тут нет впринципе. Хотя помоему спорить безполезно...
А точно ли из-за
А точно ли из-за кэша это? А что за СУБД? Она чтоли пытается себя замкнуть в оперативной памяти и запретить её свопить (это умеют делать oracle (по умолчанию) и mysql (при определенной настройке), может кто-то еще)?
Просто в теории кэши вообще не должны мешать приложениям, в основном это кэши на чтение, которые ОС может моментально выкидывать, не производя обмен с внешними носителями.
Да, это Oracle. Вот
Да, это Oracle. Вот тут я готов спорить :) Она по умолчанию не пытается себя замкнуть в оперативке. Я пробовал и замыкать и прочее - не помогает. Пытаюсь воевать с операционкой, потому, что в ней корень, явно. И про теорию понятно, тем не менее на практике - сваливается... Причем pressure помогает, просто сказывается на остальных процессах. Пока уменьшил значение до 1000, бекап сегодня прошел, прослежу за юзерами...