Uso e desempenho de Ext4

Question

Eu tenho um cluster de máquinas executando o Carbon e o Graphite que preciso dimensionar para mais armazenamento, mas não tenho certeza se preciso aumentar ou diminuir a escala.

O cluster é atualmente composto por:

• 1 Nó de retransmissão: recebe todas as métricas e encaminhamentos para o nó de armazenamento relevante
• 6 Nós de armazenamento: hospeda todos os arquivos do banco de dados Whisper

O problema é que parece que quando os discos chegaram a 80% de uso, o desempenho caiu de um penhasco. As IOPS de gravação em cluster caíram de uma constante quase 13k para uma média mais caótica de cerca de 7k e as médias de tempo de espera de 54%.

Eu dei uma olhada no nosso repositório de configuração e não há alterações desde o início de abril, então isso não é o resultado de uma alteração de configuração.

Pergunta: O aumento do tamanho do disco aumentará o controle do desempenho de E / S ou precisaremos adicionar mais nós de armazenamento?

Observação: não há SSDs aqui, apenas muitos e muitos fusos.

Gráficos relevantes:

Estatísticasematerial:

e2freefrag:

[root@graphite-storage-01~]#e2freefrag/dev/vda3Device:/dev/vda3Blocksize:4096bytesTotalblocks:9961176Freeblocks:4781849(48.0%)Min.freeextent:4KBMax.freeextent:81308KBAvg.freeextent:284KBNum.freeextent:19071HISTOGRAMOFFREEEXTENTSIZES:ExtentSizeRange:FreeextentsFreeBlocksPercent4K...8K-:400840080.08%8K...16K-:172339920.08%16K...32K-:70334950.07%32K...64K-:63774000.15%64K...128K-:1590292730.61%128K...256K-:47112368394.95%256K...512K-:26642656915.56%512K...1024K-:23594344279.08%1M...2M-:5952131734.46%2M...4M-:75491821.03%64M...128M-:61188902.49%

e4defrag:

[root@graphite-storage-01~]#e4defrag-c/dev/vda3<Fragmentedfiles>now/bestsize/ext1./opt/graphite/storage/graphite.db17/14KB2./var/log/cron13/14KB3./var/log/wtmp16/14KB4./root/.bash_history4/14KB5./var/lib/rpm/Sha1header10/14KBTotal/bestextents182256/159981Averagesizeperextent183KBFragmentationscore2[0-30noproblem:31-55alittlebitfragmented:56-needsdefrag]Thisdevice(/dev/vda3)doesnotneeddefragmentation.Done.

iostat:

[root@graphite-storage-01~]#iostat-k-x603Linux3.10.0-229.7.2.el7.x86_64(graphite-storage-01)07/05/2016_x86_64_(2CPU)avg-cpu:%user%nice%system%iowait%steal%idle7.990.002.5429.660.3559.46Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilvda0.00100.34177.481808.942715.667659.1910.450.260.130.650.080.2346.14avg-cpu:%user%nice%system%iowait%steal%idle6.170.007.0073.210.5813.04Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilvda0.0023.87672.40656.478729.872752.2717.287.365.502.728.350.7396.83avg-cpu:%user%nice%system%iowait%steal%idle7.060.007.3173.030.5912.01Device:rrqm/swrqm/sr/sw/srkB/swkB/savgrq-szavgqu-szawaitr_awaitw_awaitsvctm%utilvda0.0042.68677.67614.888634.932647.5317.466.665.152.727.830.7496.08

df:

[root@graphite-storage-01~]#dfFilesystem1K-blocksUsedAvailableUse%Mountedon/dev/vda33915385633689468382285290%/devtmpfs1933092019330920%/devtmpfs1941380019413800%/dev/shmtmpfs1941380188700175268010%/runtmpfs1941380019413800%/sys/fs/cgroup/dev/vda299932025849803521%/tmp[root@graphite-storage-01~]#df-iFilesystemInodesIUsedIFreeIUse%Mountedon/dev/vda32490368239389225097910%/devtmpfs4832733044829691%/devtmpfs48534514853441%/dev/shmtmpfs4853453224850231%/runtmpfs485345134853321%/sys/fs/cgroup/dev/vda26553622655141%/tmp

Editar:redimensioneiumdosnósdearmazenamento,masnãoteveefeito.Eutambémencontreioutilitáriocachestatno[ link coleção de ferramentas perf) que me deu um olhe dentro do cache do VFS. Neste ponto, parece que cheguei ao limite da taxa de transferência de E / S que meu armazenamento pode fornecer.

Neste ponto, acho que vou ter que continuar a escalar para mais membros de cluster ou ver uma solução de armazenamento de séries temporais mais eficiente em termos de gravação.

Exemplo de saída de cachestat :

storage-01 [resized disk]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    9691    14566     7821    40.0%          160       2628
   36181    14689     7802    71.1%          160       2631
    8649    13617     7003    38.8%          159       2628
   15567    13399     6857    53.7%          160       2627
    9045    14002     7049    39.2%          160       2627
    7533    12503     6153    37.6%          159       2620

storage-02 [not resized]
    HITS   MISSES  DIRTIES    RATIO   BUFFERS_MB   CACHE_MB
    5097    11629     4740    30.5%          143       2365
    5977    11045     4843    35.1%          142       2344
    4356    10479     4199    29.4%          143       2364
    6611    11188     4946    37.1%          143       2348
   33734    14511     5930    69.9%          143       2347
    7885    16353     7090    32.5%          143       2358

Super Late Edit: Desde então, migramos para outra plataforma onde os SSDs estão disponíveis e, enquanto as coisas estavam boas há algum tempo, vimos o mesmo declínio acentuado no desempenho quando adicionamos mais e mais métricas. Embora eu não tenha nenhuma prova definitiva, acredito que este seja um caso crucial entre o modo como o armazenamento do Carbon / Whisper funciona e o grande número de métricas que armazenamos.

Basicamente, desde que o sistema tenha RAM suficiente para armazenar confortavelmente os arquivos do Whisper para leituras, o IO é quase puro e tudo fica feliz. No entanto, uma vez que o cache de FS desmorona e os arquivos Whisper precisam ser lidos continuamente no disco que entra na sua largura de banda de IO e tudo começa a ir para o pote.

    

Answer 1

Parece que você está executando SSDs, que podem ter algumas características de desempenho interessantes à medida que ficam cheias. O fato de que quando o uso caiu em torno de 6/1, o desempenho não voltou ao normal, reforça essa teoria.

A razão por trás disso é bastante complicada, mas basicamente se resume à necessidade de apagar trechos de flash gravados, mas atualmente não usados, antes de poder ser gravada novamente. Parece que você está escrevendo muito difícil, então o processo de apagamento em execução na unidade não tem a chance de manter um suprimento suficiente de blocos em branco, uma vez que todos eles foram gravados uma vez.

Diferentes modelos de drive têm controladores diferentes, e diferentes quantidades de partes flash "sobressalentes" para serem usadas, e unidades maiores obviamente têm mais partes para escrever antes de ficarem sem bits, então é quase certo que atualizar para drives maiores "resolver" o problema para você, pelo menos temporariamente. As unidades de classe "Enterprise" tendem a melhorar nesse aspecto, mas também os modelos mais novos de controlador flash, portanto, é um pouco difícil, na ausência de testes confiáveis de terceiros de um modelo de unidade particular em um padrão de uso semelhante ao você mesmo.

Você também pode usar as unidades que tem agora por mais algum tempo, se você acenar algo como fstrim sobre elas para informar a unidade "você pode definitivamente limpar todos esses blocos corretamente now ", embora fazê-lo em um sistema em que você precisa estar fazendo outras coisas ao mesmo tempo pode não cair tão bem (você desejará observar bem os avisos de desempenho na% man_de% manpage).

Para saber se você precisa de mais nós, não posso dizer com certeza, mas acho que não. A CPU não parece fora de controle, e eu duvido que você esteja saturando o sistema de E / S em outro lugar.

    

Answer 2

Ext3 / 4 são bem conhecidos por sofrer, do ponto de vista do desempenho, com utilização acima de 80-85%. Isso ocorre devido ao aumento da fragmentação e ao desempenho reduzido de write-back.

Você pode fornecer dois iostat -k -x 60 3 de saída, um com menos de 80% da capacidade e outro com mais de 80%?

EDITAR: do seu e2freefrag , parece que /dev/vda3 tem muito espaço livre. Você pode adicionar a saída de df e df -i ?

De qualquer forma, seus resultados iostat , combinados com seus gráficos (especialmente "IOPS de disco"), são bastante interessantes. Parece que sua carga de trabalho é muito centrada em gravação; quando > 95% do total de IOPS emitidas são gravadas, você não tem problemas. No entanto, quando seu desempenho diminui, seus discos começam a exibir uma IOPS de leitura consistente. Essas leituras / gravações intermisturadas interrompem a capacidade dos discos de combinar várias gravações menores em gravações maiores (as leituras geralmente são operações de bloqueio), levando a um desempenho muito mais lento.

Por exemplo, vamos ver o resultado dos punhos mostrado por iostat : quando o total de IOPS do disco for dominado por gravações (como neste caso), seus avgqu-sz e await são muito baixos.

Mas no segundo e terceiro iostat , vemos muitas mais leituras que, sendo operações de bloqueio / bloqueio (veja a coluna rrqm/s : mostra 0, portanto nenhuma leitura pode ser mesclada no seu caso), interrompe a latência ( await ) e taxa de transferência (KB / s).

Eu vi um comportamento semelhante quando o host ficou sem cache de inode, talvez devido ao grande número de arquivos pequenos armazenados. Para ajustar seu sistema para preferir o cache inode / dentry às custas do cache de dados, tente emitir echo 10 > /proc/sys/vm/vfs_cache_pressure e espere alguns minutos: ele muda alguma coisa?