не должно, если найти баланс.
Судя по графику CPU usage очень большая часть usr трансформировалась в nice. Может быть стоит приоритет mysql уравнять с остальными программами обслуживающими сайт. Ведь mysql тоже формирует странички сайта.
ну попутал немного дебиан с центосом. и там и там тухляк.
в каких именно спецификациях и кто рекомендует проверку массива раз в месяц и почему именно раз в месяц?
Вообще, дебиану уже тыща лет, а о проверке задумались только в 2007 с выходом etch. В centos/rhel еще более затянули.
Как же оно раньше все работало ?
Мне совершенно очевидно, что политика дистрибутива задает мнение большинства его пользователей.
и где логика? размер индексов никак не характеризует частоту их использования.
перечитай еще раз мое сообщение.
вероятно, в этой конфигурации ОС считает индексы в памяти менее приоритетными чем остальное и вытесняет их в своп.
Уменьшить key_buffer_size придется, если хочется чтобы своп не использовался.---------- Добавлено 22.01.2012 в 17:27 ----------
зачем ВСЕМ ?
По задумке, nice и ionice нужно выставлять процессу бекапа и другим задачам, время выполнения которых не критично для нормальной работы сайта. До некоторой степени это даже помогает.
Dram, это характерно для нового дебиана.
до этого большинство пользователей raid даже не подозревало, что массив нужно проверять.
мало кто сможет аргументировать статистикой нормально (то есть является ли действительно стандартной практикой для подавляющего большинства raid-массивов) это или нет. я не берусь.
myhand, не вижу ни одного опровергающего суть мыслей утверждения. Может не надо меня цитировать?
Но ведь мешает.
Проблема в том, что иногда нельзя настроить нормально в вашем понимании, если ресурсы IO на пределе и любая дополнительная активность выводит сервер из равновесия. Хорошо иметь запас ресурсов для равновесия, но накладно.
Тут надо или памяти добавлять или дисков, но выгоднее ограничить скорость проверки и поставить выполняться эту проверку пореже. Что я и рекомендую.
если уж вам так важно чтобы в своп не лезло - уменьшайте key_buffer_size
скорее всего в нем много страниц, которые используются реже чем файлы, вот ОС и решает их вытеснить.
ну и vm.swapiness зачем же увеличивать было. назло Линусу? оставьте 0.
Тормозит у вас явно из-за какого-то периодического процесса типа ротации логов или бекапа. Может быть, если его исключить или убавить ему прыти, то будет полегче.
В принципе можно сделать такой бекап, который не будет портить буферы ОС. Но вам дешевле будет памяти добавить.
так я этого и не утверждал.
но, возможно, numa включается на этой материнке начиная с какого-то объема памяти.
иногда у меня впечатление что за него на форуме и так уже копирайтер-универсал пишет.
Zaqwr, так я ж просил весь dmesg. Больше информации - больше шансов догадаться откуда ноги растут.
Пока видно только что NUMA активировалась. Совершенно не понятно зачем. 12Гб не так уж и много. Полно серверов которые без NUMA, на двух процессорах и видят и больший объем.
(правда i7 двухпроцессорные мне негде посмотреть)
Поставь дебиан, вдруг заработает.
