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

Dram, этот скрипт запускает dmidecode чтобы собрать всякую инфу. Но dmidecode не сработала правильно и поэтому не видно модель материнской платы. Но можно предположить, если 4 из 4 слотов памяти забиты симметрично, то NUMA там внезапно не образуется. наличие NUMA можно в dmesg посмотреть наверняка.

Зато видно, что на новом частота ядер сейчас снижена до 800. Лучшие друзья вебмастера любят экономить электричество.

Причем, на старых картинках вижу частоту 800 в период нагрузки http://s020.radikal.ru/i707/1506/d0/a165f3f7545c.jpg

можно заключить, что автоматический разгон частоты не работал.

Есть ли графики частоты в munin за большие периоды ? Это более точно покажет работоспособность механизма разгона.

начните с переключения cpu governor таким мини-скриптом. это в файл надо набрать и запустить:

Или просто в эти файлы в /sys/ вручную запишите значение. В конечном итоге вы должны увидеть 3.4Ghz в atop .

Потом убедитесь что время работы gzip сравнимо со старым. на двух сервера запускаете gzip с подсчетом времени работы :

time gzip -9 путь-к-большому-пребольшому-файлу-с-бекапом

Но мне кажется, дело именно в разгоне.

Похоже netwind прав, не знаю как на это не обратили внимание те 3 админа.

Вот же мунин все рисовал.

Так чей это все так косяк - хедзнера или админа, настроившего серв с нуля?

А это важно ?

Да сколько платите - столько и делают вам.

Как заранее узнать, что разгон в этой конфигурации не будет работать, если времени на нагрузочное тестирование не выделить ?

Обычно эти штуки работают автоматически. Вон на первом же сервере работает - там 1800Mhz и это не максимум.

Может быть hetzner какие-то свои энергосберегающие плюшки стал сейчас устанавливать в образ, но раньше не замечал. У других хостеров бывало.

Может быть просто платформа более новая и менее обкатанная именно debian.

Еще раз настоятельно прошу показать вывод команды

cat /proc/mdstat

на вашем "тупящем" сервере

Синхронизация была и закончилась еще до того, как я перенес на новый серв 1 сайт

root@srv ~ # cat /proc/mdstat

Personalities : [raid1]

md2 : active raid1 sda3[0] sdb3[1]

1919300544 blocks super 1.2 [2/2] [UU]

md1 : active raid1 sda2[0] sdb2[1]

523968 blocks super 1.2 [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]

33537920 blocks super 1.2 [2/2] [UU]

unused devices: <none>

Как сказать, тупящий процессор после настройки можно не заметить только в случае, если __вообще__ не тестировать никак. Но что это за админ, который бенчмарк не запустит, чтобы хотя бы убедиться, что ничего не ляжет?

ТС, а попробуйте после изменений теперь openssl speed на обоих серверах. Должен выходить из состояния idle (800 МГц) и должен быть быстрее старого.

Ребят, спасибо всем , а особенно netwind, но сил и времени тестировать новый серв больше нет.

Так нашли ведь проблему, теперь только проверить, что устранили и сервером можно пользоваться.

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

Тем более на этом чуть медленнее диски. Я получил хороший опыт, теперь буду умнее в выборе следующего сервера

Вам нужно быть умнее в выборе следующего админа. Кстати у меня на всех серверах в Hetzner стоит ondemand, а не performance. Проблем нет нигде.

Так что это вы вылечили следствие, но не исправили причину.