Нужен коллективный разум - высокая нагрузка

Потому что бросьте эту политику "но на старом же работало". Это сильно губит 90% заказчиков.

cat /proc/mdstat

если погасить все активные процессы сервера LA сервера быстро падает ? С какой корреляцией, wa при этом сколько ?

у Вас же CPU загружен, значит где-то какая-то математика, как уже выше заметили сами - select count выполняющийся на каждой странице - убийца сайтов всегда (зависит от их посещаемости), а вы сменили серверный xeon на i7, я не очень железячник, но предположу, что разница таки есть. То, откуда select count - большого размера ? В самой табличке много данных ?

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

Редко, но бывают ситуации когда либо ОС неверно инициализирует память или процессор. Или планки памяти воткнут не в правильном порядке. Например, NUMA включится там где не надо.

Покажите pt-summary на обоих серверах

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

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

Допустим, если запустить сложную криптографию "openssl speed dsa2048" будет ли сильно заметна разница ?

Проблема в том, что нечего предложить из распространенных пакетов. Работа mysql по агрегации данных скорее напоминает пересылку туда-сюда.

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

Вот попробуйте memtester вроде похож на правильную программу.

Если результаты отличаются в 2 раза - копаете железо. Если нет - mysql и приложения.

Проблемные запросы переписали - нагрузка упала. Так же в данный момент сильно грузит проц GZIP, а на старом сервере был модуль ГЗИПстатик, который отдавал уже сжатые файлы, что лежат на сервере

Dram, так запросы и были плохие пока и на старом сервере работали. У вас и версии mysql не отличаются. За исключением случая когда при переносе статистика перестраивается и планы портятся, запросы должны работать так же. А на новом похоже на проблемы с железом.

Возможно новый серв добил включенный гзип?

если gzip static то не должно, а если gzip nginx с компрессией 9 - то запросто.

Но его нету в atop по этому не он :)

Может apache ;)

Версии mysql отличаются. Он писал:

Мускуль новый Версия сервера: 5.5.43-0

Мускуль старый Версия сервера: 5.5.41-0+wheezy1-log

Надо было конфиги брать со старого сервера

Я заметил. Но в разрезе построения планов запросов можно считать что не отличаются. Убедиться можно внимательно почитав список отличий - там нет изменений или фиксов влияющих на план оптимизатора.

Не в правилах mysql менять что-то в оптимизаторе стабильной версии.

При переходе с 5.1 на 5.5 стоило бы ожидать изменения в планах, а в данной ситуации- нет.

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

Что за напасть такая!!!