{"id":95783,"date":"2020-10-03T13:42:02","date_gmt":"2020-10-03T11:42:02","guid":{"rendered":"https:\/\/prohoster.info\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs"},"modified":"2020-10-03T13:42:02","modified_gmt":"2020-10-03T11:42:02","slug":"nastrojka-yadra-linux-dlya-glusterfs","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/administrirovanie\/nastrojka-yadra-linux-dlya-glusterfs","title":{"rendered":"Configura\u00e7\u00e3o do kernel Linux para GlusterFS","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

A tradu\u00e7\u00e3o do artigo foi preparada em antecipa\u00e7\u00e3o ao in\u00edcio do curso \u00abAdministrador Linux. Profissional\u00bb<\/a><\/noindex>.<\/i><\/b><\/p>\n

\"Configura\u00e7\u00e3o<\/p>\n

Ocasionalmente, surgem perguntas sobre as recomenda\u00e7\u00f5es do Gluster em rela\u00e7\u00e3o \u00e0 configura\u00e7\u00e3o do kernel e se isso \u00e9 necess\u00e1rio.<\/p>\n

Essa necessidade \u00e9 rara. Na maioria das cargas de trabalho, o kernel funciona muito bem. No entanto, h\u00e1 um lado oposto. Historicamente, o kernel Linux tende a consumir muita mem\u00f3ria, se tiver a oportunidade, inclusive para cache como uma forma principal de aumentar o desempenho.<\/a><\/noindex><\/p>\n

Na maioria dos casos, isso funciona muito bem, mas sob alta carga pode causar problemas. <\/p>\n

Temos ampla experi\u00eancia com sistemas que consomem muita mem\u00f3ria, como CAD, EDA e similares, que come\u00e7am a desacelerar sob alta carga. E \u00e0s vezes encontramos problemas no Gluster. Observando cuidadosamente o uso de mem\u00f3ria e o tempo de espera dos discos, percebemos sobrecargas, altos iowait, erros de kernel (kernel oops), travamentos, etc. <\/p>\n

Este artigo \u00e9 o resultado de muitos experimentos na configura\u00e7\u00e3o de par\u00e2metros realizados em diversas situa\u00e7\u00f5es. Gra\u00e7as a esses par\u00e2metros, n\u00e3o apenas melhoramos a capacidade de resposta geral, mas tamb\u00e9m estabilizamos consideravelmente a opera\u00e7\u00e3o do cluster.<\/p>\n

Quando se trata de ajustar a mem\u00f3ria, a primeira coisa a observar \u00e9 o subsistema de mem\u00f3ria virtual (VM, virtual memory), que possui muitas op\u00e7\u00f5es que podem confundir.<\/p>\n

vm.swappiness<\/h4>\n

\nPar\u00e2metro vm.swappiness<\/code> determina o quanto o kernel utiliza o swap em compara\u00e7\u00e3o com a mem\u00f3ria RAM. No c\u00f3digo-fonte, \u00e9 tamb\u00e9m definido como \"tendency to steal mapped memory\" (tend\u00eancia a roubar mem\u00f3ria mapeada). Um valor alto de swappiness significa que o kernel ter\u00e1 maior propens\u00e3o a descarregar p\u00e1ginas mapeadas. Um valor baixo de swappiness significa o oposto: o kernel ir\u00e1 menos descarregar p\u00e1ginas da mem\u00f3ria. Em outras palavras, quanto maior o valor vm.swappiness<\/code>, mais o sistema usar\u00e1 swap.<\/p>\n

Um alto uso de swap \u00e9 indesej\u00e1vel, pois enormes blocos de dados s\u00e3o carregados e descarregados da mem\u00f3ria RAM. Muitas pessoas afirmam que o valor de swappiness deve ser alto, mas pela minha experi\u00eancia, a configura\u00e7\u00e3o em \"0\" leva a um aumento de desempenho.<\/p>\n

Voc\u00ea pode ler mais aqui \u2014 lwn.net\/Articles\/100978<\/a><\/noindex> <\/p>\n

No entanto, novamente, essas configura\u00e7\u00f5es devem ser aplicadas com cautela e apenas ap\u00f3s testar a aplica\u00e7\u00e3o espec\u00edfica. Para aplica\u00e7\u00f5es de streaming com alta carga, esse par\u00e2metro deve ser definido como \"0\". Alterar para \"0\" melhora a responsividade do sistema.<\/p>\n

vm.vfs_cache_pressure<\/h4>\n

\nEsse par\u00e2metro controla a mem\u00f3ria consumida pelo n\u00facleo para o cache de objetos de diret\u00f3rio e descritores de \u00edndice (dentry e inode).<\/p>\n

Com o valor padr\u00e3o de 100, o n\u00facleo tentar\u00e1 liberar o cache dentry e inode com \"justi\u00e7a\" em rela\u00e7\u00e3o ao pagecache e swapcache. Reduzir o vfs_cache_pressure faz com que o n\u00facleo mantenha os caches dentry e inode. Quando o valor \u00e9 \"0\", o n\u00facleo nunca limpar\u00e1 o cache dentry e inode devido \u00e0 falta de mem\u00f3ria (memory pressure), o que pode facilmente levar a um erro de esgotamento de mem\u00f3ria. Aumentar o vfs_cache_pressure para mais de 100 faz com que o n\u00facleo priorize a descarga de dentry e inode.<\/p>\n

Ao usar GlusterFS, muitos usu\u00e1rios com grandes volumes de dados e muitos arquivos pequenos podem facilmente consumir uma quantidade significativa de mem\u00f3ria no servidor devido ao cache de inode\/dentry, o que pode resultar em diminui\u00e7\u00e3o do desempenho, j\u00e1 que o n\u00facleo precisa processar estruturas de dados em um sistema com 40 GB de mem\u00f3ria. Configurar esse par\u00e2metro para mais de 100 ajudou muitos usu\u00e1rios a conseguir um cache mais justo e melhorar a responsividade do n\u00facleo.<\/p>\n

vm.dirty_background_ratio e vm.dirty_ratio<\/h4>\n

\nO primeiro par\u00e2metro (vm.dirty_background_ratio<\/code>) define a porcentagem de mem\u00f3ria com p\u00e1ginas sujas, ao alcan\u00e7ar a qual \u00e9 necess\u00e1rio iniciar o descarregamento em segundo plano de p\u00e1ginas sujas no disco. Enquanto essa porcentagem n\u00e3o for alcan\u00e7ada, as p\u00e1ginas n\u00e3o s\u00e3o descarregadas no disco. E quando o descarregamento come\u00e7a, ele \u00e9 realizado em segundo plano, sem interromper os processos em execu\u00e7\u00e3o. <\/p>\n

O segundo par\u00e2metro (vm.dirty_ratio<\/code>) determina a porcentagem de mem\u00f3ria que pode ser ocupada por p\u00e1ginas sujas antes do in\u00edcio da limpeza for\u00e7ada (forced flash). Ao atingir esse limite, todos os processos se tornam s\u00edncronos (s\u00e3o bloqueados) e n\u00e3o podem continuar a execu\u00e7\u00e3o at\u00e9 que a opera\u00e7\u00e3o de entrada e sa\u00edda solicitada seja realmente conclu\u00edda e os dados sejam gravados no disco. Em situa\u00e7\u00f5es de alta carga de entrada e sa\u00edda, isso causa problemas, pois n\u00e3o h\u00e1 cache de dados, e todos os processos que realizam entrada e sa\u00edda ficam bloqueados aguardando a I\/O. Isso resulta em um grande n\u00famero de processos travados, alta carga, opera\u00e7\u00e3o inst\u00e1vel do sistema e baixo desempenho.<\/p>\n

A redu\u00e7\u00e3o dos valores desses par\u00e2metros faz com que os dados sejam despejados no disco com mais frequ\u00eancia e n\u00e3o permane\u00e7am na RAM. Isso pode ajudar sistemas com muita mem\u00f3ria, onde \u00e9 normal despejar em disco um cache de p\u00e1ginas de 45 a 90 GB, resultando em um enorme tempo de espera para aplica\u00e7\u00f5es frontend, diminuindo a responsividade e interatividade geral.<\/p>\n

\u00ab1\u00bb > \/proc\/sys\/vm\/pagecache<\/h4>\n

\nO cache de p\u00e1ginas (page cache) \u00e9 um cache onde s\u00e3o armazenados os dados de arquivos e programas execut\u00e1veis, ou seja, s\u00e3o p\u00e1ginas com o conte\u00fado real dos arquivos ou dispositivos de bloco. Esse cache \u00e9 usado para reduzir a quantidade de leituras do disco. O valor \u00ab1\u00bb significa que 1% da RAM \u00e9 usado para o cache e haver\u00e1 mais opera\u00e7\u00f5es de leitura do disco do que da RAM. N\u00e3o \u00e9 necess\u00e1rio alterar este par\u00e2metro, mas se voc\u00ea for paranoico quanto ao controle do cache de p\u00e1ginas, pode utiliz\u00e1-lo.<\/p>\n

\u00abdeadline\u00bb > \/sys\/block\/sdc\/queue\/scheduler<\/h4>\n

\nO planejador de I\/O (I\/O scheduler) \u00e9 um componente do n\u00facleo do Linux que gerencia as filas de leitura e escrita. Teoricamente, para um controlador RAID inteligente, \u00e9 melhor usar \u00abnoop\u00bb, pois o Linux n\u00e3o sabe nada sobre a geometria f\u00edsica do disco, ent\u00e3o \u00e9 mais eficiente deixar o controlador, que conhece bem a geometria do disco, processar o pedido o mais r\u00e1pido poss\u00edvel. Mas parece que \u00abdeadline\u00bb melhora o desempenho. Voc\u00ea pode ler mais sobre os planejadores na documenta\u00e7\u00e3o do c\u00f3digo fonte do n\u00facleo do Linux: linux\/Documentation\/block\/*osched.txt<\/code>. E tamb\u00e9m observei um aumento na largura de banda de leitura durante opera\u00e7\u00f5es mistas (muitas opera\u00e7\u00f5es de grava\u00e7\u00e3o).<\/p>\n

\u00ab256\u00bb > \/sys\/block\/sdc\/queue\/nr_requests<\/h4>\n

\nO n\u00famero de solicita\u00e7\u00f5es de entrada e sa\u00edda no buffer antes de serem enviadas para o planejador. O tamanho da fila interna de alguns controladores (queue_depth) \u00e9 maior do que nr_requests do planejador de E\/S, de modo que o planejador de E\/S tem poucas chances de priorizar corretamente e realizar a mesclagem de solicita\u00e7\u00f5es. Para os planejadores deadline e CFQ, \u00e9 melhor que nr_requests seja duas vezes maior que a fila interna do controlador. A mesclagem e a reorganiza\u00e7\u00e3o de solicita\u00e7\u00f5es ajudam o planejador a ser mais responsivo sob alta carga.<\/p>\n

echo \"16\" > \/proc\/sys\/vm\/page-cluster<\/h4>\n

\nO par\u00e2metro page-cluster controla o n\u00famero de p\u00e1ginas escritas no swap de uma vez. No exemplo acima, o valor \u00e9 definido como \"16\" de acordo com o tamanho do stripe (stripe size) RAID de 64 KB. Isso n\u00e3o faz sentido com swappiness = 0, mas se voc\u00ea definiu swappiness como 10 ou 20, o uso desse valor pode ajud\u00e1-lo quando o tamanho do stripe RAID \u00e9 64 KB.<\/p>\n

blockdev \u2014setra 4096 \/dev\/<<\/code>devname><\/code> (-sdb, hdc ou dev_mapper)<\/h4>\n

\nAs configura\u00e7\u00f5es padr\u00e3o dos dispositivos de bloco para muitos controladores RAID frequentemente resultam em um desempenho terr\u00edvel. A adi\u00e7\u00e3o da op\u00e7\u00e3o acima configura a leitura antecipada para 4096 * 512 bytes setores. Pelo menos para opera\u00e7\u00f5es sequenciais, a velocidade aumenta, preenchendo o cache embutido do disco por meio da leitura antecipada durante o per\u00edodo que o n\u00facleo utiliza para preparar a E\/S. Os dados que ser\u00e3o solicitados na pr\u00f3xima leitura podem ser armazenados no cache. Leituras antecipadas excessivas podem prejudicar a E\/S aleat\u00f3ria para arquivos grandes, se utilizar potencialmente tempo \u00fatil do disco ou carregar dados para al\u00e9m do cache.<\/p>\n

Aqui est\u00e3o mais algumas recomenda\u00e7\u00f5es a n\u00edvel de sistema de arquivos. Mas elas ainda n\u00e3o foram testadas. Certifique-se de que seu sistema de arquivos conhe\u00e7a o tamanho do stripe e o n\u00famero de discos na matriz. Por exemplo, que esta \u00e9 uma matriz raid5 com um tamanho de stripe de 64K de seis discos (na verdade cinco, pois um disco \u00e9 utilizado para paridade). Essas recomenda\u00e7\u00f5es s\u00e3o baseadas em suposi\u00e7\u00f5es te\u00f3ricas e coletadas de v\u00e1rios blogs\/artigos de especialistas em RAID.<\/p>\n

-> ext4 fs, 5 discos, stripe de 64K, unidades em blocos de 4K\nmkfs -text4 -E stride=$((64\/4))\n-> xfs, 5 discos, stripe de 64K, unidades em setores de 512 bytes\nmkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))<\/code><\/pre>\n
\nPara arquivos grandes, pode-se considerar aumentar os tamanhos de stripe mencionados acima.<\/p>\n
ATEN\u00c7\u00c3O!<\/b> Tudo o que foi descrito acima \u00e9 extremamente subjetivo para certos tipos de aplicativos. Este artigo n\u00e3o garante melhorias sem testes pr\u00e9vios dos aplicativos relevantes por parte do usu\u00e1rio. Deve ser aplicado somente se necess\u00e1rio para melhorar a responsividade geral do sistema ou se resolver problemas atuais.<\/p>\n
Materiais adicionais:<\/h4>\n
<\/p>\n