Вообще, docker дает немного специфичную нагрузку на хост. Я имею ввиду, что без docker большинство процессов являются предками своих чилдренов, в случае же docker - те самые предки есть тоже дети процессов, таких как containerd.
При этом ваша ОС - не совсем понимает, что происходит. Раньше (без docker) пользователь запускал демонов, каждый из которых был чадом от init.d процесса, а сейчас - пользователь порешил запустить некоторую странную службу (типа /usr/bin/containerd) и начал активно ветвить с ее помощью детей на детей, тех детей еще на детей :)
"Так как же мне распределять нагрузку, генерируемую со стороны всего этого детского сада в сторону ваших винчестеров, уважаемый пользователь?" - спросила ваша ОС.
Подскажем ей. И подскажем примерно следующее:
"Уважаемая ОС! Распределяй, пожалуйста, ресурсы винчестеров (особенно SSD) по принципу "кто первый встал, того и тапки!".
Подсказать довольно просто:
sudo nano /etc/default/grub
Указываем в параметре GRUB_CMD_LINE_LINUX (а можно и через пробел в GRUB_CMDLINE_LINUX_DEFAULT) следующее:
GRUB_CMD_LINE_LINUX="elevator=noop transparent_hugepage=never"
Сохраняем файл. Записываем изменения в загрузчике:
sudo update-grub
Перезагружаем хост.
Собственно elevator=noop - устанавливает noop в качестве I/O scheduler ядра по умолчанию. Noop - формирует весь стек комманд в сторону вашего HDD в виде FIFO-очереди, которая работает тем самым нужным нам способом - "кто первый встал, того и тапки". Прирост по OLTP операциям в БД заметите тут же.
transparent_hugepage=never - можете и не ставить, данный параметр выключает штатный механизм THP, который на облачных хостингах формирует в целом бОльшую нагрузку на хост, чем хотелось бы видеть. Сильно на запись в БД он влиять не будет, если нет мощных нагрузок. Если же нагрузка крутая, есть смысл выключать данный механизм.
"А что же за гадость такая этот ваш docker? Что же мне - теперь каждую виртуалку конфигурировать при создании вот в таких интимных местах?" - спросите вы.
Отвечу.
Linux - бесплатная ОС для самого широкого спектра задач. Она не windows, она не будет хардкодить за вас все параметры ядра, которые могут отличаться в рамках этих самых задач, решаемых на вашем хосте. А потом - колосально глючить без вариантов. Linux - ставится даже на стиральные машины, холодильники, и черт знает куда еще. Ваша задача - подсказать ОС, что вы делаете. ОС - не подведет. В свою очередь - разработчики служб dockerd и containerd не могут нести ответственность за поведение их продукта на хостах, работающих на коробочных настройках. Docker - дает вам экосистему, которая позволяет решать очень крутые задачи быстрее, чем это сделает матерый старообрядский сис-админ руками в консоли.
Можно документировать нужные настройки хоста в confluence, написать подробные инструкции по шагам - что нужно сделать с ОС после установки, чтобы на ней все летало. Удобно, советую. Можно обратить внимание на продукт Teraform, который может помочь вам автоматизировать создание хостов в промышленных количествах с заданными параметрами.
Как-то так. Пробуйте :)