Делай, как знаешь))

Ну у меня нет опыта работы с докером, поэтому консультируюсь

на оф сайте, контейнер собран под дебиан 10-й

+1

Насколько я понимаю, это про base OS

Хотя... там же ядро вообще не виртуализируется, а остальное через cgroups и прочее?

Так что даже двойной нет

Добрый день есть проблема по скорости работы сервера.
При выводе команды
time dd if=/dev/urandom of=test bs=1024k count=10
команда выводит около 15МB/s. (1-ый сервер 10 ядер sas ssd raid, 64 ОЗУ) на втором сервер где (1 ядро ssd sata выводит 150МB/s ) Ровно в 15 раз больше. Не могу понять что не правильно работает на первом.

Наверное, тут нужно знать на чем находится файл test, в который вы пишете. Плюс скорость самого urandom

Не пробовали другие бенчмарки?

Что покажет, если источником поставить /dev/zero? А /dev/random?

Замерить ещё скорость копирования из fs в fs

Мало свободной памяти, высокая нагрузка на систему?

Вообще, было бы неплохо кеширование в памяти отключить для дд, но я не помню, как это делается

Вернее, не отключить, а заставить дд ждать честной записи данных в диск, прежде чем писать следующий блок

oflag=dsync

Современные накопители зануляют довольно быстро, намного быстрее чем пишут. Это работает за счет того, что контроллер в момент "зануления" не физически отчищает ячейки, а просто помечает их для себя как "свободные". А отчищаются они уже при записи в них
Urandom же довольно быстрый, т.к. там используется генератор псевдо-случайных чисел. Он запускается, приняв в качестве стартовой точки "истинное" случайно число uint32 из /dev/random. А последний довольно медленный за счет того, что генерирует "истинно" случайные числа. Но так как это довольно дорогой процесс, истинно случайны числа генерируются довольно редко с точки зрения системы. Его генератор имеет не очень высокий приоритет, и при старте ОС наполнят специальный "пул энтропии" случайными числами. При чтении из этого пула числа, генератор удаляет часть этого пула, из-за чего пулл требует наполнения. Поэтому при чтении из /dev/random процесс будет вечность ждать наполнения этого пула, а не записи в диск. Наполнение пула  можно ускорить, запуская генератор чаще, но лучше просто использовать dev/urandom, так как с  точки зррения криптографии они равнозначно случайны

Наверное несколько сумбурно

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

все находяться на техже дисках