Por que o io scheduler não está mesclando solicitações?

Question

Por que o io scheduler não está mesclando solicitações?

#1 resposta do (3 votos)

3

Após algum tempo (ou quantidade de dados gravados) após a reinicialização do servidor, a velocidade de gravação cai para menos de 1 MB / s. Isto é independente de qual sistema de arquivos (também partição bruta) e independente de HDD (HW RAID) ou SSD (SW RAID com SSD conectado a portas AHCI da placa-mãe, não a placa de ataque). Estamos testando com o comando dd if=/dev/zero of=tst bs=1M oflag=dsync (eu tentei também 1k e também sem dsync , mas o desempenho não foi melhor).

A única coisa estranha que notei foi que o avgrq-sz é apenas 8 na saída do iostat (em outros servidores testados era mais de 600) e que o req / s é de cerca de 100 (também no SSD). A execução de mais dd em paralelo deu a cada um deles 1 MB / s e cada um deles cerca de 100 req / s.

Amostra iostat -xN 1 output:

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00    0.00  125.00     0.00   500.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00     0.00    0.00  124.00     0.00   496.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00     3.00    0.00  128.00     0.00   524.00     8.19     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00     6.00    0.00  124.00     0.00   728.00    11.74     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00     0.00    0.00  125.00     0.00   500.00     8.00     0.00    0.00    0.00    0.00   0.00   0.00
sdc               0.00     3.00    0.00  128.00     0.00   524.00     8.19     0.00    0.00    0.00    0.00   0.00   0.00

Saída Iostat com 8x dd em execução:

sdc               0.00    64.00    0.00  959.00     0.00  7560.00    15.77     0.00    0.00    0.00    0.00   0.00   0.00

A saída

lsblk -O é consistente com outros servidores, que não têm esse problema (como MIN-IO, RQ-SIZE, LOG-SEC). O kernel atual é o 4.9.16-gentoo, mas o problema começou com o kernel antigo. A execução de dd com oflag=direct é rápida.

EDITAR: Com base na resposta do shodanshok, vejo agora que as solicitações são realmente pequenas, mas a pergunta é por que o io scheduler não as mescla em solicitações maiores? Eu tentei os agendadores cfq e deadline . Existe alguma coisa que eu possa verificar (ou comparar com outros servidores)?

Saída ao executar com oflag=direct (a velocidade é boa):

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
sdc               0.00     0.00    2.00  649.00     8.00 141312.00   434.16     2.78    4.26    2.00    4.27   1.53  99.60
sdc               0.00     0.00    0.00  681.00     0.00 143088.00   420.23     2.71    3.99    0.00    3.99   1.46  99.20
sdc               0.00     0.00    2.00  693.00     8.00 146160.00   420.63     2.58    3.71    0.00    3.72   1.42  98.80
sdc               0.00    49.00    2.00  710.00     8.00 146928.00   412.74     2.68    3.76   22.00    3.71   1.39  99.20
sdc               0.00     0.00    1.00  642.00     4.00 136696.00   425.19     2.43    3.79   60.00    3.71   1.42  91.60

O servidor é o Dell PowerEdge R330 com 32 GB de RAM, controlador LSI MegaRAID 3108 com HDDs, SSDs conectados ao SATA onboard e CPU Intel E3-1270. Sistema de arquivos ext3, mas o mesmo acontece com dd para partição bruta.

Saída de lsblk (sdc é HW RAID HDD, sda / sdb SW RAID SSDs):

NAME    MAJ:MIN RM   SIZE RO TYPE  MOUNTPOINT
sdb       8:16   0 223.6G  0 disk
|-sdb4    8:20   0     1K  0 part
|-sdb2    8:18   0   140G  0 part
| '-md1   9:1    0   140G  0 raid1 /
|-sdb5    8:21   0    25G  0 part
| '-md2   9:2    0    25G  0 raid1 /var/log
|-sdb3    8:19   0     1G  0 part
|-sdb1    8:17   0    70M  0 part
| '-md0   9:0    0    70M  0 raid1 /boot
'-sdb6    8:22   0  57.5G  0 part
  '-md3   9:3    0  57.5G  0 raid1 /tmp
sr0      11:0    1  1024M  0 rom
sdc       8:32   0   3.7T  0 disk
'-sdc1    8:33   0   3.7T  0 part  /home
sda       8:0    0 223.6G  0 disk
|-sda4    8:4    0     1K  0 part
|-sda2    8:2    0   140G  0 part
| '-md1   9:1    0   140G  0 raid1 /
|-sda5    8:5    0    25G  0 part
| '-md2   9:2    0    25G  0 raid1 /var/log
|-sda3    8:3    0     1G  0 part
|-sda1    8:1    0    70M  0 part
| '-md0   9:0    0    70M  0 raid1 /boot
'-sda6    8:6    0  57.5G  0 part
  '-md3   9:3    0  57.5G  0 raid1 /tmp

Com oflag=direct , a velocidade está boa, mas o problema é que os aplicativos não usam o io direto, por isso mesmo o cp está lento.

/sys/block/sdc/queue/hw_sector_size : 512
/sys/block/sdc/queue/max_segment_size : 65536
/sys/block/sdc/queue/physical_block_size : 512
/sys/block/sdc/queue/discard_max_bytes : 0
/sys/block/sdc/queue/rotational : 1
/sys/block/sdc/queue/iosched/fifo_batch : 16
/sys/block/sdc/queue/iosched/read_expire : 500
/sys/block/sdc/queue/iosched/writes_starved : 2
/sys/block/sdc/queue/iosched/write_expire : 5000
/sys/block/sdc/queue/iosched/front_merges : 1
/sys/block/sdc/queue/write_same_max_bytes : 0
/sys/block/sdc/queue/max_sectors_kb : 256
/sys/block/sdc/queue/discard_zeroes_data : 0
/sys/block/sdc/queue/read_ahead_kb : 128
/sys/block/sdc/queue/discard_max_hw_bytes : 0
/sys/block/sdc/queue/nomerges : 0
/sys/block/sdc/queue/max_segments : 64
/sys/block/sdc/queue/rq_affinity : 1
/sys/block/sdc/queue/iostats : 1
/sys/block/sdc/queue/dax : 0
/sys/block/sdc/queue/minimum_io_size : 512
/sys/block/sdc/queue/io_poll : 0
/sys/block/sdc/queue/max_hw_sectors_kb : 256
/sys/block/sdc/queue/add_random : 1
/sys/block/sdc/queue/optimal_io_size : 0
/sys/block/sdc/queue/nr_requests : 128
/sys/block/sdc/queue/scheduler : noop [deadline] cfq
/sys/block/sdc/queue/discard_granularity : 0
/sys/block/sdc/queue/logical_block_size : 512
/sys/block/sdc/queue/max_integrity_segments : 0
/sys/block/sdc/queue/write_cache : write through

io linux

por Marki555 13.05.2017 / 23:07

1 resposta

Tags io linux

Como atualizar todos os pacotes de nós com o leme netsh comando dhcp binding não está funcionando no Server 2016?

score 3 · Answer 1

O tamanho da solicitação ( avgrq-sz ) é pequeno porque você está emitindo pequenos pedidos de gravação. Seu comando dd , embora especificando um tamanho de bloco de 1 MB, está atingindo a pagecache e, portanto, cada solicitação de 1 MB realmente é uma coleção de solicitações de 256 * 4 KB. Isso é refletido pelo avgrq-sz , que, expresso em unidades de 512 bytes, se alinha perfeitamente com a entrada de página de 4 KB. Além disso, mesmo o SSD pode ter um desempenho ruim com gravações sincronizadas, conforme solicitado por oflag=dsync . Dito isso, observe que o agendador de E / S deve mesclar essas solicitações pequenas de 4 KB em outras maiores , mas isso não está acontecendo.

Algumas coisas para verificar:

o que você vê emitindo cat /sys/block/sdc/queue/scheduler ? Se noop for o agendador selecionado, tente selecionar deadline
é seu /sys/block/sdc/queue/max_sectors_kb pelo menos 1024?
tente executar dd if=/dev/zero of=tst bs=1M oflag=direct : o desempenho de E / S deve ser muito maior, certo?