Por que a leitura do meu espelho lvm é mais lenta do que a leitura dos discos individuais?

Question

Estou medindo usando o hdparm -t nos PVs (sda3 e sdb2) e no LV (work). Na verdade, é mais rápido nos PVs.

Isso é realmente o jeito que o lvm é, ou estou fazendo algo errado?

# lvs -a -o +devices
LV              VG     Attr   LSize   Origin Snap%  Move Log       Copy%  Convert Devices                          
root            foobar -wi-ao 165.00G                                             /dev/sda3(10752)                 
swap            foobar -wi-ao   2.00G                                             /dev/sda3(10240)                 
work            foobar mwi-ao 148.52G                    work_mlog 100.00         work_mimage_0(0),work_mimage_1(0)
[work_mimage_0] foobar iwi-ao 148.52G                                             /dev/sda3(52992)                 
[work_mimage_1] foobar iwi-ao 148.52G                                             /dev/sdb2(0)                     
[work_mlog]     foobar lwi-ao   4.00M                                             /dev/sdb1(0)                     

    

Answer 1

Existe uma pequena sobrecarga extra para passar os dados pelas interfaces de dispositivos de blocos virtuais extras (no kernel). Geralmente é da ordem do ruído da linha (não mais do que cerca de 3%).

Se você deseja melhorar o desempenho de várias unidades, é necessário consultar os drivers md (metadisk) ... RAID 1 (espelhamento) ou RAID 10 (espelhamento + striping). Nesses casos, seu sistema pode ser capaz de intercalar leituras e gravações de várias unidades (eixos) simultaneamente. (Observe que existem algumas configurações de hardware das quais você não se beneficiará com o espelhamento; por exemplo, duas unidades suspensas em um cabo IDE / PATA simples; o único controlador / cabo é um gargalo).

Os dois principais fatores que afetam o desempenho geral da unidade são tempo de busca e taxa de transferência ... quanto tempo leva para posicionar a unidade sobre os dados solicitados e com que rapidez os dados podem ser transferidos pelo cabo. O espelhamento de dois canais de E / S, obviamente, melhora a taxa de transferência de leitura (potencialmente quase o dobro dos dados transferidos em qualquer intervalo dado). O efeito sobre o tempo de busca é dramático e mais probabilístico ... as cabeças nas duas unidades provavelmente estarão em diferentes partes de suas respectivas bandejas. A solicitação de leitura pode vir de qualquer unidade, portanto, a solicitação pode ser roteada para a unidade que, por acaso, tem suas cabeças mais próximas da área desejada. (Até onde eu sei, isso é feito apenas por uma heurística bruta no kernel do Linux ... os drivers não conhecem detalhes da geometria da unidade, mas simplesmente tratam os pedidos como deslocamentos em uma tabela "array linear de blocos"). / p>

Mais importante, uma configuração de RAID de espelhamento pode atender várias solicitações de leitura simultaneamente.

Observe que o espelhamento de RAID não oferece benefícios para gravações. Cada gravação deve ser feita em várias unidades ... assim, ela deve ser transferida para todos os canais de E / S do conjunto, e você sofre com o pior tempo de busca do conjunto (em vez de ganhar com a cabeça posicionada de maneira ideal no caso de lê).

Note que é possível usar os recursos LVM e md RAID juntos no Linux. Normalmente, você usaria os drivers md * como uma camada de bloco virtual mais baixa (agregando os discos físicos em conjuntos RAID) e depois usando o LVM sobre esses (tornando cada um de seus dispositivos de nível superior md * (1, 5 ou 6) em PVs do LVM --- volumes físicos). Para a maior parte, eu diria que o RAID 0 (striping) não faz sentido com o LVM. (O LVM pode agregar várias unidades em volumes virtuais maiores, da mesma forma que o RAID 0. No entanto, o faz de forma muito mais flexível).

    

Answer 2

Isso pode ser por vários motivos. Eu sei que certos sistemas de arquivos têm "copy-on-write", incluindo Ext3, ZFS, WAFL, VERITAS (NetBackup) e btrfs. No entanto, enquanto o COW (copy-on-write) pode atrasar o seu sistema, não deve ser algo facilmente perceptível.

Além disso, se você tiver instantâneos ativados (com qualquer controlador que você esteja usando para criar o LV), isso também os atrasaria.

Dependendo do tamanho das extensões físicas no volume, isso pode atrasá-lo (digamos, talvez, que cada unidade física tenha um volume total diferente). Ou talvez algo esteja acontecendo com um dos discos físicos individuais que compõem o seu LVM.

Tente fazer alguns diagnósticos nos próprios discos e veja se algum deles retorna setores / fatias defeituosos. Você está aumentando este volume lógico automaticamente ou este é um volume de tamanho fixo?

Poderia muito bem ser a maneira que o seu espelho LVM está configurado. O controlador, ou discos físicos, pode ter algo acontecendo. Você também tem que lembrar a velocidade no controlador, já que o caminho que os dados levam para atingir as unidades passa pelo controlador - ter um controlador mais antigo com HDs mais novos não acelera as coisas (dependendo do controlador mais antigo, eu tenho um que tem idades antigas e quase sempre supera alguns dos mais novos).

    

Answer 3

Um problema que tive em algum momento foi que, com volumes LVM, os valores padrão para o readahead máximo foram definidos para algo estupidamente baixo. IIRC que foi corrigido desde então, mas suponho que não vai doer para verificar. Por exemplo. o

blockdev --getra / dev / foo / bar

para ver a configuração de leitura antecipada do dispositivo e --setra N para configurá-lo para N setores. E você provavelmente deseja definir um readahead decente no dispositivo subjacente ou no volume LVM, não em ambos.

Além disso, para benchmarking "adequado", use algo como iozone, fio, bonnie ++ em vez de hdparm. O hdparm acessa as unidades diretamente, e não tenho certeza de que faça algo relevante ao executá-lo em um dispositivo virtual, como um LVM LVM.