Индексы в базе не потерялись при переносе?

Какая версия mysql на исходном сервере, какая на целевом?

В 5.6.8 query_cache_type off по-умолчанию, например, это может повлиять на производительность (даже если ты не трогал конфиг, а только обновился)

Mysql

Исходный сервер 5.5.44-0+deb8u1 Обновленный сервер 55.52-0+deb8u1

Версию mysql сервера откатывал назад, специально нашел старые пакеты и переустановил - ничего не изменилось

База переносилась стандартными средствами mysqldump для экспорта и mysql для импорта, объем базы ~10Gb, в виде .sql файла 2Gb

А не сохранили, какие запросы тормозили?

Не используй fake-raid. Делай массив на mdadm.

большие большие SELECTы с созданием временных таблиц. Вот что пишет mysqltuner

MySQLTuner 1.3.0 - Major Hayden <major@mhtx.net>

>> Bug reports, feature requests, and downloads at http://mysqltuner.com/ >> Run with '--help' for additional options and output filtering [OK] Logged in using credentials from debian maintenance account. [OK] Currently running supported MySQL version 5.5.44-0+deb8u1 [OK] Operating on 64-bit architecture

-------- Storage Engine Statistics ------------------------------------------- [--] Status: +ARCHIVE +BLACKHOLE +CSV -FEDERATED +InnoDB +MRG_MYISAM [--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17) [--] Data in InnoDB tables: 10G (Tables: 108) [!!] Total fragmented tables: 108

-------- Security Recommendations ------------------------------------------- [OK] All database users have passwords assigned

-------- Performance Metrics ------------------------------------------------- [--] Up for: 24m 6s (62K q [43.130 qps], 484 conn, TX: 38M, RX: 13M) [--] Reads / Writes: 99% / 1% [--] Total buffers: 3.1G global + 2.7M per thread (151 max threads) [OK] Maximum possible memory usage: 3.5G (11% of installed RAM) [OK] Slow queries: 0% (0/62K) [OK] Highest usage of available connections: 5% (9/151) [OK] Key buffer size / total MyISAM indexes: 16.0M/103.0K [OK] Key buffer hit rate: 100.0% (2K cached / 0 reads) [OK] Query cache efficiency: 57.8% (35K cached / 60K selects) [!!] Query cache prunes per day: 153440 [OK] Sorts requiring temporary tables: 0% (0 temp sorts / 2K sorts) [OK] Temporary tables created on disk: 22% (3K on disk / 14K total) [OK] Thread cache hit rate: 97% (10 created / 484 connections) [OK] Table cache hit rate: 94% (129 open / 136 opened) [OK] Open file limit used: 1% (20/1K) [OK] Table locks acquired immediately: 100% (49K immediate / 49K locks) [!!] InnoDB buffer pool / data size: 3.0G/10.3G [OK] InnoDB log waits: 0 -------- Recommendations ----------------------------------------------------- General recommendations: Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Variables to adjust: query_cache_size (> 16M) innodb_buffer_pool_size (>= 10G)

На оригинальном сервере всё работает именно так и не тормозит. То же самое без обновлений на новом сервере. Предложенные оптимизации не помогают

Может быть на старом сервере временные таблицы создавались на SSD, на новом на HDD https://dev.mysql.com/doc/refman/5.5/en/temporary-files.html Но это не объясняет повышеную загрузку процессора. Вообще, такие запросы нужно соптимизировать. Ну или хоть увеличить tmp_table_size/max_heap_table_size

На новом сервере все точки монтирования на одном SSD, HDD никак не задействованы. На прежнем сервере /var живёт на жестком диске, остальное на SSD. Сейчас на новом сервере на одном ssd всё работает быстро, но система старая. Либо не париться и идти по принципу - работает-не трогай и переживать за дырки в безопасности, либо решать проблему точечно обновляя пакеты.

По поводу оптимизации - увеличение tmp_table_size/max_heap_table_size улучшит ситуацию, но эффекта «вау» не будет, так как само приложение и его запросы довольно таки тяжелые. Всё это уже переписывается и переделывается заного и по нормальному. Пока этот процесс идёт, прежняя версия должна нормально работать в исходном виде, в безопасной среде с поправками на то, что теперь сервер смотрит в интернет напрямую

Не вариант - твой ssd когда-нибудь откажет и будет «ой». RAID нужен.

Сервер не мой, он арендован у немцев в датацентре.