Início / server / Perguntas / 660575
Accepted
Halfgaar
Asked: 2015-01-20 01:52:01 +0800 CST

Qual agendador mudar no LVM para beneficiar as máquinas virtuais

  • 772

Quando você tem LVM, você tem uma entrada para um agendador /sys/blockpara seus volumes físicos, mas também para cada volume lógico individual e o dispositivo bruto.

Temos um sistema Debian 6 LTS x64, kernel 2.6.32 rodando Xen hypervisor 4.0 (3Ware 9650 SE hardware RAID1). Ao executar máquinas virtuais em cada volume lógico, em qual delas você precisa definir o agendador se quiser influenciar como elas são agendadas pelo sistema operacional? Se você definir o volume lógico como deadline, isso fará alguma coisa quando o volume físico estiver definido como cfq? E se você definir o prazo final no volume lógico, esses prazos serão honrados mesmo quando o disco estiver lento devido a E/S em outros LVs definidos como cfq?

A pergunta está relacionada a E/S em VMs que desaceleram demais as outras VMs. Todos os convidados usam o noop como agendador internamente.

Edit: de acordo com isso , em um ambiente multipath, apenas o agendador do DM entrará em vigor. Portanto, se eu quiser lidar com o IO entre as máquinas virtuais de uma deadlinemaneira, tenho que definir o caminho DM do volume físico (dm-1 no meu caso) como deadline. Isso está certo? Há também um agendador para sdc, que é o dispositivo de bloco original do meu dm-1. Por que não deveria ser feito nisso?

edit2: mas alguém diz nos comentários que dm-0/1 não possui um agendador em kernels mais recentes:

famzah@VBox:~$ cat /sys/block/dm-0/queue/scheduler
none

No meu sistema (Debian 6, kernel 2.6.32), tenho:

cat /sys/block/dm-1/queue/scheduler 
noop anticipatory [deadline] cfq

A pergunta também é: eu tenho uma configuração de caminhos múltiplos? pvsmostra:

# pvs
PV         VG                 Fmt  Attr PSize PFree
/dev/dm-0  universe           lvm2 a-   5,41t 3,98t
/dev/dm-1  alternate-universe lvm2 a-   1,82t 1,18t

Mas eles foram criados com /dev/sd[bc]. Isso significa que tenho multipath, mesmo que seja uma configuração LVM padrão?

A questão principal, eu acho, é se devo definir o agendador em sdc ou dm-1? Se eu fizer iostat, vejo muito acesso em ambos:

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdc               0,00     0,00   13,02   25,36   902,71   735,56    42,68     0,08    2,17   0,73   2,79
dm-1             82,25    57,26   12,97   25,36   902,31   735,56    42,72     0,18    4,73   0,84   3,23

Então, o que é o quê e quem é o chefe? Se for sdc, posso dizer que defini-lo como deadline não afeta o desempenho de minhas VMs. Olhando para a diferença nas colunas 'requests merged' (as duas primeiras), eu diria que é dm-1 que controla o agendamento.

linux

3 respostas

  1. Best Answer

    Portanto, a resposta acabou sendo simples: o dispositivo subjacente. Os kernels mais novos só têm 'none' /sys/block/*/queue/schedulerquando não há agendador para configurar.

    No entanto, por um motivo desconhecido para mim, os dispositivos neste servidor são criados como dispositivos de caminhos múltiplos, portanto, minha manipulação do agendador /dev/sd[bc]nunca fez nada no passado. Agora eu defino dm-1e dm-0para o prazo com um read_expire=100e write_expire=1500(muito mais rigoroso que o normal) e os resultados parecem muito bons.

    Este gráfico mostra o efeito na latência do disco em uma máquina virtual, causado por outra máquina virtual com uma tarefa por hora:

    Latência de disco superior a 24h em ms

    Você pode ver claramente o momento em que alterei os parâmetros do agendador.

    • 2

  2. Hum, Debian...

    Bem, posso compartilhar como a Redhat aborda isso com sua estrutura ajustada . Existem perfis para "host virtual" e "convidado virtual". As descrições do perfil são explicadas em detalhes aqui e o trecho a seguir mostra quais dispositivos são afetados. Os dispositivos "dm-*" e "sdX" tiveram seus agendadores alterados.

    # This is the I/O scheduler ktune will use.  This will *not* override anything
# explicitly set on the kernel command line, nor will it change the scheduler
# for any block device that is using a non-default scheduler when ktune starts.
# You should probably leave this on "deadline", but "as", "cfq", and "noop" are
# also legal values.  Comment this out to prevent ktune from changing I/O
# scheduler settings. 
ELEVATOR="deadline"

# These are the devices, that should be tuned with the ELEVATOR 
ELEVATOR_TUNE_DEVS="/sys/block/{sd,cciss,dm-,vd,zd}*/queue/scheduler"

    Veja também:
    CentOS Tuned Equivalent For Debian e Entendendo os perfis ajustados recomendados pelo RedHat

    • 1

  3. como o vmware recomenda, é melhor usar o agendador noop, se seu convidado estiver usando arquivo como disco virtual, dessa forma seu convidado passará o IO para seu host diretamente sem reorganizar o IO duas vezes em seu convidado e em seu host físico

    • 0

relate perguntas