O estranho caso do ZFS consumir muita CPU

O estranho caso do ZFS consumir muita CPU
O estranho caso do ZFS consumir muita CPU

 Por mais que muitos pintam a imagem do ZFS como um sistema de arquivos indestrutível, ele também possui suas ventagens e desvantagens (como tudo no mundo, lei natural). Eu já abordei esse assunto em uma série do meu canal chamado ZFS vs Btrfs. Quem vence essa batalha.
 E por mais que seus defensores não consigam admitir, o ZFS também possui seus defeitos. Dois deles já foram mencionados aqui sendo o um o seu alto consumo de RAM e o outros o grande problema com de fragmentação.
 No dia seis de Setembro, Brendan Gregg relatou em seu blog um problema muito estranho que ocorre com o ZFS. Uma equipe de microsserviços o contatou apresentando o caso em que o ZFS estava consumindo sozinho 30% da capacidade de CPU. E por que exatamente a Brendan Gregg? Para quem não o conhece, Brendan Gregg já foi representante senior Solaris na Netflix, engenheiro de kernel, já foi desenvolvedor do Solaris onde ficou conhecido na área de performance concentrando seus esforços na primeira nuvem baseada em container do mundo e no primeiro dispositivo de armazenamento ZFS no mundo.

 Brendan ainda é engenheiro senior de performance na Netflix voltando seus esforços para o Solaris, Linux e FreeBSD e ainda mantem seus trabalhos voltados ao ZFS sendo o desenvolvedor do ZFS L2ARC e de várias outras ferramentas que geraram economia mundial de US$1bilhão (além de suas ferramentas terem dado origem a várias startups). Brendan é também internacionalmente conhecido como expert em performance na área de computação sendo desenvolvedor de várias ferramentas de analise para tal fim, 
gwhiz
gwhiz, uma das ferramentas desenvolvidas por Brendan Gregg em perl que eu gosto.
 
 Mas voltando ao caso do ZFS, esse é um caso que Brendan já apresentou em 2017 na kernel recipes e sua primeira ideia foi algum engano que cometeram durante a configuração:
"Eu trabalhei nos componentes internos do ZFS na Sun Microsystems e, a menos que esteja mal configurado, não há como consumir tanta CPU."
 Foi aí que começou toda a surpresa. Brendan começou utilizando uma ferramenta da Netflix de monitoramento e nuvem chamada Atlas e de cara o ZFS estava consumindo 38% de CPU; algo muito incomum nada carga de trabalho na nuvem da Netflix. Depois de outras analises com outras ferramentas como o Vector e supos através disso que o problema estava relacionado a containers. O que para a surpresa de todos é que eles não estava utilizando containers e nem o ZFS...

Ferramenta Vector da Netflix
Ferramenta Vector da Netflix

 Brendan então começou a debugar o sistema com comandos do sistema mesmo como df -h, mount e zfs list e estranhamente e ZFS não estava montado. Brendan então deduziu que containers poderiam ter sido criados anteriormente e destruídos; então Brendan decidiu analisar os arcstats que são contadores do kernel que rastreiam estatísticas do ZFS e o resultado foi que os contadores estavam zerados, o ZFS não estava montado e mesmo assim o ZFS estava consumindo 30% de CPU.

arcstats do ZFS
arcstats do ZFS

 Foi aí que Brendan decidiu olha o flame graph do Vector mais de perto e depois verificar no código fonte e no histórico de alterações e encontrou o erro no ARC que tinha como intenção melhorar o desempenho e acabou gerando tamanho problema.

 Brendan abriu a requisição de numero 6531 no GitHub da equipe do Open ZFS em 2017 (ano em que abordou esse assunto) que desde então vem dando atenção especial ao ARC e assim, não teve mais notificações por parte do cliente.

Comente com o Facebook:

Nenhum comentário:

Postar um comentário

Observação: somente um membro deste blog pode postar um comentário.

Marcadores

A pior história sobre Linux que já ouvi (5) A.I (1) ambiente gráfico (19) AMD (14) analise (9) Andriod (14) android (5) artigo (5) aws (1) bc (15) benchmark (3) BSDs (27) btrfs (30) bugs (1) Caixa de Ferramentas do UNIX (19) canto do Diego Lins (2) certificações Linux (7) Código Fonte (53) comandos (24) comp (1) compressores (5) container (6) CPU (19) criptografia (4) crowdfunding (9) cursos (24) daemons (13) Debian (31) desenvolvimento (80) desktop (19) DevOps (3) DevSecOps (3) dic (1) Dica de leitura (86) dica DLins (2) dicas do Flávio (27) Dicas TechWarn (1) diet libc (1) diocast (1) dioliunx (3) distribuições Linux (13) Docker (11) DragonflyBSD (20) ead Diolinux (2) edição de vídeo (5) EMMI Linux (4) emuladores (5) endless (5) English interview (3) Enless OS (2) entrevista (17) espaço aberto (82) evento (6) facebook (1) Fedora (10) filesystem (75) financiamento coletivo (2) fork (4) fox n forests (4) FreeBSD (20) Funtoo Linux (13) games (90) gerenciadores de pacotes (3) GOG (3) google (8) gpu (3) hardware (101) hash (1) helenos (3) I.A (1) init system (8) Intel (15) IoT (1) ispconfig (1) jogos (36) kde (1) kernel (134) lançamento (60) leis (1) LFCS (1) licenças (8) Linus (16) linus torvalds (2) Linux (194) linux foundation (3) linux para leigos (1) live (5) LPI (8) LTS (1) machine learning (1) matemática (4) mesa redonda (27) microsoft (6) microst (1) muito além do GNU (146) não viva de boatos (9) navegadores (3) NetBSD (7) novatec (17) novidades (1) nuvem (1) o meu ambiente de trabalho (3) off-topic (12) open source (82) OpenBSD (5) OpenShift (1) os vários sabores de Linux (39) padrim (2) palestras e eventos (5) partições (6) pentest (8) pipewire (1) processadores (27) professor Augusto Manzano (11) Programação (60) promoção (1) propagandas com Linux (8) Red Hat (21) redes (3) resenha nerd (4) Resumo da Semana do Dlins (2) resumo do Tux (19) retrospectiva Linux (1) risc-V (1) runlevel (2) segurança digital (19) servidores (1) shell (3) sistema operacional (22) smartphones (3) Software livre e de código aberto (150) sorteio (3) Steam (9) Steam no Linux (7) supercomputadores (4) suse (7) systemd (7) terminal (83) terminal de comandos (11) toca do tux (1) toybox (23) tutorial (6) Tux (3) unboxing (7) UNIX (16) UNIX Toolbox (14) vartroy (1) vga (1) vulnerabilidade (4) wayland (5) whatsapp (1) Windows Subsystem for Linux (2) wine (14) WoT (1) ZFS (13) zsh (2)