Fujisu Eternus DX100 low iSCSI read performance

Поломалось, посыпалось, не работает...

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить
vvk
Junior member
Сообщения: 7
Зарегистрирован: 16 дек 2008, 16:02
Откуда: Tyumen

Fujisu Eternus DX100 low iSCSI read performance

Сообщение vvk » 17 май 2017, 14:13

Есть СХД Fujitsu DX100, сконфигурирован Thin Provisioning Pool на дисках SAS 10000 1.2TB в режиме RAID1+0. По iSCSI отдан тестовый Volume на 128 GB. Никакой нагрузки на СХД нет.

Сеть: на СХД 4 порта iSCSI 10 Gbps, коммутатор HP 8212zl, СХД подключена к нему по оптике, сервера подключены кабелями Direct-Attach. Каждый контроллер СХД в отдельном VLAN-е. Включены jumbo-frames.

Сервера: HP ProLiant DL380p Gen8 с сетевухами HP Ethernet 10Gb 2-port 530SFP Adapter [652503-B21], система Proxmox 3.x

Проблема: скорость последовательного чтения с СХД существенно меньше, чем скорость записи.

Код: Выделить всё

# sync;fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/mapper/stor1 --bs=4M --iodepth=256 --size=10G --readwrite=write --ramp_time=4
test: (g=0): rw=write, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=256
2.0.8
Starting 1 process
Jobs: 1 (f=1): [W] [81.0% done] [0K/620.0M /s] [0 /155  iops] [eta 00m:04s]
test: (groupid=0, jobs=1): err= 0: pid=138977
  write: io=8636.0MB, bw=727661KB/s, iops=156 , runt= 12153msec
  cpu          : usr=4.58%, sys=4.11%, ctx=2122, majf=0, minf=19
  IO depths    : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.4%, 16=0.8%, 32=1.7%, >=64=131.1%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued    : total=r=0/w=1904/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=8636.0MB, aggrb=727660KB/s, minb=727660KB/s, maxb=727660KB/s, mint=12153msec, maxt=12153msec

Код: Выделить всё

# sync;fio --randrepeat=1 --ioengine=libaio --direct=1 --gtod_reduce=1 --name=test --filename=/dev/mapper/stor1 --bs=4M --iodepth=256 --size=10G --readwrite=read --ramp_time=4
test: (g=0): rw=read, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=256
2.0.8
Starting 1 process
Jobs: 1 (f=1): [R] [78.8% done] [256.0M/0K /s] [64 /0  iops] [eta 00m:07s] 
test: (groupid=0, jobs=1): err= 0: pid=141665
  read : io=8932.0MB, bw=415385KB/s, iops=89 , runt= 22019msec
  cpu          : usr=0.06%, sys=4.16%, ctx=1252, majf=0, minf=262165
  IO depths    : 1=0.1%, 2=0.1%, 4=0.2%, 8=0.4%, 16=0.8%, 32=1.6%, >=64=126.2%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.1%
     issued    : total=r=1978/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=8932.0MB, aggrb=415385KB/s, minb=415385KB/s, maxb=415385KB/s, mint=22019msec, maxt=22019msec

Т.е. по записи bw=727661KB/s, iops=156, по чтению bw=415385KB/s, iops=89. И так в общем-то на всех тестах - по чтению всегда несколько меньше IOPS чем по записи. Переписывались с их саппортом больше месяца, ничего внятного они так и не смогли сказать, вообще он у них какой-то очень недружеский.

Есть подозрения что проблема сетевая. И вот почему - если попинговать по SAN-сети с одного сервера другой большим пакетом, то картина такая:

Код: Выделить всё

# ping -s 8972 192.168.88.3
PING 192.168.88.3 (192.168.88.3) 8972(9000) bytes of data.
8980 bytes from 192.168.88.3: icmp_req=1 ttl=64 time=1.31 ms
8980 bytes from 192.168.88.3: icmp_req=2 ttl=64 time=0.132 ms
8980 bytes from 192.168.88.3: icmp_req=3 ttl=64 time=0.127 ms
8980 bytes from 192.168.88.3: icmp_req=4 ttl=64 time=0.134 ms
8980 bytes from 192.168.88.3: icmp_req=5 ttl=64 time=0.135 ms
8980 bytes from 192.168.88.3: icmp_req=6 ttl=64 time=0.124 ms
8980 bytes from 192.168.88.3: icmp_req=7 ttl=64 time=0.124 ms
8980 bytes from 192.168.88.3: icmp_req=8 ttl=64 time=0.126 ms
8980 bytes from 192.168.88.3: icmp_req=9 ttl=64 time=0.128 ms
8980 bytes from 192.168.88.3: icmp_req=10 ttl=64 time=0.129 ms
^C
--- 192.168.88.3 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9003ms
rtt min/avg/max/mdev = 0.124/0.247/1.315/0.356 ms

а если попинговать СХД, то такая:

Код: Выделить всё

# ping -s 8972 192.168.88.1
PING 192.168.88.1 (192.168.88.1) 8972(9000) bytes of data.
8980 bytes from 192.168.88.1: icmp_req=1 ttl=64 time=1.61 ms
8980 bytes from 192.168.88.1: icmp_req=2 ttl=64 time=0.499 ms
8980 bytes from 192.168.88.1: icmp_req=3 ttl=64 time=0.432 ms
8980 bytes from 192.168.88.1: icmp_req=4 ttl=64 time=0.432 ms
8980 bytes from 192.168.88.1: icmp_req=5 ttl=64 time=0.437 ms
8980 bytes from 192.168.88.1: icmp_req=6 ttl=64 time=0.433 ms
8980 bytes from 192.168.88.1: icmp_req=7 ttl=64 time=0.434 ms
8980 bytes from 192.168.88.1: icmp_req=8 ttl=64 time=0.469 ms
8980 bytes from 192.168.88.1: icmp_req=9 ttl=64 time=0.433 ms
8980 bytes from 192.168.88.1: icmp_req=10 ttl=64 time=0.434 ms
^C
--- 192.168.88.1 ping statistics ---
10 packets transmitted, 10 received, 0% packet loss, time 9004ms
rtt min/avg/max/mdev = 0.432/0.561/1.613/0.352 ms
Т.е. latency до СХД существенно выше. Есть подозрение что именно это как-то влияет. Может кто-то сталкивался и прокомментирует?

vvk
Junior member
Сообщения: 7
Зарегистрирован: 16 дек 2008, 16:02
Откуда: Tyumen

Re: Fujisu Eternus DX100 low iSCSI read performance

Сообщение vvk » 19 май 2017, 15:32

Тесты с помощью fio показывают интересную картину (multipath включен на сервере).

Конфиги fio:

seqread.ini:

Код: Выделить всё

[readtest]
blocksize=4m
filename=/dev/mapper/stor1
rw=read
direct=1
buffered=0
ioengine=libaio
iodepth=4
seqwrite.ini:

Код: Выделить всё

[readtest]
blocksize=4m
filename=/dev/mapper/stor1
rw=write
direct=1
buffered=0
ioengine=libaio
iodepth=4
На storage активирован 1 порт на 1 контроллере

Код: Выделить всё

stor1 (3600000e00d280000002808f600000000) dm-5 FUJITSU,ETERNUS_DXL
size=128G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
  |- 31:0:0:0 sde 8:64 failed faulty running
  |- 29:0:0:0 sdc 8:32 failed faulty running
  |- 30:0:0:0 sdd 8:48 active ready  running
  `- 28:0:0:0 sdb 8:16 failed faulty running

Запись:

Код: Выделить всё

# fio seqwrite.ini 
readtest: (g=0): rw=write, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [W] [100.0% done] [0K/604.0M /s] [0 /151  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=487373
  write: io=131072MB, bw=623338KB/s, iops=152 , runt=215321msec
    slat (usec): min=172 , max=2525 , avg=390.99, stdev=90.93
    clat (msec): min=7 , max=45 , avg=25.89, stdev= 4.55
     lat (msec): min=7 , max=46 , avg=26.28, stdev= 4.55
    clat percentiles (usec):
     |  1.00th=[13632],  5.00th=[18304], 10.00th=[20352], 20.00th=[22912],
     | 30.00th=[24192], 40.00th=[24960], 50.00th=[25728], 60.00th=[26752],
     | 70.00th=[27776], 80.00th=[29056], 90.00th=[31616], 95.00th=[33536],
     | 99.00th=[37632], 99.50th=[38656], 99.90th=[41728], 99.95th=[42240],
     | 99.99th=[44800]
    bw (KB/s)  : min=585142, max=654051, per=100.00%, avg=623953.28, stdev=12749.25
    lat (msec) : 10=0.24%, 20=9.05%, 50=90.71%
  cpu          : usr=3.05%, sys=2.89%, ctx=46260, majf=0, minf=21
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=32768/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=131072MB, aggrb=623337KB/s, minb=623337KB/s, maxb=623337KB/s, mint=215321msec, maxt=215321msec
Чтение:

Код: Выделить всё

# fio seqread.ini
readtest: (g=0): rw=read, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [R] [100.0% done] [560.0M/0K /s] [140 /0  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=500362
  read : io=131072MB, bw=610580KB/s, iops=149 , runt=219820msec
    slat (usec): min=168 , max=2312 , avg=253.80, stdev=75.24
    clat (msec): min=3 , max=158 , avg=26.58, stdev=16.80
     lat (msec): min=3 , max=158 , avg=26.83, stdev=16.80
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[    7], 10.00th=[    9], 20.00th=[   12],
     | 30.00th=[   17], 40.00th=[   20], 50.00th=[   23], 60.00th=[   28],
     | 70.00th=[   32], 80.00th=[   40], 90.00th=[   51], 95.00th=[   60],
     | 99.00th=[   73], 99.50th=[   87], 99.90th=[  112], 99.95th=[  119],
     | 99.99th=[  151]
    bw (KB/s)  : min=396648, max=760916, per=100.00%, avg=611253.28, stdev=55713.56
    lat (msec) : 4=0.95%, 10=13.92%, 20=28.45%, 50=46.00%, 100=10.43%
    lat (msec) : 250=0.25%
  cpu          : usr=0.09%, sys=3.72%, ctx=40318, majf=0, minf=4118
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=32768/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=131072MB, aggrb=610580KB/s, minb=610580KB/s, maxb=610580KB/s, mint=219820msec, maxt=219820msec
Что видим: запись=чтение, скорости примерно одинаковы, упираются скорее всего в сеть, latency одинакова.

На storage активировано 2 порта на одном контроллере

Код: Выделить всё

stor1 (3600000e00d280000002808f600000000) dm-5 FUJITSU,ETERNUS_DXL
size=128G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
  |- 31:0:0:0 sde 8:64  failed faulty running
  |- 29:0:0:0 sdc 8:32  failed faulty running
  |- 30:0:0:0 sdd 8:48  active ready  running
  `- 28:0:0:0 sdb 8:16  active ready  running
Запись:

Код: Выделить всё

# fio seqwrite.ini 
readtest: (g=0): rw=write, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [W] [100.0% done] [0K/716.0M /s] [0 /179  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=577515
  write: io=131072MB, bw=734667KB/s, iops=179 , runt=182692msec
    slat (usec): min=181 , max=4164 , avg=399.33, stdev=98.60
    clat (msec): min=7 , max=44 , avg=21.90, stdev= 4.95
     lat (msec): min=7 , max=44 , avg=22.30, stdev= 4.94
    clat percentiles (usec):
     |  1.00th=[ 9792],  5.00th=[13504], 10.00th=[15424], 20.00th=[17792],
     | 30.00th=[19328], 40.00th=[20864], 50.00th=[22144], 60.00th=[23168],
     | 70.00th=[24448], 80.00th=[25984], 90.00th=[28032], 95.00th=[29824],
     | 99.00th=[33024], 99.50th=[34048], 99.90th=[37632], 99.95th=[38144],
     | 99.99th=[41216]
    bw (KB/s)  : min=660908, max=781741, per=100.00%, avg=735398.28, stdev=18669.70
    lat (msec) : 10=1.19%, 20=32.53%, 50=66.29%
  cpu          : usr=3.56%, sys=3.58%, ctx=46325, majf=0, minf=21
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=32768/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=131072MB, aggrb=734666KB/s, minb=734666KB/s, maxb=734666KB/s, mint=182692msec, maxt=182692msec
Чтение:

Код: Выделить всё

# fio seqread.ini 
readtest: (g=0): rw=read, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [R] [100.0% done] [536.0M/0K /s] [134 /0  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=586382
  read : io=131072MB, bw=513434KB/s, iops=125 , runt=261412msec
    slat (usec): min=148 , max=6235 , avg=260.83, stdev=79.10
    clat (msec): min=3 , max=154 , avg=31.65, stdev=17.41
     lat (msec): min=3 , max=155 , avg=31.91, stdev=17.41
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[    8], 10.00th=[   10], 20.00th=[   17],
     | 30.00th=[   21], 40.00th=[   26], 50.00th=[   31], 60.00th=[   36],
     | 70.00th=[   40], 80.00th=[   46], 90.00th=[   55], 95.00th=[   63],
     | 99.00th=[   83], 99.50th=[   91], 99.90th=[  109], 99.95th=[  117],
     | 99.99th=[  139]
    bw (KB/s)  : min=372363, max=709543, per=100.00%, avg=514005.99, stdev=58255.54
    lat (msec) : 4=0.66%, 10=9.68%, 20=18.87%, 50=56.77%, 100=13.82%
    lat (msec) : 250=0.20%
  cpu          : usr=0.08%, sys=3.20%, ctx=43295, majf=0, minf=4118
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=32768/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=131072MB, aggrb=513433KB/s, minb=513433KB/s, maxb=513433KB/s, mint=261412msec, maxt=261412msec

Что видно: запись стала чуть побольше - на СХД принимают данные 2 интерфейса, но на сервере отправка идёт через 1. Latency на чтение больше чем на запись, скорость чтения и IOPS-ы просели по сравнению с работой через 1 интерфейс.

На storage активировано 2 порта на разных контроллерах.

Код: Выделить всё

stor1 (3600000e00d280000002808f600000000) dm-5 FUJITSU,ETERNUS_DXL
size=128G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=0 status=active
  |- 31:0:0:0 sde 8:64 failed faulty running
  |- 29:0:0:0 sdc 8:32 active ready  running
  |- 30:0:0:0 sdd 8:48 active ready  running
  `- 28:0:0:0 sdb 8:16 failed faulty running

Последовательная запись:

Код: Выделить всё

# fio seqwrite.ini
readtest: (g=0): rw=write, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8               
Starting 1 process  
^Cbs: 1 (f=1): [W] [24.6% done] [0K/940.0M /s] [0 /235  iops] [eta 01m:47s]
fio: terminating on signal 2
                    
readtest: (groupid=0, jobs=1): err= 0: pid=876149
  write: io=31748MB, bw=950611KB/s, iops=232 , runt= 34199msec
    slat (usec): min=208 , max=2116 , avg=410.06, stdev=108.58
    clat (msec): min=5 , max=33 , avg=16.82, stdev= 3.51
     lat (msec): min=5 , max=33 , avg=17.23, stdev= 3.51
    clat percentiles (usec):
     |  1.00th=[ 7008],  5.00th=[10304], 10.00th=[12096], 20.00th=[14144],
     | 30.00th=[15424], 40.00th=[16320], 50.00th=[17280], 60.00th=[18048],
     | 70.00th=[18816], 80.00th=[19584], 90.00th=[20608], 95.00th=[22144],
     | 99.00th=[24704], 99.50th=[26240], 99.90th=[28544], 99.95th=[30592],
     | 99.99th=[33024]
    bw (KB/s)  : min=905689, max=1009749, per=100.00%, avg=951471.64, stdev=16969.05
    lat (msec) : 10=4.32%, 20=80.62%, 50=15.06%
  cpu          : usr=4.48%, sys=4.97%, ctx=12026, majf=0, minf=21
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=7937/d=0, short=r=0/w=0/d=0
                    
Run status group 0 (all jobs):
  WRITE: io=31748MB, aggrb=950611KB/s, minb=950611KB/s, maxb=950611KB/s, mint=34199msec, maxt=34199msec
Последовательное чтение:

Код: Выделить всё

# fio seqread.ini
readtest: (g=0): rw=read, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [R] [99.7% done] [560.0M/0K /s] [140 /0  iops] [eta 00m:01s]
readtest: (groupid=0, jobs=1): err= 0: pid=878178
  read : io=131072MB, bw=361941KB/s, iops=88 , runt=370828msec
    slat (usec): min=146 , max=7701 , avg=267.41, stdev=89.38
    clat (msec): min=3 , max=259 , avg=45.00, stdev=32.78
     lat (msec): min=3 , max=259 , avg=45.26, stdev=32.78
    clat percentiles (msec):
     |  1.00th=[    5],  5.00th=[    8], 10.00th=[   10], 20.00th=[   17],
     | 30.00th=[   22], 40.00th=[   30], 50.00th=[   40], 60.00th=[   48],
     | 70.00th=[   52], 80.00th=[   68], 90.00th=[   91], 95.00th=[  110],
     | 99.00th=[  137], 99.50th=[  155], 99.90th=[  174], 99.95th=[  178],
     | 99.99th=[  217]
    bw (KB/s)  : min=126273, max=697536, per=100.00%, avg=362980.35, stdev=97454.38
    lat (msec) : 4=0.43%, 10=10.40%, 20=15.84%, 50=39.46%, 100=27.63%
    lat (msec) : 250=6.23%, 500=0.01%
  cpu          : usr=0.06%, sys=2.31%, ctx=43426, majf=0, minf=4118
  IO depths    : 1=0.1%, 2=0.1%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=32768/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=131072MB, aggrb=361940KB/s, minb=361940KB/s, maxb=361940KB/s, mint=370828msec, maxt=370828msec
Что видим: чтение через 2 контроллера медленнее чем запись и медленнее чем чтение через 1 контроллер. Latency по чтению более чем в 2 раза выше чем по записи. WTF?

Аватара пользователя
Umlyaut
Advanced member
Сообщения: 370
Зарегистрирован: 09 июл 2010, 11:23
Откуда: Москва

Re: Fujisu Eternus DX100 low iSCSI read performance

Сообщение Umlyaut » 19 май 2017, 15:50

vvk писал(а): Что видим: чтение через 2 контроллера медленнее чем запись и медленнее чем чтение через 1 контроллер. Latency по чтению более чем в 2 раза выше чем по записи. WTF?
Подозреваю, у Вас мультипас криво работает (то ли настроен так, то ли идеологически ущербен).

Попробуйте подтвердить (или опровергнуть это) банальным тестом через один активный линк от хоста до СХД (можно для вящей пользы пробить этот бенчмарк дважды - через коммутатор и директ-линком). Если "внезапно(тм)" всё сохранится как есть, то копать надо в сторону СХД (например, её дисковой группы и/или взаимодействия контроллеров).
Ну а коли на одиночном линке статус кво будет восстановлен (R > W), стало быть Вам надо плющить настройки мультипаса.

Как-то так.

vvk
Junior member
Сообщения: 7
Зарегистрирован: 16 дек 2008, 16:02
Откуда: Tyumen

Re: Fujisu Eternus DX100 low iSCSI read performance

Сообщение vvk » 22 май 2017, 14:56

Попробуйте подтвердить (или опровергнуть это) банальным тестом через один активный линк от хоста до СХД
Там выше есть такой тест, где 1 активный path в multipath. Скорость чтения примерно равна записи. Просадка идёт только когда несколько линков работает. Пробовал крутить rr_min_io в multipath.conf - 0 эффекта.

vvk
Junior member
Сообщения: 7
Зарегистрирован: 16 дек 2008, 16:02
Откуда: Tyumen

Re: Fujisu Eternus DX100 low iSCSI read performance

Сообщение vvk » 22 май 2017, 16:50

Вот для сравнения поднял iSCSI Target на соседней linux-машине с бэкендом на ramdisk, чтобы проверить чисто работу сети/multipath.
Одинаковые задержки на read и write, скорость одинаковая. Настройки multipath те же самые, что и с работой с fujitsu DX100. Получается, multipath сам по себе нормально работает. Вот такой вот active-active ALUA на DX100, блин.

Код: Выделить всё

caesium (36001405060f4c32cd35420bb20271f6a) dm-3 LIO-ORG,RAMDISK-MCP
size=16G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=25 status=active
  |- 32:0:0:0 sdj 8:144 active ready running
  `- 33:0:0:0 sdk 8:160 active ready running

Код: Выделить всё

root@argentum:/tmp# fio seqwrite-caes.ini 
readtest: (g=0): rw=write, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [W] [100.0% done] [0K/1348M /s] [0 /337  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=979446
  write: io=16384MB, bw=1334.5MB/s, iops=333 , runt= 12278msec
    slat (usec): min=260 , max=4829 , avg=529.51, stdev=134.04
    clat (msec): min=4 , max=33 , avg=11.46, stdev= 1.70
     lat (msec): min=5 , max=33 , avg=11.99, stdev= 1.70
    clat percentiles (usec):
     |  1.00th=[ 8768],  5.00th=[ 9536], 10.00th=[10048], 20.00th=[10432],
     | 30.00th=[10688], 40.00th=[10944], 50.00th=[11200], 60.00th=[11456],
     | 70.00th=[11712], 80.00th=[12096], 90.00th=[12992], 95.00th=[14272],
     | 99.00th=[17792], 99.50th=[21888], 99.90th=[24448], 99.95th=[24960],
     | 99.99th=[33024]
    bw (MB/s)  : min= 1308, max= 1400, per=100.00%, avg=1367.93, stdev=25.35
    lat (msec) : 10=9.47%, 20=89.92%, 50=0.61%
  cpu          : usr=8.68%, sys=8.48%, ctx=11156, majf=0, minf=21
  IO depths    : 1=0.1%, 2=0.1%, 4=99.9%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=0/w=4096/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
  WRITE: io=16384MB, aggrb=1334.5MB/s, minb=1334.5MB/s, maxb=1334.5MB/s, mint=12278msec, maxt=12278msec
root@argentum:/tmp# fio seqread-caes.ini
readtest: (g=0): rw=read, bs=4M-4M/4M-4M, ioengine=libaio, iodepth=4
2.0.8
Starting 1 process
Jobs: 1 (f=1): [R] [100.0% done] [1232M/0K /s] [308 /0  iops] [eta 00m:00s]
readtest: (groupid=0, jobs=1): err= 0: pid=980276
  read : io=16384MB, bw=1311.2MB/s, iops=327 , runt= 12488msec
    slat (usec): min=186 , max=1793 , avg=287.22, stdev=85.87
    clat (msec): min=3 , max=27 , avg=11.90, stdev= 2.07
     lat (msec): min=5 , max=27 , avg=12.19, stdev= 2.07
    clat percentiles (usec):
     |  1.00th=[10048],  5.00th=[10304], 10.00th=[10560], 20.00th=[10688],
     | 30.00th=[10944], 40.00th=[11072], 50.00th=[11328], 60.00th=[11584],
     | 70.00th=[11840], 80.00th=[12480], 90.00th=[13888], 95.00th=[15936],
     | 99.00th=[21632], 99.50th=[22912], 99.90th=[24960], 99.95th=[25216],
     | 99.99th=[27008]
    bw (MB/s)  : min=  954, max= 1471, per=100.00%, avg=1349.14, stdev=116.37
    lat (msec) : 4=0.02%, 10=0.54%, 20=97.58%, 50=1.86%
  cpu          : usr=0.19%, sys=9.05%, ctx=6321, majf=0, minf=4119
  IO depths    : 1=0.1%, 2=0.1%, 4=99.9%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
     submit    : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     complete  : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
     issued    : total=r=4096/w=0/d=0, short=r=0/w=0/d=0

Run status group 0 (all jobs):
   READ: io=16384MB, aggrb=1311.2MB/s, minb=1311.2MB/s, maxb=1311.2MB/s, mint=12488msec, maxt=12488msec

vvk
Junior member
Сообщения: 7
Зарегистрирован: 16 дек 2008, 16:02
Откуда: Tyumen

Re: Fujisu Eternus DX100 low iSCSI read performance

Сообщение vvk » 22 июн 2017, 12:55

Чтобы подытожить тему. Обнаружили, что если создать volume на СХД и сразу читать из него, то сторадж успешно кормит клиента нулями из кэша на максимальной скорости линка. В таком режиме видно, что максимальная прогрузка линков получается при подключении 2-я путями к 2-м контроллерам СХД. Если добавить 3-й и тем более 4-й путь, скорость сразу проседает, растёт latency. Кто в этом виноват - linux iscsi / multipath или сторадж - установить не удалось, т.к. сравнить не с чем - нет linux-машины с 4-я 10G интерфейсами чтобы воссоздать ситуацию.

Так что мы остановились на использовании 2-х активных путей к разным контроллерам, с Active-Active ALUA mode.

Ответить

Вернуться в «Массивы - Технические вопросы, решение проблем.»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 7 гостей