Ошибка MySQL на сервере на базе SSD. Маленькие столы. Конфигурация MySQL? RAID?

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

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

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

Каждый сервер имеет 32 ГБ ОЗУ ECC.

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

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

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

RAM - это в основном (~ 60%) кэшированные данные.

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

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

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

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

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

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

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

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

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

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

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

Мы будем благодарны за любые идеи!