Uso e desempenho do Ext4

Eu tenho um cluster de máquinas executando Carbon e Graphite que preciso escalar para obter mais armazenamento, mas não tenho certeza se preciso escalar ou reduzir.

O cluster atualmente é composto por:

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

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 13k quase constantes para uma média mais caótica de cerca de 7k e o tempo de espera em média é de 54%.

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

Pergunta: Aumentar o tamanho do disco trará o desempenho de E / S de volta ao controle ou preciso adicionar mais nós de armazenamento?

Nota: Não há SSDs aqui, apenas muitos e muitos eixos.

Gráficos Relevantes:

Estatísticas e outras coisas:

e2freefrag:

[root@graphite-storage-01 ~]# e2freefrag /dev/vda3
Device: /dev/vda3
Blocksize: 4096 bytes
Total blocks: 9961176
Free blocks: 4781849 (48.0%)

Min. free extent: 4 KB
Max. free extent: 81308 KB
Avg. free extent: 284 KB
Num. free extent: 19071

HISTOGRAM OF FREE EXTENT SIZES:
Extent Size Range :  Free extents   Free Blocks  Percent
    4K...    8K-  :          4008          4008    0.08%
    8K...   16K-  :          1723          3992    0.08%
   16K...   32K-  :           703          3495    0.07%
   32K...   64K-  :           637          7400    0.15%
   64K...  128K-  :          1590         29273    0.61%
  128K...  256K-  :          4711        236839    4.95%
  256K...  512K-  :          2664        265691    5.56%
  512K... 1024K-  :          2359        434427    9.08%
    1M...    2M-  :           595        213173    4.46%
    2M...    4M-  :            75         49182    1.03%
   64M...  128M-  :             6        118890    2.49%

e4defrag:

[root@graphite-storage-01 ~]# e4defrag -c /dev/vda3
<Fragmented files>                             now/best       size/ext
1. /opt/graphite/storage/graphite.db            17/1              4 KB
2. /var/log/cron                                13/1              4 KB
3. /var/log/wtmp                                16/1              4 KB
4. /root/.bash_history                           4/1              4 KB
5. /var/lib/rpm/Sha1header                      10/1              4 KB

 Total/best extents                             182256/159981
 Average size per extent                        183 KB
 Fragmentation score                            2
 [0-30 no problem: 31-55 a little bit fragmented: 56- needs defrag]
 This device (/dev/vda3) does not need defragmentation.
 Done.

iostat:

[root@graphite-storage-01 ~]# iostat -k -x 60 3
Linux 3.10.0-229.7.2.el7.x86_64 (graphite-storage-01)     07/05/2016      _x86_64_        (2 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.99    0.00    2.54   29.66    0.35   59.46

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00   100.34  177.48 1808.94  2715.66  7659.19    10.45     0.26    0.13    0.65    0.08   0.23  46.14

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           6.17    0.00    7.00   73.21    0.58   13.04

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    23.87  672.40  656.47  8729.87  2752.27    17.28     7.36    5.50    2.72    8.35   0.73  96.83

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
           7.06    0.00    7.31   73.03    0.59   12.01

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util
vda               0.00    42.68  677.67  614.88  8634.93  2647.53    17.46     6.66    5.15    2.72    7.83   0.74  96.08

df:

[root@graphite-storage-01 ~]# df
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/vda3       39153856 33689468   3822852  90% /
devtmpfs         1933092        0   1933092   0% /dev
tmpfs            1941380        0   1941380   0% /dev/shm
tmpfs            1941380   188700   1752680  10% /run
tmpfs            1941380        0   1941380   0% /sys/fs/cgroup
/dev/vda2         999320     2584    980352   1% /tmp
[root@graphite-storage-01 ~]# df -i
Filesystem      Inodes  IUsed   IFree IUse% Mounted on
/dev/vda3      2490368 239389 2250979   10% /
devtmpfs        483273    304  482969    1% /dev
tmpfs           485345      1  485344    1% /dev/shm
tmpfs           485345    322  485023    1% /run
tmpfs           485345     13  485332    1% /sys/fs/cgroup
/dev/vda2        65536     22   65514    1% /tmp

Editar: redimensionei um dos nós de armazenamento, mas não teve efeito. Eu também encontrei o cachestatutilitário em [ https://github.com/brendangregg/perf-toolsingerie (uma coleção de ferramentas perf) que me deu uma olhada no cache do VFS. Neste ponto, parece que eu atingi o limite de taxa de transferência de IO que meu armazenamento pode fornecer.

Neste ponto, acho que terei que continuar a expandir para mais membros de cluster ou procurar encontrar uma solução de armazenamento em série temporal mais eficiente para 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

Edição super tardia: desde então, migramos para outra plataforma onde os SSDs estão disponíveis e, embora as coisas estivessem boas por algum tempo, acabamos vendo o mesmo declínio acentuado no desempenho, à medida que adicionamos cada vez mais métricas. Embora eu não tenha nenhuma prova definitiva, acredito que esse seja um caso interessante entre o funcionamento do armazenamento Carbon / Whisper e o grande número de métricas que armazenamos.

Basicamente, desde que o sistema tenha RAM suficiente para armazenar em cache confortavelmente os arquivos Whisper para leituras, a E / S é quase pura e tudo fica feliz. No entanto, uma vez que a inanição do cache FS é iniciada e os arquivos Whisper precisam ser lidos continuamente em um disco que consome a largura de banda da sua IO e tudo começa a dar errado.

Parece que você está executando SSDs, que podem ter algumas características de desempenho descoladas à 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 anular pedaços de flash escritos, mas atualmente não utilizados, antes que possam ser gravados novamente. Parece que você está escrevendo bastante, portanto o processo de apagamento em execução na unidade não tem chance de manter um suprimento suficiente de pedaços em branco depois que todos são gravados uma vez.

Diferentes modelos de unidades têm controladores diferentes e quantidades diferentes de blocos flash "sobressalentes" para usar, e unidades maiores obviamente têm mais blocos para escrever antes de ficarem sem novos bits, por isso é quase certo que a atualização para unidades maiores "resolveria" o problema para você, pelo menos temporariamente. As unidades "corporativas" tendem a se sair melhor nesse aspecto, assim como os modelos mais recentes de controlador flash, por isso é um pouco de crapshoot, na ausência de testes confiáveis ​​de terceiros de um determinado modelo de unidade em um padrão de uso semelhante a seu próprio.

Você também pode se safar do uso das unidades que possui agora por mais algum tempo, se você fstrimpassar algo parecido com elas para dizer à unidade "você pode definitivamente limpar todos esses blocos agora ", embora faça isso em um sistema você precisa fazer outras coisas ao mesmo tempo e pode não cair tão bem (você deve observar bem os avisos de desempenho na página de fstrimmanual).

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 duvido que você esteja saturando o sistema de E / S em outro lugar.

Sabe-se que o Ext3 / 4 sofre, do ponto de vista de 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 duas iostat -k -x 60 3saídas, uma com menos de 80% da capacidade e outra com mais de 80%?

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

De qualquer forma, seus iostatresultados, combinados com seus gráficos (especialmente "IOPS de disco"), são bastante interessantes. Parece que sua carga de trabalho é muito centrada na gravação; quando> 95% do total de IOPS emitidos são gravados, você não tem problemas. No entanto, quando seu desempenho diminui, seus discos começam a exibir um IOPS consistente de leitura. Essa leitura / gravação misturada interrompe 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 primeiro resultado mostrado por iostat: quando o total de IOPS do disco é dominado por gravações (como neste caso), você avgqu-sze awaitambos são muito baixos.

Mas, na segunda e na terceira iostat, vemos muitas outras leituras que, sendo operações de bloqueio / paralisação (consulte a rrqm/scoluna: mostra 0, para que nenhuma leitura possa ser mesclada no seu caso), interrompem a latência ( await) e a taxa de transferência (KB / s) .

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