um E / S de leitura aleatória de 16K emite 2 solicitações de I / O scsi (16K e 4K) no linux

Question

Eu notei um estranho problema ao fazer um benchmarking de E / S de leitura aleatória para arquivos no linux (2.6.18). O programa Benchmarking é meu próprio programa e ele simplesmente continua lendo 16KB de um arquivo de um deslocamento aleatório.

Eu tracei o comportamento de E / S no nível de chamada do sistema e no nível scsi por systemtap e Eu notei que um sysread de 16KB emite 2 scsi I / Os da seguinte forma.

SYSPREAD random(8472) 3, 0x16fc5200, 16384, 128137183232 
SCSI random(8472) 0 1 0 0 start-sector: 226321183 size: 4096 bufflen 4096 FROM_DEVICE 1354354008068009
SCSI random(8472) 0 1 0 0 start-sector: 226323431 size: 16384 bufflen 16384 FROM_DEVICE 1354354008075927
SYSPREAD random(8472) 3, 0x16fc5200, 16384, 21807710208 
SCSI random(8472) 0 1 0 0 start-sector: 1889888935 size: 4096 bufflen 4096 FROM_DEVICE 1354354008085128
SCSI random(8472) 0 1 0 0 start-sector: 1889891823 size: 16384 bufflen 16384 FROM_DEVICE 1354354008097161
SYSPREAD random(8472) 3, 0x16fc5200, 16384, 139365318656 
SCSI random(8472) 0 1 0 0 start-sector: 254092663 size: 4096 bufflen 4096 FROM_DEVICE 1354354008100633
SCSI random(8472) 0 1 0 0 start-sector: 254094879 size: 16384 bufflen 16384 FROM_DEVICE 1354354008111723
SYSPREAD random(8472) 3, 0x16fc5200, 16384, 60304424960 
SCSI random(8472) 0 1 0 0 start-sector: 58119807 size: 4096 bufflen 4096 FROM_DEVICE 1354354008120469
SCSI random(8472) 0 1 0 0 start-sector: 58125415 size: 16384 bufflen 16384 FROM_DEVICE 1354354008126343

Como mostrado acima, um bloco de 16KB emite 2 I / Os scsi. (Eu rastreei o scsi io despachando com o probe scsi.iodispatching. Por favor, ignore os valores, exceto para o setor inicial e tamanho).

Uma E / S scsi é 16KB E / S, conforme solicitado pelo aplicativo e está OK. A coisa é a outra E / S de 4KB que eu não sei porque o linux emite essa E / S.

É claro que o desempenho de E / S é degradado pela I / O de 4KB e estou com problemas. Eu também uso fio (famosa ferramenta de benchmark de E / S) e notei o mesmo problema, então não é da aplicação.

Alguém pode me explicar isso?

    

Answer 1

Isso pode ser uma coisa estúpida / óbvia que você já tenha verificado, mas seu sistema de arquivos está montado com o noatime flag?

Se você não especificou noatime , o Linux precisará atualizar o inode toda vez que um arquivo for acessado (para definir o a cesso tempo ), o que significa tem que ler a área do disco que contém o inode e escrevê-lo de volta. (Por acaso, é por isso que os sistemas de arquivos de leitura crítica de desempenho devem ser montados com noatime - a E / S para atualizar inodes constantemente é substancial e pode ser um resultado de desempenho mensurável).

    

Answer 2

Eu descobri o que está acontecendo, mas não sei para que serve.

O sistema de arquivos Ext3 possui alguns dados de 4KB em cada dado de 4096 KB (setores 8192). Visualmente, os dados são alinhados da seguinte forma.

| 4KB | 4096KB | 4KB | 4096KB | 4KB | 4096KB | ...

E área de 4096 KB somente acessível por programas aplicativos. Ao acessar a primeira área de 4096KB pela primeira vez, então OS lê o 4KB pouco antes da área de 4096KB primeiro e em seguida, leia os dados solicitados na área de 4096 KB.

Ao acessar um arquivo grande (comparado ao tamanho da DRAM) aleatoriamente, cada E / S tem uma chance rara de acessar o cahce da página, então cada solicitação de E / S vem junto com 4KB I / O.

A coisa é para que servem os dados de 4KB? Este metadado de localização é para o sistema de arquivos? Existe alguma maneira de remover isso? Ou existe alguma maneira de limpar apenas a área de 4096 KB?

Quaisquer comentários e conselhos são apreciados.

(Eu testei em muitas máquinas com muitas versões de kernel. isso acontece em todas as máquinas.)

Obrigado.

    

Answer 3

Eu percebi isso. É do mapeamento de bloco indireto ext3. (Ext3 tem um bloco que tem ponteiros de bloco em cada 1024 blocos.)

Eu mudei o sistema de arquivos para ext4 faz o problema desaparecer. (Ext4 tem esquema mais eficiente para endereçamento de bloco.)

Obrigado a todos.