slizh

Нас Vmware вообще не интересует. Мы чисто решили для сравнения протестировать. Мы хотим, чтобы KVM работал нормально, а не резал скорость хотя бы чтения.

С iOPS у нас все в порядке. Именно обычная команда dd на чтение сильно проседает на VPS и мы не можем понять причину.

dd на запись:

dd if=/dev/zero of=test bs=64k count=16k conv=fdatasync oflag=direct

dd на чтение:

dd if=test of=/dev/null bs=1M count=1024 iflag=direct

Скорость показывает постоянно одинаковую. И судя по тому, что при смене рейд ничего не меняется, то дело явно в типе виртуализации и метода хранения данных. Может в LVM есть какие-то ограничения, чтобы 1 VPS не накрыла всю ноду?

Используется virtio.

Хранилище на основе ссд дисков и рейд контроллера.

Причем здесь интерфейс?

Там все указано специально через SNAT. Разве это неправильно?

дело в том, что мой личный VPN также залочило. возможно где-то косяк в настройках?

Айпи у меня уже давно. По идее, никто не пользуется кроме меня. А могут ли меня забанить, если соседние айпи таким занимаются?

Ip адрес сервера, на котором установлен VPN. Да, личный.

TRIM тоже работает.

Ребята, подскажите. Я пошел дальше и купил такие же диски, как в первом случае. Также их в рейд поставил. Накатил такую же систему. Результат тот же. Первое мнение - виновата материнка. Обновил биос, потестировал. Тоже самое. Потом начал грешить на backpanel. Подключил напрямую без нее. Аналогично. Проверил прошивку дисков. Такая же как и на первом сервере. Купил материнку с новым чипсетом. Такой же результат. Я реально в шоке и не понимаю, что же такое на первом сервере сделано. Может со стороны установщика прописывается какой-нибудь block size или что еще может быть...

1) 1-й сервер

READ: io=3071.7MB, aggrb=365445KB/s, minb=365445KB/s, maxb=365445KB/s, mint=8607msec, maxt=8607msec

WRITE: io=1024.4MB, aggrb=121867KB/s, minb=121867KB/s, maxb=121867KB/s, mint=8607msec, maxt=8607msec

2)

READ: io=3071.7MB, aggrb=233805KB/s, minb=233805KB/s, maxb=233805KB/s, mint=13453msec, maxt=13453msec

WRITE: io=1024.4MB, aggrb=77968KB/s, minb=77968KB/s, maxb=77968KB/s, mint=13453msec, maxt=13453msec

Все равно на втором сервере с такими же дисками есть просадка. Как это объяснить?

EvGenius:
да причем тут материнка если диски-то разные.
у ssd все очень сложно с производительностью. упор на разные вещи делается, разные настройки изначально ставятся и по-разному можно самостоятельно настроить.

есть к примеру micron p320h 700gb, вроде бы замечательная вещь, SLC, 50Pb ресурс, 3.2/1.9 скорости чтения/записи. вот только создавалась она изначально под многопроцессорные системы с расчетом на то что ее грузить будут одновременно большим количеством потоков задач. ей подавай блоки данных по-больше и глубину очереди в 256 хотя бы.
при этом у нее есть настройка чтобы сместить производительность в сторону маленькой очереди, хоть и в ущерб максимальным iops'ам.
так вот даже при такой настройке она при обычной небольшой нагрузке маленькой очередью с маленькими блоками показывает хуже производительность чем p3700 400gb на MLC с 2.7/1.0 скоростями (и в раз в 7 ниже ресурсом, к слову).

запись 4k блоками, очередь 8 - 320мб/с



а если подбавить размер блока до 64k и глубину увеличить до 256 уже получаем положенные 1.9гб/с на запись



в то время как p3700 при тех же 4k/8 уже с ходу выдает больше 800мб/с запись:



т.е. p3700 больше подходит для однопроцессорного не слишком загруженного серверка.
хоть p320h в целом гораздо круче, но она просто не раскроет себя полностью в обычных задачах.
но зато можно пользоваться и вообще не переживать за надежность. 50 петабайт - это уровень!
сколько там ресурс на ваших самсунгах? 🙄

а вот для сравнения они же в смешанном тесте read/write 4k/64





т.е. более-менее на равне ~580 чтение и 190 запись
но опять же, если куда-нибудь сместить размер блока или глубину очереди, то кто-то из них будет вырываться в лидеры.

ну и для сравнения sata'шный s3700 400:



145/48 мб/с "всего лишь". в кавычках т.к. все равно в том же битриксе как видите вполне вменяемый результат выдает.
что покажут pci-e диски, поглядим... хотя там же не только от дисков все зависит.

в общем мораль такова - если вам кажется что "pro" самсунг проигрывает в производительности, то возможно он еще проявит себя в чем-то другом. например дольше проживет :)

ну и стоит поковырять фирменными утилитами разные настройки. я правда не знаю что там как у самсунгов, но наверняка что-то должно быть.
к примеру в p320h по-умолчанию write buffer был выключен и от этого производительность была еще хуже.
я его включил и по-лучше стало, правда пугает вариант с пропадением питания и потерей данных из буфера.
на более современных s3700/p3700/p420m для этого есть встроенный конденсатор, который в случае чего поддержит питание и закончит запись нормально.

Т.е. получается, что все из-за дисков?

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

Вы написали про write cache buffer и я сразу стал гуглить, как проверить, включен ли он. Много информации для виндовс систем и их программа magican + есть rapid mode - http://www.samsung.com/ch/business-images/resource/white-paper/2014/01/Whitepaper-Samsung_SSD_Rapid_Mode-0.pdf

Тем не менее, ничего толкового для linux.

Первый сервер из хецнера. Может они что-то оптимизируют при установке ОС или на самих дисках? ОС Centos7.

На второй материнке биос обновил. Ничего не изменилось. Неужели разница только в дисках.

На втором сервере явная проблема с записью - https://gyazo.com/ba9d78692a0a624b00c9eeddcb5f7f9a