Converter MiB para GiB

Um mebibyte são 1.024 kibibytes, ou seja 1.048.576 bytes. As ferramentas do Linux e os números de memória quase sempre se referem a isto, mesmo escrevendo «MB».

Um gibibyte são 1.073.741.824 bytes, cerca de 7 % a mais que um gigabyte. O Windows mede em gibibytes mas rotula «GB», e é nisso que consiste todo o mistério do espaço que some.

Neste sentido a conta é uma divisão, e por um número inteiro: 1.024 dessas cabem em um gibibyte sem sobrar nada. O incômodo é só que os resultados saem em frações — um terço, um doze avos — em vez dos números redondos que o sentido contrário dá.

Mesmo assim não se perde nada, porque a divisão é exata. Se o seu resultado não quer parar quieto em decimais — 0,0833… e parentes —, isso é a fração aparecendo, não um erro se instalando.

Um MiB são 1.024 da unidade de baixo; um MB, 1.000. Nesta página isso é a diferença entre 0,001 GiB e 0,0009 GiB — 4,9 % — e a distância cresce a cada degrau: por isso é arredondamento desprezível numa foto e um pedaço visível de um HD.

O mistério do espaço que some é inteiro isso. Um disco vendido como um terabyte tem exatamente o que diz em unidades decimais; o Windows reconta em unidades binárias e mantém o nome decimal, então o número encolhe sem que nada tenha se perdido. O macOS conta em unidades decimais desde o 10.6, e é por isso que o mesmo disco pode aparecer com dois tamanhos em dois computadores.

Quantidades de recurso do Kubernetes aceitam duas famílias de sufixo. O conjunto binário — Ki, Mi, Gi, Ti, Pi, Ei — multiplica por potências de 1.024. O conjunto decimal — m, k, M, G, T, P, E — multiplica por potências de 1.000, com o kilo em minúscula, e o m na frente é um mili que existe para CPU fracionária, não para memória. memory: 512Mi e memory: 512M são os dois válidos, diferem em 24.870.912 bytes, e nenhum dos dois produz aviso.

A diferença de 4,9 por cento no degrau do mebibyte se alarga para 7,4 por cento no degrau do gibibyte: 4Gi são 4.294.967.296 bytes e 4G são 4.000.000.000. Toda ferramenta na cadeia vai preservar fielmente o que foi escrito, e o valor mostrado num painel geralmente é reformatado para a unidade que aquele painel prefere, então o sufixo original só é visível no manifesto em si. Fazer um grep no repositório atrás de um M ou G solto num campo de memória é uma auditoria de cinco minutos que vale fazer uma vez.

CPU é compressível: um contêiner que pede mais do que seu limite é estrangulado e continua, devagar. Memória não. Quando o cgroup de um contêiner ultrapassa seu limite de memória, o OOM killer do kernel encerra um processo dentro dele, o contêiner relata código de saída 137, e o pod reinicia. Não há degradação gradual nem aviso no meio do caminho, motivo pelo qual um limite 4,9 por cento menor do que pretendido não é um erro de arredondamento, é uma mudança na frequência com que uma carga morre.

Isso também significa que os dois sufixos falham de forma assimétrica. Escrever M onde se queria Mi torna o limite menor e o contêiner mais propenso a ser morto — uma falha visível que acaba investigada. Escrever Mi onde se queria M torna o limite maior, o que não aparece em nada até o nó ficar sobrecarregado e o escalonador ter empacotado com cifras todas ligeiramente generosas. A segunda é a que custa dinheiro em silêncio.

Uma JVM iniciada com -Xmx4096m tem um heap de 4 GiB e um consumo total notavelmente maior. Metaspace guarda metadados de classe e é ilimitado por padrão; cada thread leva sua própria pilha, tipicamente 1 MiB, fora do heap; o cache de código do JIT vem em 240 MiB por padrão no HotSpot 64 bits; buffers diretos de byte usados pelo Netty e pela maioria dos servidores baseados em NIO são memória nativa; e o coletor de lixo mantém suas próprias estruturas. Um limite de contêiner igual ao -Xmx é um contêiner que vai ser morto.

A prática usual é dar ao contêiner 25 a 50 por cento a mais que o heap, ou parar de definir -Xmx e deixar a JVM se dimensionar sozinha. Desde o JDK 10 o runtime lê o limite do cgroup e aplica -XX:MaxRAMPercentage, que vem padrão em 25 — conservador o bastante para um contêiner de 4Gi receber um heap de 1 GiB a menos que a porcentagem seja aumentada. Ajustar para 70 ou 75 e deixar a JVM fazer a aritmética remove um dos dois números que podem estar errados.

Um nó anunciado como 16 GiB não oferece 16.384 MiB para pods. Capacidade menos kube-reserved menos system-reserved menos o limiar de despejo forçado dão alocável, e num cluster gerenciado a reserva costuma ir de algumas centenas de mebibytes num nó pequeno a mais de um gibibyte num grande. kubectl describe node imprime capacidade e alocável lado a lado, e a diferença é o número que decide quantas réplicas realmente cabem.

É aqui que converter para gibibytes se justifica, porque aritmética de empacotamento em mebibytes convida a erros. Nove réplicas a 1.536Mi são 13.824Mi, que são 13,5 GiB, que cabe dentro de 14,6 GiB de alocável com espaço para os daemonsets e não cabe se o nó reserva mais do que parecia. Fazer a soma em mebibytes e comparar com um nó cotado em gibibytes é como um cluster acaba uma réplica abaixo do pretendido sem causa óbvia.

O request é o que o escalonador reserva e o limit é o que o kernel impõe, e a relação entre os dois decide a prioridade de despejo do pod. Request e limit iguais dão Guaranteed; um request menor que o limit dá Burstable; nenhum dos dois definidos dá BestEffort, o primeiro a ser despejado quando um nó fica sob pressão. A classe decorre dos dois números em vez de ser declarada, então um manifesto com 512Mi e 1Gi escolheu Burstable, quisesse ou não.

Para memória especificamente, o argumento para deixar os dois iguais é mais forte do que para CPU. Um pod Burstable que habitualmente usa mais que seu request é escalonado como se fosse pequeno e morto como se fosse grande, e o nó em que aterrissa fica sobrecarregado com base numa cifra que ninguém conferiu. Onde o conjunto de trabalho é conhecido, escrever a mesma cifra em gibibytes duas vezes é mais simples e mais honesto que uma diferença que ninguém revisita.

O manifesto diz 1536Mi; o Grafana diz 1,5 GiB; o console de nuvem diz 1,61 GB; o relatório de custo diz 1,6 GB-hora. Os quatro são os mesmos 1.610.612.736 bytes, apresentados por quatro ferramentas com convenções diferentes, e só os dois primeiros estão do lado binário. Reconciliar uma fatura contra um manifesto significa saber de que lado cada cifra está antes de comparar, e a diferença de 7,4 por cento é grande o bastante para parecer uma discrepância de verdade.

O hábito que ajuda é manter uma unidade canônica por documento. Planos de capacidade em gibibytes, manifestos na que for de Mi ou Gi que mantiver o número inteiro, e qualquer cifra citada numa unidade decimal rotulada como tal. Uma planilha de capacidade cujo cabeçalho de coluna diz GiB e cujos números vieram de um console relatando GB está errada por um quinze avos e vai continuar errada até alguém reconstruí-la.

A cifra que vale converter é a que a carga realmente usa, e container_memory_working_set_bytes é a métrica sobre a qual o kernel e o OOM killer efetivamente agem — memória residente menos o cache de página que pode ser recuperado. Pegar o pico ao longo de duas semanas, acrescentar folga, e arredondar para uma cifra arrumada em mebibytes ou gibibytes produz um limite defensável; pegar o RSS do contêiner ou, pior, o próprio relatório de heap da JVM produz um que não é.

Arredonde para cima até uma potência de dois onde a escolha for livre. Um limite de 1.536Mi são 1,5 GiB e empacota de forma limpa em nós dimensionados em gibibytes; um limite de 1.600Mi são 1,5625 GiB, empacota mal, e diz ao próximo leitor que o número veio de um cálculo decimal em algum lugar rio acima. A aritmética é exata nas duas direções, então o que está sendo otimizado é só a legibilidade do número para a próxima pessoa que precisar mudá-lo.