Mark ☢️
Александр
Вот я и спрашиваю, а точно ли мегабиты
Mark ☢️
да точно, точно
Mark ☢️
ладно, я специально сделаю айперф до каждого цефного узла, но уверен, что причина не в этом
Александр
Тцп и удп проверял?
Mark ☢️
проверю специально чуть позже.
Александр
А внутри себя работает хорошо, так?
Александр
Я про скорости
Александр
Внутри ноды
Александр
И это, как там с la?
Mark ☢️
ну ребят, цеф же не срёт мелкими пакетами...
Евгений
А 10 гигабит оптикой?
Александр
Ну ты же ищешь где место узкое, так что..
Mark ☢️
DAC-кабели
Mark ☢️
коммутатор Quanta LB6M
Александр
Т.е. где затык
Mark ☢️
Не похоже. всякие очереди, лоад эвераджи и тд дают дёрганный график. а тут прямо строго горизонтальная линия
Евгений
Не похоже. всякие очереди, лоад эвераджи и тд дают дёрганный график. а тут прямо строго горизонтальная линия
Дальше идут игры с irqbalance и посадка osd при помощи cgroup на одно ядро с прерываниями от сетевухи и контроллера дисков
Mark ☢️
гонево
Mark ☢️
это всё при 10 гигабитах
Mark ☢️
на одном гигабите - это всё ничего не нужно. я гарантирую это.
Mark ☢️
и да, они все оптимизируют CPU
Mark ☢️
а у меня оно крайне низко
Mark ☢️
кластерная 10 гигабит
Mark ☢️
клиентская 1 гигабит
Mark ☢️
сегменты изолированные
Mark ☢️
кракен
Евгений
не к чему подкопаться
Mark ☢️
именно, Карл
Евгений
Ябпоискал забитые очереди на интерфейсах и коммутаторе
Mark ☢️
Их не будет. Потому что тисипи адаптируется
Mark ☢️
Если они вдруг есть
Mark ☢️
Но посмотрим, ладно
Дмитрий
именно, Карл
[root@on01 var]# fio —time_based —name=benchmark —size=10G —runtime=30 —filename=/var/lib/one/datastores/110/test —ioengine=libaio —randrepeat=0 —iodepth=128 —direct=1 —invalidate=1 —verify=0 —verify_fatal=0 —numjobs=4 —rw=randread —blocksize=4k —group_reporting
benchmark: (g=0): rw=randread, bs=4K-4K/4K-4K/4K-4K, ioengine=libaio, iodepth=128
...
fio-2.2.8
Starting 4 processes
Jobs: 4 (f=4): [r(4)] [100.0% done] [102.4MB/0KB/0KB /s] [26.3K/0/0 iops] [eta 00m:00s]
benchmark: (groupid=0, jobs=4): err= 0: pid=2689: Sun Apr 30 13:49:26 2017
read : io=2815.7MB, bw=95515KB/s, iops=23878, runt= 30186msec
slat (usec): min=6, max=698, avg=28.68, stdev= 9.47
clat (usec): min=223, max=617275, avg=21406.54, stdev=50069.48
lat (usec): min=250, max=617308, avg=21435.62, stdev=50069.73
Получаю ~750МБит с Гигабитного клиента
9 SSD на 3 нодах, ceph version 12.0.2, везде centos 7.3, mtu 9000
монтирую так
10.1.16.1:6789:/ /var/lib/one/datastores/110 ceph rw,relatime,name=admin,secret=xxx,nodcache 0 0
на клиенте ceph version 0.94.5, все по умолчанию.
G72K
дефолтный CUBIC как раз забивает все очереди под завязку и потом страдает
Mark ☢️
жду
Mark ☢️
benchmark: Laying out IO file(s) (1 file(s) / 10240MB)
Mark ☢️
Mark ☢️
и чо
Александр
Mark ☢️
и чо
Александр
А почему так мало то
Mark ☢️
ну магнитные диски же. чот ты хотел. при размере пула 3 и 128 глубине очереди
Mark ☢️
так что очччень не плохо
Mark ☢️
Mark ☢️
первый прямоугольник - это линейная запись через фио.
Mark ☢️
блин.. и второй тоже
Mark ☢️
щас введу команду по рандомреаду
Mark ☢️
echo 3 > /proc/sys/vm/drop_caches
Mark ☢️
вот это надо перед тестом сделать
Mark ☢️
на чтение
Mark ☢️
Mark ☢️
xntybt
Mark ☢️
РАНДОМНОЕ чтение
Mark ☢️
Mark ☢️
Линейное чтение
Mark ☢️
что за хрень
Mark ☢️
Mark ☢️
линейное чтение в один поток
Mark ☢️
цпу на клиенте в районе нуля
Дмитрий
локально на 1 ноде рандом рид
Jobs: 4 (f=4): [r(4)] [100.0% done] [222.2MB/0KB/0KB /s] [56.9K/0/0 iops] [eta 00m:00s]
benchmark: (groupid=0, jobs=4): err= 0: pid=202932: Sun Apr 30 15:20:32 2017
read : io=6591.2MB, bw=224542KB/s, iops=56135, runt= 30058msec
В 3 раза хуже rbd
Tverd
может пропустил, но МТУ 9к на интерфейсе стоит?
Mark ☢️
Тестили ранее. Не более 3-5 процентов на тцп
Tverd
10G мы подняли 9к мту, перестройка стала шустрее
Mark ☢️
Дак то 10
Mark ☢️
короче. я ебанат
Mark ☢️
у меня ВНЕЗАПНО оказалось что на клиенте шёл трафик через Dlink DGE-828-T
Mark ☢️
Когда-то я говорил что-то там насчёт говённого реалтека. не ведитесь на это. есть намного хуже.
Mark ☢️
