MySQL работает плохо на SSD-сервере. Маленькие столики. MySQL конфиг? RAID?

У меня есть пара серверов в промышленной среде (сеть с воздушным зазором), которые проводят довольно легкие телеметрические сборы. Мы генерируем около 10 ГБ истории телеметрии за ~30 дней.

Вся телеметрия входит в набор таблиц, разделенных на два типа: текущее состояние и история. Таблицы состояний обычно имеют 16 строк или меньше. Таблицы истории могут быть довольно большими, но общее количество составляет около 11 ГБ. Скорость телеметрии составляет чуть менее 100 выборок в секунду, а таблицы истории обновляются только в том случае, если что-то меняется или прошло 30 секунд. Из моих проверок "назад за конвертом" обновление истории пропускается примерно 9 раз из 10. Поэтому в большинстве случаев каждый пример приводит к одному ЗАМЕНЕ INTO в одну из примерно шести таблиц.

Все это работает на стандартной загрузке сервера Ubuntu 14.04 (64-разрядная версия) на серверах Supermicro 1U с процессорами Xeon с 2015 года или около того. Я не на фабрике, поэтому я не могу проверить точную модель.

Каждый сервер имеет 32 ГБ оперативной памяти ECC.

Диски имеют конфигурацию RAID 1 с четырьмя дисками (технические специалисты на заводе не работают быстро, когда диск выходит из строя, поэтому мы хотим много резервного копирования). Все диски постоянно контролируются с помощью Smartctl, и когда один из них показывает сбой или предупреждение, мы заменяем его. В декабре мы заменили диски на одном из серверов и сделали то же самое с другим.

На обоих серверах производительность MySQL обычно хорошая с временем отклика в одну цифру в миллисекундах при обновлении таблиц состояния. Тем не менее, мы получаем экстремальные выбросы. Время от времени, несколько раз в день и, как правило, чаще, чем раз в час, мы видим, что одно ЗАМЕНА В 16-рядную таблицу состояния занимает> 1,5 секунды. Это вызывает тревогу, что мы потеряли телеметрию, так что это более чем раздражает.

Все таблицы InnoDB, один файл на таблицу. Сброс включен для файловой системы (ext4). Я попытался изменить параметры MySQL, чтобы отключить синхронизацию при фиксации (вместо этого используя периодическую синхронизацию), и это, похоже, не дало результата. У меня есть журнал объемом 1 ГБ для InnoDB, а сами файлы базы данных значительно меньше оперативной памяти.

ОЗУ в основном (~60%) кэширует данные.

Я попытался изменить типы таблиц таблиц состояния на MyISAM, но проблема остается неизменной.

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

Тот факт, что MyISAM ничего не изменил (и я имею в виду, что вообще не было заметных изменений в поведении), заставляет меня заподозрить RAID.

Диски совершенно новые (менее двух недель) Crucial MX500, 1 ТБ. Да, это потребительские диски, но скорость записи довольно низкая. И мы постоянно поддерживаем файловую систему менее чем на 40%.

Я в недоумении, что попробовать дальше. Это проблема RAID? Это проблема конфигурации MySQL?

Я вижу задержку во всех таблицах состояний, даже в таблицах с 1 строкой. Строки в некоторых случаях немного широки (у одного 125 столбцов), но они все еще очень и очень малы.

Таблицы состояния / состояния имеют первичные ключи для обеспечения уникальности данных.

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

Я не был достаточно умен, чтобы установить iostat на серверах, когда они были впервые установлены. Тем не менее, оригинальные тесты с hdparm -tT, казалось, показали, что на базовых дисках все в порядке. Никакие диски не показывают проблемы в smartctl.

Замена дисков производилась по одному, поэтому RAID-массив - это фактически старый RAID-массив (основанный на MX200). RAID не был восстановлен с нуля, когда диски были заменены.

Есть ссылки на известную проблему с этой версией MySQL (5.5 что-то) и REPLACE INTO, но ничто из того, что я прочитал, не говорит о том, что я должен увидеть такое значительное изменение производительности.

Любые идеи были бы хорошы!