Новый MySQL Server медленнее старого

Question

Таким образом, у меня есть новый сервер MySQL, который работает медленнее, чем тот, который он заменяет. Я пытаюсь определить, происходит ли это из-за почти несуществующей нагрузки на новом сервере, пока я тестирую его (IE: оптимизатор запросов не знает, что делать). Я просто не хочу нажимать на эту штуку, и наши приложения перестают работать.

Теперь для деталей... оба сервера MySQL (Percona) 5.5. "Старый" сервер - это Xeon 8c/16t, 128 ГБ оперативной памяти, 6x SAS 15k RAID10 box. "Новый" сервер - это двойной Xeon, 16c/32t, 256 ГБ оперативной памяти, 6x SSD RAID 10.

На старом сервере запущен Debian, новый Ubuntu. Это почти единственное не аппаратное различие между ними. Оба используют ТОЧНУЮ конфигурацию my.cnf. База данных MySQL строго INNODB.

У меня "новый" сервер настроен как ведомый "старому" для тестирования. Однако большинство запросов на выбор в 2-10 раз медленнее при выполнении на новом, значительно более быстром оборудовании. Даже после того, как буферный пул успел загрузиться, последующие запросы выполняются намного медленнее. Похоже, новый сервер не будет ничего кешировать, несмотря на одинаковые настройки.

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

Черт возьми, ниже приведена измененная часть my.cnf, которая в настоящее время находится на каждом боксе. Текущий действующий сервер (старый) составляет около 600 выборок / сек, 150 вставок / сек. Иногда всплывает, чтобы удвоить этот объем.

key_buffer              = 128M
max_allowed_packet      = 16M
thread_stack            = 192K
thread_cache_size       = 8
max_connections         = 350 
read_rnd_buffer_size    = 2M
read_buffer_size        = 1M
sort_buffer_size        = 2M
join_buffer_size        = 3M 
bulk_insert_buffer_size = 8M
table_open_cache        = 4096
table_definition_cache  = 2048 
thread_cache_size       = 32
max_heap_table_size     = 64M 
tmp_table_size          = 64M 
query_cache_limit       = 4M
query_cache_size        = 128M

default-storage-engine  = innodb
innodb_buffer_pool_size = 81920M
innodb_additional_mem_pool_size = 20M
innodb_buffer_pool_instances = 4 
innodb_log_file_size    = 256M  
innodb_log_buffer_size  = 4M 
innodb_thread_concurrency = 12
innodb_flush_method     = O_DIRECT  
innodb_flush_log_at_trx_commit = 2  
innodb_file_format      = barracuda
innodb_support_xa       = 0         
innodb_file_per_table   = true
innodb_max_dirty_pages_pct=75 
innodb_read_io_threads  = 8
innodb_write_io_threads = 8
innodb_io_capacity      = 500

Заранее благодарю за любую помощь.

---- РЕДАКТИРОВАТЬ: Образец запроса и объяснения ---

Вот один из самых неприятных запросов (выбранный специально), использующий объединение и объединения. Он просматривает данные RFID в двух таблицах и объединяет их.

Log_RFID_WebService имеет ~5 миллионов строк. Log_RFID_Zonal имеет ~2 миллиона строк.

Время выполнения старого сервера (3 запуска): .110, .074, .074

Время выполнения нового сервера (3 запуска): .234, .250, .249

Опять же, похоже на проблему кеширования... или временные таблицы намного медленнее на новом сервере... что все равно не имеет смысла для меня

SELECT 
sql_calc_found_rows 
Q.*,D.MktDlrCode,GetLastOrder(Q.CustId,D.StoreId,Q.Timestamp) As       LastOrder
FROM 
((SELECT
Zonal.ID,Zonal.CustId,Zonal.SID,'' As  Lane,Zonal.RFIDtag,ANT.Antenna,ANT.Location,ANT.Direction,Timestamp,DATE_FORMAT(Timestamp,'%c/%d/%y %l:%i:%s %p') As DateTimestamp
FROM Portal.Log_RFID_Zonal As Zonal 
INNER JOIN Portal.Log_RFID_Antennas As ANT ON
ANT.Antenna=Zonal.LocationCode AND
ANT.SID=Zonal.SID AND
ANT.IgnoreFlag=0
WHERE
Zonal.Timestamp>=STR_TO_DATE('08/01/2015','%m/%d/%Y') AND
Zonal.Timestamp<DATE_ADD(STR_TO_DATE('08/01/2015','%m/%d/%Y'), INTERVAL 1     day)
ORDER BY Zonal.Timestamp DESC
)
UNION
(SELECT
RFID.ID,RFID.CustId,RFID.SID,RFID.Lane,RFID.RFIDtag,ANT.Antenna,ANT.Location,ANT.Direction,Timestamp,DATE_FORMAT(Timestamp,'%c/%d/%y %l:%i:%s %p') As DateTimestamp
FROM Portal.Log_RFID_WebService As RFID 
INNER JOIN Portal.Log_RFID_Antennas As ANT ON
ANT.Antenna=RFID.LocationCode AND
ANT.SID=RFID.SID AND
ANT.IgnoreFlag=0 
WHERE
RFID.Timestamp>=STR_TO_DATE('08/01/2015','%m/%d/%Y') AND
RFID.Timestamp<DATE_ADD(STR_TO_DATE('08/01/2015','%m/%d/%Y'), INTERVAL 1 day)
ORDER BY RFID.Timestamp DESC
)
ORDER BY
Timestamp DESC
) As Q
INNER JOIN Stores As D ON
D.StoreId=Q.SID AND
D.ReportFlag=1
LIMIT 0,25;

Объяснение одинаково на обоих серверах для этого конкретного запроса:

Id SelType      Table        Type    Key       Rows    Extra
1 PRIMARY      <derived>    ALL               300     Using where;Using Index
1 PRIMARY      D            ref     StoreId   1       Using Where
2 DERIVED      Zonal        range   ix1       6368    Using where
2 DERIVED      ANT          eq_ref  PRIMARY   1       Using where
3 UNION        RFID         range   ix1       938     Using where
3 UNION        ANT          eq_ref  PRIMARY   1       Using where
  UNION RESULT              ALL               0       Using filesort

Answer 1

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