Деградация производительности ядра после апдейта 007->008

[Витька]

Обновили биллинг до 008 upd 4.
Параллельно была обновлена система CentOS 5 (32) -> CentOS 6 (64), добавлено памяти. Остальное железо то же самое.
Свежее ядро сильно подтупливает. Очень упала скорость поиска в админке, долго открываются окна редактирования пользователей и т.д.
Ядро течёт и падает по вечерам раз в два часа. Ночью, утром и днём реже.
Так и должно быть?

[starchik]

верификатор лог чистый?
была похожая проблема, дело было в таблице....точно уже не помню в какой

[duzer]

Витька симптомы очень похожи на проблему с базой данных. Расположена на том же сервере? Что в момент подвисаний `говорит` top?

[Витька]

Витька симптомы очень похожи на проблему с базой данных. Расположена на том же сервере? Что в момент подвисаний `говорит` top?

БД расположена там же, но в этом плане ничего не поменялось.
То есть раньше этот сервер выполнял все те же функции. В момент апгрейда было добавлено 16 гиг оперативы, стало 24. Больше из железа ничего не обновлялось.
Как такого момента подвисаний нету, потому что тупит оно постоянно. Память ядра с примерно постоянной скоростью растёт и ядро падает при достижении 4G.
Теоретически проблема может быть где угодно, потому что обновлено было много софта. Ядро 2.6.18 -> 2.6.32, мускул и т.д. Осталось понять, что именно косячит.

[duzer]

Дайте `top -Hd1`. Данные о трафике экспортируются в билинг по netflow или radius? Насколько быстро отдает данные mysqld (на каком-нибудь стандартном запросе) ? `tail -f debug.log` - чем в этот момент занято ядро?

[Витька]

В общем, проблема "как бы" решена, но её генезис до сих пор не установлен.
Решилось выставлением параметра innodb_flush_log_at_trx_commit = 2.
Сразу после этого ядро начало херачить запросы к базе с большой скоростью и минут через десять-пятнадцать высвободило память, с тех пор не течёт.
Судя по всему проблема на уровне ФС, хотя тут единственное изменение ext3 => ext4. Винты те же самые, на том же контроллере, внутри той же группы LVM. Мистика.