Почему может тупить на запись RAID1 из двух SSD дисков?
Linux, mdadm, raid1 2x1Tb Samsung Pro SSD. Сильно тормозит скорость записи на raid1 массив. При записи большого объема информации (более 2-3 Гб) скорость записи падает до 17-20 МБ/с и остается такой на протяжении всего процесса копирования.
TRIM включен. smartctl -a не выдает проблем. Памяти куча, проц сильный. Тупит запись.
Например:
dd if=/dev/zero bs=110K count=60000 | pv | dd of=./zero.dd
может выдать примерно 17-20 MB/s.
dd if=/dev/zero bs=110K count=500 | pv | dd of=./zero.dd
выдаст нормально, 230-250 MB/s, причем если быстро запустить команду раза три-четыре, то скорость по чуть-чуть норовит упасть.
dd if=/dev/zero bs=2100K count=5000 | pv | dd of=./zero.dd
выдает через 30 секунд снижение скорости с 250 до 30, а потом опять 17-20 MB/s.
Точно такую же скорость записи наблюдаю и при копировании в mc.
Проблема случайно проявила себя, просто не надо было никогда писать ничего более 1-2-3 Гб сразу. А тут стал лить архивы гигов под 180 и сразу вылезло.
Это нормально.
Уперлись в деградацию скорости записи.
Поскольку TRIM в ваших условиях работать не будет да и если бы работал толку от него ноль, то нужно обходиться без него.
Over provisioning спасет ситуацию
Во первых TRIM это команда, если трим включен, это значит что команда отправляется, но не значит что доходит.
Во вторых TRIM в большинстве случаев не проходит через различные виртуальные прослойки вроде рэйдов, lvm, и прочего
И самое главное в вашей ситуации даже работающий TRIM будет бесполезен.
Нужен over provisioning приличного размера - не менее чем размер одной непрерывной записи.
Т.е если часто записываете на диск большой объем информации например 50гб, то нужно чтобы размер over provisioning был более 50гб.
обычный софтверный рейд прекрасно работает с трим. over provisioning - почитайте документацию до 30% и это на корп сегменте. Так что 100% переизбыточность это сказка. А вот виртуалка действительно могла бы тормозить но это в теории.
АртемЪ: Если на диске LVM, то уменьшение раздела LVM может считаться улучшением "over provisioning"? Запас места есть, можно попробовать освободить гигов 50 спокойно.
MarvinD: over provisioning это область диска недоступная пользователю и операционной системе.
Причем там не должно быть данных.
Т.е это должен быть неразмеченная область диска - на ней не должно быть разделов.
Перед тем как создать эту неразмеченную область нужно гарантированно очистить весь диск - как правило это делает утилита от производителя.
Хотя можно сделать и без нее, но сложнее.
ОС CentOS 7, fs ext4. Обидно будет, если так себя ведет такая ось. Похожий комп, только с 2xSATA, такие же тесты, скорость 80 показывает.
НО! Что характерно, клиенты (да и я сам вижу это сильно) стали работать НАМНОГО шустрее, чем раньше (на этом сервере диски были заменены на SSD после огромных тормозов и длиннющих очередей по iostat. Может, есть что-то до неприличия простое, что я мог упустить?
Смотрел тут про особенности монтирования, предлагается использовать опции "defaults,noatime,discard". У меня просто все:
/dev/mapper/centos-root / ext4 defaults 1 1
Это не может быть причиной?
chupasaurus: на запасном сервере с discard скорость поднялась до 80 МБ/с. Рву волосы, очень стыдно, жду возможности проверить на главном сервере. Спасибо.
Всё проще. Чтобы записать хотя бы байт - нужно перезаписать целиком блок, обычно это 128к. Это значит, что уже чистый блок должен быть. Или его надо очищать прямо сейчас. Очистка блока - медленно. Есть трим или нет - при больших записях чистых блоков может не хватить. И всё, приехали.
Облегчают проблему серверные диски и оверпровизионинг.
