Использование VM

Прикрепил my.cnf.

Ну по идеи да, но почему в нужный момент оно не очищает часть кеша, а свопит.. проблема именно в этом.

ok.Совсем по делу ничего сказать не могу, но давайте попробуем. PHP у вас не как fcgi случаем?

Перезапустите MySQL и если кеш не освободится - апач (nginx) у сервера. Так же предлагаю поставить htop - им удобнее наблюдать за сими процессами.

Это из разряда танцев с бубном, но покажет, кто именно использует кеш, т.к. при перезапуске сервисов помимо освобождения used RAM еще освободятся и кеш и буферы.

если уж вам так важно чтобы в своп не лезло - уменьшайте key_buffer_size

скорее всего в нем много страниц, которые используются реже чем файлы, вот ОС и решает их вытеснить.

ну и vm.swapiness зачем же увеличивать было. назло Линусу? оставьте 0.

Тормозит у вас явно из-за какого-то периодического процесса типа ротации логов или бекапа. Может быть, если его исключить или убавить ему прыти, то будет полегче.

В принципе можно сделать такой бекап, который не будет портить буферы ОС. Но вам дешевле будет памяти добавить.

Raistlin, стоит php cli. Тут на графике виден как раз перезапуск mysql + перезапуск httpd и nginx. Естественно резко уменьшилась память под приложения (мускул до этого весил 7ГБ в памяти, сейчас 6ГБ и потихоньку растет), но кеш системы все равно не сбрасывается.

htop стоит, ну сколько не смотрел - никогда ничего криминального не было. Единственное, как поставил eaccelerator, munin пишет apache ram usage 10-25ГБ, ну этого просто быть не может - совершенно не совпадает с показателями использования памяти, та и тогда в свопе было б очень много всего.

netwind, vm.swapiness поставил в 0. Уменьшать key_buffer_size наверное не стоит, т.к. там 5,5ГБ индексов. Каждую ночь сливаются базы данных + раз в неделю делается полный бекап, ротация логов нагружать не может (у большинства логов стоит симлинк на /dev/null). Но в своп уходит и без бекапов - по первому графику, начало уходить в своп в 7-8утра, а бекап баз длился с 1:30 до 1:57.

По поводу убавления прыти - стоит spri, который выставляет всем процессам nice и ionice. Памяти добавить нельзя - это максимум.

и где логика? размер индексов никак не характеризует частоту их использования.

перечитай еще раз мое сообщение.

вероятно, в этой конфигурации ОС считает индексы в памяти менее приоритетными чем остальное и вытесняет их в своп.

Уменьшить key_buffer_size придется, если хочется чтобы своп не использовался.

---------- Добавлено 22.01.2012 в 17:27 ----------

зачем ВСЕМ ?

По задумке, nice и ionice нужно выставлять процессу бекапа и другим задачам, время выполнения которых не критично для нормальной работы сайта. До некоторой степени это даже помогает.

Тут сразу не понял. Ну а если уменьшить, не получится ли так, что индексы малонагруженных баз попадут в кеш, а индексы нагруженных баз - останутся вообще без кеша?

Ну не для всех, но он делается и для httpd, nginx, mysql (так в статье вычитал, та и в начальных конфигах spri также - апач имеет высокий приоритет, мускул - средний). Для cp, rm, tar, gzip, rsync и ряда других nice 19 и ionice 7, для httpd и nginx - 2 и 1, для mysql - 7 и 4.

---------- Добавлено 22.01.2012 в 16:34 ----------

Сейчас вообще отключил своп, вроде памяти всем хватает. Вообще способ наверное варварский, но вроде все нормально. Сейчас и бекап идет, но работает как должно - когда остается свободной памяти меньше 200МБ, сгружает часть кеша и свободной становится около 500МБ.

не должно, если найти баланс.

Судя по графику CPU usage очень большая часть usr трансформировалась в nice. Может быть стоит приоритет mysql уравнять с остальными программами обслуживающими сайт. Ведь mysql тоже формирует странички сайта.

Ясно, ну как бекап закончится - тогда попробую поиграться с настройками, т.к. iowait сейчас итак большой, а рестарт мускула точно добьет.

Поставил нгинкс, апач и мускул в высокоприоритетные приложения, график не меняется - юзер 20%, найс 180%. Правда в стандарте у spri кронзадание раз в 45минут (если не ошибаюсь), я поставил раз в 2 минуты - но не думаю, что это важно - т.к. он все равно просто чекает все процессы и почти всегда old и new priority равны. А вот когда бекапинг начинает делаться 45 минут слишком большой отрезок времени.

И что вы хотите? Это его кеш. Видимо, вы апач не ребутаете, а релоадите... Иначе кеш должен был быть очищен, т.к. модуль выгружается. Правьте настройки и будет вам счастье.

Кеш eaccelerator идет на tmpfs /var/tmp и там же mysql-slow.log и выделено всего 6ГБ, из которых используется не более 30%. По идеи, эти данные занимать более 2ГБ в озу просто не могут.

По поводу рестарта апача, 16ГБ cached до рестарта и 14,5ГБ после, команда service httpd restart.