Quantificando os efeitos do mau alinhamento da partição

Question

Estou com alguns problemas significativos de desempenho em um servidor NFS. Eu tenho lido um pouco sobre o alinhamento de partições, e eu acho que minhas partições estão desalinhadas. Não consigo encontrar nada que me diga como realmente quantificar os efeitos das partições mal alinhadas. Algumas das informações gerais que encontrei sugerem que a penalidade de desempenho pode ser bastante alta (acima de 60%) e outros dizem que é insignificante. O que eu quero fazer é determinar se o alinhamento da partição é um fator nos problemas de desempenho do servidor ou não; e se sim, em que grau?

Então, colocarei minhas informações aqui, e espero que a comunidade possa confirmar se minhas partições estão realmente desalinhadas e, em caso afirmativo, ajude-me a colocar um número no custo de desempenho.

O servidor é um Dell R510 com CPUs E5620 duplas e 8 GB de RAM. Há oito unidades de 15k de 2,5 ”e 600 GB (Seagate ST3600057SS) configuradas no hardware RAID-6 com um único hot spare. O controlador RAID é um Dell PERC H700 com cache de 512 MB (o Linux vê isso como um LSI MegaSAS 9260). OS é o CentOS 5.6, a partição de diretório inicial é ext3, com opções “rw, data = journal, usrquota”.

Eu tenho o HW RAID configurado para apresentar dois discos virtuais no sistema operacional: / dev / sda para o sistema operacional (boot, root e partições de troca), e / dev / sdb para um grande compartilhamento NFS:

[root@lnxutil1 ~]# parted -s /dev/sda unit s print

Model: DELL PERC H700 (scsi)
Disk /dev/sda: 134217599s
Sector size (logical/physical): 512B/512B
Partition Table: msdos

Number  Start    End         Size        Type     File system  Flags
 1      63s      465884s     465822s     primary  ext2         boot
 2      465885s  134207009s  133741125s  primary               lvm

[root@lnxutil1 ~]# parted -s /dev/sdb unit s print

Model: DELL PERC H700 (scsi)
Disk /dev/sdb: 5720768639s
Sector size (logical/physical): 512B/512B
Partition Table: gpt

Number  Start  End          Size         File system  Name  Flags
 1      34s    5720768606s  5720768573s                     lvm

Editar 1 Usando o planejador cfq IO (padrão para o CentOS 5.6):

# cat /sys/block/sd{a,b}/queue/scheduler
noop anticipatory deadline [cfq]
noop anticipatory deadline [cfq]

O tamanho do bloco é o mesmo que o tamanho da faixa, certo? Se sim, então 64kB :

# /opt/MegaCli -LDInfo -Lall -aALL -NoLog
Adapter #0

Number of Virtual Disks: 2
Virtual Disk: 0 (target id: 0)
Name:os
RAID Level: Primary-6, Secondary-0, RAID Level Qualifier-3
Size:65535MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default
Number of Spans: 1
Span: 0 - Number of PDs: 7

... physical disk info removed for brevity ...

Virtual Disk: 1 (target id: 1)
Name:share
RAID Level: Primary-6, Secondary-0, RAID Level Qualifier-3
Size:2793344MB
State: Optimal
Stripe Size: 64kB
Number Of Drives:7
Span Depth:1
Default Cache Policy: WriteBack, ReadAdaptive, Direct, No Write Cache if Bad BBU
Current Cache Policy: WriteThrough, ReadAdaptive, Direct, No Write Cache if Bad BBU
Access Policy: Read/Write
Disk Cache Policy: Disk's Default
Number of Spans: 1
Span: 0 - Number of PDs: 7

Se não for óbvio, o disco virtual 0 corresponde a / dev / sda, para o SO; O disco virtual 1 é / dev / sdb (a árvore de diretórios home exportada).

    

Answer 1

Suas partições estão desalinhadas e pode ser difícil avaliar o quanto você está realmente perdendo em desempenho porque isso dependeria do tipo de carga de trabalho de E / S. Pode ser insignificante se sua carga de trabalho de E / S for leve, em comparação com o desempenho de seus discos. No entanto, uma vez que este é um servidor NFS, estou assumindo que não é insignificante e deve ser abordado. Alguns estimativas colocam a penalidade de desempenho em 20-30%.

O desalinhamento de partição basicamente significa que você pode precisar de duas operações de E / S no nível de hardware para satisfazer uma operação de E / S no nível do software. Se os seus blocos de software não estiverem terminando no mesmo limite de hardware, isso acontecerá. Pelo que você escreveu, você já pesquisou e entendeu isso.

• Disco = setores de 512 bytes
• RAID = faixas de 65536 bytes (OK)
• Partição 0 = iniciando no setor 63 (deslocamento de 32256 bytes)
• Partição 1 = iniciando no setor 465885 (deslocamento de 238533120 bytes)
• Tamanho do bloco EXT2 / 3/4 =?
• Tamanho da passada EXT2 / 3/4 =? ( calculadora )

Lembre-se de que o desalinhamento de partição é diferente de ter seu subsistema de armazenamento usando tamanhos de bloco diferentes dos que o software está usando. Isso também poderia colocar mais pressão em seus discos, mas não está realmente relacionado a problemas de alinhamento.

Use tunefs -l /dev/sdaX | grep size para verificar o tamanho do bloco no seu sistema de arquivos.

De acordo com as recomendações do Red Hat Enterprise Linux:

Generally, it is a good idea to align the partitions to a multiple of one MB (1024x1024 bytes). To achieve alignment, start sectors of partitions should always be a multiple of 2048, and end sectors should always be a multiple of 2048, minus 1. Note that the first partition can not start at sector 0, use sector 2048 instead.

Parece que você está procurando migrar os dados e recriar suas partições, se essa for a causa raiz do problema de desempenho do NFS. No entanto, a coisa toda é geralmente mais complexa e eu tentaria encontrar evidências de que outras coisas estão OK antes de considerar uma reinstalação cara.