Dotaz: Diskové pole a iostat util na 100

[OgeeN]

Ahoj, potřeboval bych poradit s interpretací výstupu iostatu.

Mám nasazené diskové pole ze kterého se čtou data pro celkem vytížené webové stránky.

Data exportuje nfs server pomocí NFS a sám je k diskovému poli připojený pomocí iscsi a multipath.

Výstup příkazu iostat -dxc 2 mi téměř neustále ukazuje util disku na 100%, nicméně nezaznamenávám žádné výkonnostní problémy a i load average na serveru se mi podařilo spíše snížit.

Mám si s výstupem níže dělat starosti?

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           0.06    0.00    8.99   33.21    0.00   57.74

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
cciss/c0d0        0.00     3.00    0.00    1.00     0.00    16.00    32.00     0.00    2.00    0.00    2.00   2.00   0.20
dm-9            713.00   692.50  332.50  338.50  1505.50  2218.00    11.10     4.75    7.10   13.17    1.13   1.49 100.00
sde               0.00     0.00  332.50  603.50  1505.50  2218.00     7.96     1.52    1.63    3.54    0.57   0.76  71.60
sdd               0.00     0.00    0.00    0.00     0.00     0.00     0.00     0.00    0.00    0.00    0.00   0.00   0.00

Díky.

Odpovědi

[jirka]

Ahoj,

man iostat rika: %util : Percentage of CPU time during which I/O requests were issued to the device (bandwidth utilization for the device). Device saturation occurs when this value is close to 100%.

Tj. vypada to, ze "jedes" na hranici resp. saturaci device

Otazka je, jestli se da naladit reseni na vyssi vykon a nebo uz jsi narazil na nejaky bottleneck.

Urcite by se dalo jeste optimalizovat, ale zalezi jake mas pole, disky a jejich backend, jake Raidove skupiny, jak pracujes a cache, jaky mas IO pattern, jestli pouzivas bonding pro iscsi, jestli mas dobre naladeny multipath atd, atd.

Jirka

[OgeeN]

Ahoj,

tak tu utilizaci mi způsobuju findy, pomocí nichž vyhledávám změněné soubory, které pak synchronizuji na záložní svazek(totéž pole, jiný RAID, jiný řadič, jiné disky). Jakmile jsem findy schodil, tak byla %util poloviční.

Diskové pole máme HP P2000 G3, iscsi, 4x10Gbit/s. Zmíněný svazek leží sám na RAID10 poli z 12 disků +1 hot spare.

Výpis multipath:

root@nfs2:~# multipath -ll
3600c0ff00012731163fbe35001000000 dm-9 HP,P2000 G3 iSCSI
size=683G features='1 queue_if_no_path' hwhandler='0' wp=rw
|-+- policy='round-robin 0' prio=130 status=active
| |- 10:0:0:0 sde 8:64  active ready running
| `- 9:0:0:0  sdd 8:48  active ready running
`-+- policy='round-robin 0' prio=10 status=enabled
  |- 7:0:0:0  sda 8:0   active ready running
  `- 8:0:0:0  sdb 8:16  active ready running

Co mě zarazilo, bylo to, že se používají pouze disky sde a sdd. Na disky sda a sdb není podle iostatu směrován žádný provoz.

Konfigurace multipath:

defaults {
       udev_dir                /dev
       polling_interval        10
       selector                "round-robin 0"
       path_grouping_policy    multibus
       getuid_callout          "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
       prio                    const
       path_checker            directio
       rr_min_io               100
       flush_on_last_del       no
       max_fds                 8192
       rr_weight               priorities
       failback                immediate
       no_path_retry           fail
       queue_without_daemon    no
       user_friendly_names     no
       mode                    644
       uid                     0
       gid                     disk
}
blacklist {
       wwid 26353900f02796769
       devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
       devnode "^hd[a-z][[0-9]*]"
       devnode "^sda1"
       device {
               vendor DEC.*
               product MSA[15]00
       }
}
#"NIKDY nepouzivejte pro jmena svazku aliasy. Zpusobuje to zasekavani multipath demona.!
multipaths {
        multipath {
                wwid                    3600c0ff00012731163fbe35001000000
        #       alias                   data
        }
}
devices {
       device {
               vendor                  "HP"
               product                 "P2000 G3 FC|P2000 G3 iSCSI"
               path_grouping_policy    group_by_prio
               getuid_callout          "/lib/udev/scsi_id --whitelisted --device=/dev/%n"
               path_checker            tur
               path_selector           "round-robin 0"
               hardware_handler        "0"
               prio                    alua
               failback                immediate
               rr_weight               uniform
               no_path_retry           18
               rr_min_io               100
       }

Zatím takhle. Zbylé termíny si vyhledám.

Děkuju za odpověď.

[jirka]

Ahoj,

bude jenom hadat. Na R10 je jeden LUN, ktery vlastni storage processor resp. controler A nebo B. Je to tak ? Pokud ano, pak jsou Prvni dve cesty k tomuto kontroleru aktivni a druhe jsou enabled pro pripad failoveru na urovni backendu.

Aby byly naplno vitizene oba SP resp. controlery a vsechny cesty , udelal bych 2 x R10 a v kazdem LUN a ty pak rozhodil na SP Contr. A a SP. Contr. B. Ke klientovy by byly exportovany dva LUNy. LUNy bych pak svazal pomoci LVM do jednoho device pro Fileserver.

Tim dojde k zatizene vsech cest a vsech CPU na poli = vyssi vykon, nizsi latence atd.

Jirka

[OgeeN]

Ahoj, děkuju za tip, je to přesně tak. Bohužel teď nemám možnost navrhované nastavení vyzkoušet. Nejsem si jistý jestli by pomohlo zvýšit iops. Protože i když půjdu přes dva různé kotrolery, tak budu mít stejný počet disků. Nebo se pletu?

Nicméně jsem nastavil path_grouping_policy na multibus a provoz je teď podle iostatu rozkládán na všechny disky, resp. kontrolery:

3600c0ff00012731163fbe35001000000 dm-9 HP,P2000 G3 iSCSI
size=683G features='1 queue_if_no_path' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=70 status=active
  |- 10:0:0:0 sde 8:64  active ready running
  |- 9:0:0:0  sdd 8:48  active ready running
  |- 7:0:0:0  sda 8:0   active ready running
  `- 8:0:0:0  sdb 8:16  active ready running

Iops to bohužel nezvýšilo.

[Käyttäjä 11133]

jestli pouzivas bonding pro iscsi

Ten kdo doporučuje bonding pro iSCSI by si zasloužil nafackovat...

[OgeeN]

jj, bondovany intarface vůči iscsi se choval naprosto nepředvídatelně. Rozhodně nepoužívat.

[Käyttäjä 11133]

Přihřeju si polívčičku :) Oh, really? – 1 – Bonded iSCSI interfaces

[OgeeN]

Co nedělat už vím. Otázka zní, jak tedy odlehčit diskovému poli, když kvůli synchronizaci dat mezi dvěma svazky, nad ním potřebuji několikrát denně pouštět find?

[Käyttäjä 11133]

Nesynchronizovat tak hloupě jak to děláš. Takže synchronizovat na blokové úrovni...

[OgeeN]

Jak to provést mezi dvěma svazky na stejném diskovém poli? Samotné pole tohle neumí tak jak bych to potřeboval. To jsem už zkoumal.