{"id":21291,"date":"2026-09-11T11:51:31","date_gmt":"2026-09-11T09:51:31","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/"},"modified":"2026-09-11T11:51:31","modified_gmt":"2026-09-11T09:51:31","slug":"interpretar-corretamente-o-racio-de-fragmentacao-da-memoria-do-redis-analise-da-memoria","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/","title":{"rendered":"Interpretar corretamente e otimizar o r\u00e1cio de fragmenta\u00e7\u00e3o de mem\u00f3ria do Redis"},"content":{"rendered":"<p><strong>Fragmenta\u00e7\u00e3o do Redis<\/strong> determina a quantidade de mem\u00f3ria que se perde entre o RSS atribu\u00eddo pelo sistema operativo e os dados do Redis efetivamente utilizados, e como evitar a lat\u00eancia, o swap e as falhas. Vou explicar o <strong>R\u00e1cio de fragmenta\u00e7\u00e3o de mem\u00f3ria do Redis<\/strong> orientado para a pr\u00e1tica, apresente valores-limite relevantes e indique medidas claras para o ajuste, a monitoriza\u00e7\u00e3o e a modela\u00e7\u00e3o de dados.<\/p>\n\n<h2>Pontos centrais<\/h2>\n\n<ul>\n  <li><strong>Defini\u00e7\u00e3o de<\/strong>: Ler corretamente a rela\u00e7\u00e3o entre used_memory_rss e used_memory.<\/li>\n  <li><strong>Valores-limite<\/strong>: Agir a partir de 1,5; se for inferior a 1,0, verificar imediatamente.<\/li>\n  <li><strong>Causas<\/strong>: Tamanhos vari\u00e1veis dos objetos, ondas de apagamento, tempos de execu\u00e7\u00e3o longos.<\/li>\n  <li><strong>Medidas<\/strong>: Desfragmenta\u00e7\u00e3o ativa, elabora\u00e7\u00e3o de or\u00e7amentos, otimiza\u00e7\u00e3o do modelo de dados.<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong>: Definir alertas para os valores do Ratio e do Allocator.<\/li>\n<\/ul>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img fetchpriority=\"high\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-analyse-4032.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>O que significa exatamente \u00abmem_fragmentation_ratio\u00bb?<\/h2>\n\n<p>Utilizo o valor de refer\u00eancia <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong>, para ver a rela\u00e7\u00e3o entre o RSS e o consumo de dados. O quociente entre <strong>mem\u00f3ria_usada_rss<\/strong> dividido por <strong>mem\u00f3ria_utilizada<\/strong> mostra o qu\u00e3o intensamente o Redis utiliza a RAM. Valores pr\u00f3ximos de 1,0 indicam uma <strong>eficiente<\/strong> Taxa de utiliza\u00e7\u00e3o com poucas lacunas. Valores elevados indicam que existem muitas \u00e1reas livres no processo que o alocador n\u00e3o consegue reutilizar. Nunca avalio este valor isoladamente, mas sim em conjunto com o tamanho, a carga de trabalho e <strong>Alocador<\/strong>-M\u00e9tricas.<\/p>\n\n<h2>Interpretar corretamente os valores de refer\u00eancia<\/h2>\n\n<p>Eu organizo o <strong>R\u00e1cio<\/strong> em zonas fixas, para que as decis\u00f5es continuem a ser reproduz\u00edveis. Para mim, pequenos excedentes em torno de 1,1 s\u00e3o normais <strong>Despesas gerais<\/strong>. A partir de cerca de 1,5, planeio tomar medidas, porque, caso contr\u00e1rio, a RAM fica ociosa ou o sistema aproxima-se dos limites de OOM. Abaixo de 1,0, reajo imediatamente, pois isso indica <strong>Troca<\/strong> . A tabela seguinte resume as \u00e1reas e a\u00e7\u00f5es t\u00edpicas.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>R\u00e1cio<\/strong><\/th>\n      <th><strong>Significado<\/strong><\/th>\n      <th><strong>medida imediata<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Menos de 1,0<\/td>\n      <td><strong>Troca<\/strong>-Risco, lat\u00eancia elevada<\/td>\n      <td>Verificar a RAM\/mem\u00f3ria m\u00e1xima e reduzir a quantidade de dados<\/td>\n    <\/tr>\n    <tr>\n      <td>1,0\u20131,1<\/td>\n      <td><strong>Saud\u00e1vel<\/strong> com um ligeiro custo adicional<\/td>\n      <td>Continuar a acompanhar, nada de urgente<\/td>\n    <\/tr>\n    <tr>\n      <td>1,1\u20131,5<\/td>\n      <td><strong>Normal<\/strong>, fragmenta\u00e7\u00e3o moderada<\/td>\n      <td>Observar tend\u00eancias, registar as causas<\/td>\n    <\/tr>\n    <tr>\n      <td>Mais de 1,5<\/td>\n      <td><strong>Aumentado<\/strong>, desperd\u00edcio de mem\u00f3ria<\/td>\n      <td>Active Defrag, verificar o modelo, testar o Purge<\/td>\n    <\/tr>\n    <tr>\n      <td>Mais de 2,0<\/td>\n      <td><strong>Elevado<\/strong>, press\u00e3o sobre a capacidade<\/td>\n      <td>Desfragmenta\u00e7\u00e3o agressiva, considerar reiniciar<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_meeting_optimization_6723.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Como surge a fragmenta\u00e7\u00e3o<\/h2>\n\n<p>Vejo um elevado <strong>Fragmenta\u00e7\u00e3o<\/strong> sobretudo em caso de muitas ondas de grava\u00e7\u00e3o e apagamento. O alocador, na maioria das vezes <strong>jemalloc<\/strong>, cria armazenamento nas arenas que nem sempre \u00e9 reciclado na perfei\u00e7\u00e3o. Quando as chaves encolhem, aumentam ou desaparecem por completo, ficam lacunas. Muitas vezes, os novos objetos n\u00e3o cabem nessas lacunas, o que faz com que o RSS se mantenha mais elevado do que os dados reais. Com tempos de execu\u00e7\u00e3o longos, estas lacunas acumulam-se <strong>Lacunas<\/strong>, at\u00e9 que o r\u00e1cio aumente significativamente.<\/p>\n\n<h2>Sintomas e riscos no local de trabalho<\/h2>\n\n<p>Crescente <strong>Lat\u00eancia<\/strong>, o que me salta \u00e0 vista em primeiro lugar s\u00e3o os erros OOM repentinos e o aumento do RSS. Mesmo que o used_memory se mantenha moderado, a inst\u00e2ncia pode <strong>RAM<\/strong>-atingir os limites. Quando o sistema come\u00e7a a transferir p\u00e1ginas para a mem\u00f3ria externa, os tempos de resposta disparam. Os servi\u00e7os tornam-se lentos e os tempos de espera aumentam, o que perturba o funcionamento das aplica\u00e7\u00f5es. Por isso, tenho sempre em conta a <strong>Troca<\/strong>-M\u00e9tricas em destaque.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-memory-optimization-8486.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ler a INFO MEMORY com seguran\u00e7a<\/h2>\n\n<p>Sobre <strong>INFORMA\u00c7\u00c3O<\/strong> No que diz respeito \u00e0 mem\u00f3ria, verifico os valores de used_memory, used_memory_rss e mem_fragmentation_ratio. Al\u00e9m disso, presto aten\u00e7\u00e3o a <strong>allocator_frag_ratio<\/strong> e allocator_rss_ratio, para detetar diferen\u00e7as entre a pilha e o sistema operativo. Um valor elevado de mem_fragmentation_ratio, quando o valor do alocador \u00e9 normal, indica-me que o sistema operativo n\u00e3o est\u00e1 a recuperar bem as p\u00e1ginas. Por outro lado, valores elevados do alocador apontam para problemas internos <strong>Pilha<\/strong>- fragmenta\u00e7\u00e3o. Registo as combina\u00e7\u00f5es para que as tend\u00eancias fiquem vis\u00edveis e as medidas surtam efeito de forma precisa.<\/p>\n\n<h2>A desfragmenta\u00e7\u00e3o ativa na pr\u00e1tica<\/h2>\n\n<p>Eu ativo o <strong>Ativo<\/strong> Desfragmenta\u00e7\u00e3o, quando o r\u00e1cio aumenta ou as cargas de trabalho oscilam significativamente. Nesse processo, o Redis reorganiza os objetos e agrupa-os de forma mais compacta, para que o sistema operativo possa libertar p\u00e1ginas. Estou a testar o controlo gradualmente, para manter os custos de CPU dentro de limites razo\u00e1veis. Para come\u00e7ar, utilizo configura\u00e7\u00f5es comprovadas e, posteriormente, fa\u00e7o ajustes finos. Este artigo fornece-me uma boa introdu\u00e7\u00e3o <a href=\"https:\/\/webhosting.de\/pt\/redis-desfragmentacao-ativa-reducao-da-fragmentacao-da-memoria-otimizacao-do-heap\/\">Desfragmenta\u00e7\u00e3o ativa<\/a>-Artigo.<\/p>\n\n<pre><code>CONFIG SET activedefrag yes\nCONFIG SET active-defrag-ignore-bytes 100mb\nCONFIG SET active-defrag-threshold-lower 10\nCONFIG SET active-defrag-threshold-upper 100\nCONFIG SET active-defrag-cycle-min 5\nCONFIG SET active-defrag-cycle-max 75\n<\/code><\/pre>\n\n<p>Eu fixo <strong>Valores-limite<\/strong> de forma a que o Defrag seja ativado apenas quando for realmente necess\u00e1rio. Os valores de Cycle limitam a utiliza\u00e7\u00e3o da CPU, para que os picos de carga n\u00e3o sejam afetados. Ap\u00f3s os ajustes, observo as m\u00e9tricas durante v\u00e1rias horas. S\u00f3 quando o Ratio, a lat\u00eancia e a utiliza\u00e7\u00e3o da CPU parecerem adequados \u00e9 que aplico as <strong>Valores<\/strong> permanente.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_optimierung_3021.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Ajustar os par\u00e2metros com precis\u00e3o, sem efeitos secund\u00e1rios<\/h2>\n\n<p>Eu aumento a <strong>Valores de limiar<\/strong> apenas em pequenos passos, para evitar efeitos secund\u00e1rios. Um ciclo demasiado agressivo reduz, certes, a fragmenta\u00e7\u00e3o, mas sobrecarrega o <strong>CPU<\/strong> not\u00e1vel. Em per\u00edodos de maior tr\u00e1fego diurno, adio os testes para intervalos mais calmos, para que os efeitos continuem a ser bem mensur\u00e1veis. \u00c9 \u00fatil fazer uma compara\u00e7\u00e3o antes e depois do ajuste com condi\u00e7\u00f5es id\u00eanticas <strong>Carga de trabalho<\/strong>. \u00c9 assim que consigo perceber se o Defrag reduz realmente o r\u00e1cio ou se apenas redistribui a carga.<\/p>\n\n<h2>Utilizar o Lazy Free de forma consciente<\/h2>\n\n<p>Eu uso <strong>Lazy Free<\/strong>, quando muitas chaves grandes desaparecem ou s\u00e3o renomeadas ao mesmo tempo. Em vez de bloquear a sincroniza\u00e7\u00e3o, <em>DESLIGAR<\/em>, <em>FLUSHDB ASYNC<\/em> e <em>FLUSHALL ASYNC<\/em> Liberta mem\u00f3ria em segundo plano. Isto reduz os picos de lat\u00eancia, mas pode aumentar a fragmenta\u00e7\u00e3o a curto prazo, uma vez que as p\u00e1ginas s\u00e3o recicladas de forma ass\u00edncrona. Controlo este comportamento atrav\u00e9s dos par\u00e2metros do lazyfree (por exemplo, lazyfree-lazy-eviction, lazyfree-lazy-server-del), testo os efeitos na CPU e monitorizo <strong>lazyfree_pending_objects<\/strong> na mem\u00f3ria INFO. Se ficarem muitos objetos pendentes, aumente ligeiramente os or\u00e7amentos de desfragmenta\u00e7\u00e3o ou espalhe as ondas de elimina\u00e7\u00e3o, para que a pilha n\u00e3o se fragmentem em muitos pequenos espa\u00e7os vazios.<\/p>\n\n<h2>Planear a limpeza manual e o rein\u00edcio<\/h2>\n\n<p>Se o Ratio disparar, vou tomar medidas dr\u00e1sticas <strong>Alavanca<\/strong>. Com o comando MEMORY PURGE, solicito ao alocador que devolva as p\u00e1ginas n\u00e3o utilizadas ao sistema operativo. Com o comando DEBUG MALLOC-STATS, consigo analisar mais detalhadamente o <strong>Arenas<\/strong> e padr\u00f5es de aloca\u00e7\u00e3o. Se o r\u00e1cio se mantiver acima de 2,0, pretendo planear um rein\u00edcio coordenado ap\u00f3s um snapshot ou uma sincroniza\u00e7\u00e3o AOF. Este passo define a <strong>Estrutura de armazenamento<\/strong> Volta atr\u00e1s e acede imediatamente ao RSS.<\/p>\n\n<h2>Planear a Maxmemory de forma inteligente<\/h2>\n\n<p>Estou a planear <strong>mem\u00f3ria m\u00e1xima<\/strong> nunca at\u00e9 ao limite f\u00edsico da RAM. Como regra geral, reservo cerca de 60\u201365 % para dados, 5\u201310 % como buffer de fragmenta\u00e7\u00e3o e 10\u201320 % para <strong>Copy-on-Write<\/strong>. O restante destina-se ao sistema operativo, aos agentes e ao funcionamento. Esta reparti\u00e7\u00e3o impede <strong>OOM<\/strong>-Surpresas e d\u00e1 espa\u00e7o ao Defrag. Encontro aqui um guia pr\u00e1tico: <a href=\"https:\/\/webhosting.de\/pt\/gestao-de-memoria-do-redis-configurar-a-memoria-de-forma-otimizada-desempenho-cache\/\">Configurar a mem\u00f3ria de forma ideal<\/a>.<\/p>\n\n<h2>Persist\u00eancia, RDB\/AOF e Copy-on-Write<\/h2>\n\n<p>Tenho sempre em conta os efeitos de <strong>Persist\u00eancia<\/strong> em rela\u00e7\u00e3o \u00e0 fragmenta\u00e7\u00e3o. No BGSAVE e nas reescritas AOF, o Copy-on-Write duplica as p\u00e1ginas alteradas. Nesta fase, o RSS aumenta, embora a used_memory quase n\u00e3o cres\u00e7a. Por isso, pretendo realizar reescritas completas em intervalos de tempo menos movimentados e verificar <em>auto-aof-percentagem-de-reescrita<\/em> e <em>-tamanho m\u00ednimo<\/em> e mantenho espa\u00e7o livre dispon\u00edvel para o CoW. Picos de escrita intensos durante uma reescrita fazem com que as arenas se fragmentem rapidamente; a desfragmenta\u00e7\u00e3o posterior recupera o RSS. Nas r\u00e9plicas, observo a primeira ressincroniza\u00e7\u00e3o completa com especial aten\u00e7\u00e3o: grandes importa\u00e7\u00f5es em massa, juntamente com o CoW, s\u00e3o um fator cl\u00e1ssico para picos elevados a curto prazo <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong>. Se o valor continuar elevado ap\u00f3s a conclus\u00e3o, vou executar uma breve desfragmenta\u00e7\u00e3o ou testar <em>LIMPEZA DA MEM\u00d3RIA<\/em>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis_optimierung_desktop_4253.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Abaixo de 1,0: o swap \u00e9 o trav\u00e3o<\/h2>\n\n<p>Se o r\u00e1cio for inferior a 1,0, o sistema trava <strong>Troca<\/strong> o sistema. Cada ciclo de falha de p\u00e1gina consome tempo significativo e compromete os objetivos de lat\u00eancia. Verifico ent\u00e3o o estado da RAM e reduzo <strong>mem\u00f3ria m\u00e1xima<\/strong> ou reduzir os dados na inst\u00e2ncia. Al\u00e9m disso, controlo par\u00e2metros do sistema como o vm.swappiness, para que o kernel recorra com menos frequ\u00eancia <strong>externaliza<\/strong>. O objetivo continua a ser manter a inst\u00e2ncia exclusivamente na RAM e evitar a recupera\u00e7\u00e3o de p\u00e1ginas.<\/p>\n\n<h2>Ter em conta as defini\u00e7\u00f5es dos contentores e do kernel<\/h2>\n\n<p>Nos contentores, medo sempre a fragmenta\u00e7\u00e3o no contexto de <strong>cgroups<\/strong>-Limites. Comparo o RSS com os limites de mem\u00f3ria e defino <em>vm.overcommit_memory=1<\/em>, para que o Redis n\u00e3o falhe devido ao overcommit. <strong>P\u00e1ginas enormes transparentes<\/strong> Desativo-as porque sobrecarregam o RSS e dificultam a desfragmenta\u00e7\u00e3o. Al\u00e9m disso, observo que <em>oom_kill<\/em>- Monitorizo o contador do cgroup e reajo atempadamente quando o kernel come\u00e7a a ficar sobrecarregado. No Kubernetes, defino pedidos\/limites realistas e reservo margem de manobra por pod, para que o BGSAVE e as reescritas n\u00e3o atinjam os limites de forma indesejada. Importante: o isolamento de contentores n\u00e3o altera a l\u00f3gica interna da pilha \u2013 a desfragmenta\u00e7\u00e3o, o Lazy Free e a atualiza\u00e7\u00e3o do modelo continuam a ser as ferramentas centrais contra <strong>Fragmenta\u00e7\u00e3o<\/strong>.<\/p>\n\n\n<figure class=\"wp-block-image size-full is-resized\">\n  <img loading=\"lazy\" decoding=\"async\" src=\"https:\/\/webhosting.de\/wp-content\/uploads\/2026\/09\/redis-optimierung-4931.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Otimizar o modelo de dados e os indicadores-chave<\/h2>\n\n<p>Eu seguro <strong>objetos<\/strong> pequenas e uniformes, para que o alocador tenha menos varia\u00e7\u00e3o. Divido listas, conjuntos ou tabelas hash muito grandes em v\u00e1rias chaves mais pequenas. Em vez de cadeias JSON enormes, utilizo <strong>Tipos de dados<\/strong> como hashes com campos que mudam com menos frequ\u00eancia. No caso de sess\u00f5es, contadores e caches, padronizo os tamanhos para que as aloca\u00e7\u00f5es sejam mais previs\u00edveis. Assim, reduzo o <strong>Fragmenta\u00e7\u00e3o<\/strong>, antes de come\u00e7ar a ajustar as configura\u00e7\u00f5es.<\/p>\n\n<h2>Pol\u00edtica de despejo e comportamento de fluxo<\/h2>\n\n<p>Eu escolho o <strong>Pol\u00edtica de despejo<\/strong> de acordo com a carga de trabalho. Quando os conjuntos de chaves variam significativamente, as variantes LRU\/LFU distribuem as elimina\u00e7\u00f5es de forma mais uniforme e evitam picos. Evito expira\u00e7\u00f5es em massa \u00e0 hora em ponto e distribuo os TTLs, para que o Active-Expire n\u00e3o remova milhares de objetos ao mesmo tempo. Par\u00e2metros como <em>hz<\/em> e <em>active-expire-effort<\/em> ajusto apenas com cuidado, para n\u00e3o sobrecarregar a CPU. Um padr\u00e3o de execu\u00e7\u00e3o regular gera aloca\u00e7\u00f5es previs\u00edveis \u2013 e \u00e9 precisamente isso que mant\u00e9m a <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong> plano.<\/p>\n\n<h2>Redis Cluster e Sharding<\/h2>\n\n<p>No que diz respeito ao crescimento, aposto em <strong>Fragmenta\u00e7\u00e3o<\/strong> ou clusters, porque os heaps mais pequenos por shard criam menos lacunas de longo prazo. Durante o reequil\u00edbrio, planeio as janelas de migra\u00e7\u00e3o de forma a que os picos de escrita e as reescritas n\u00e3o entrem em conflito. Grandes ondas de MIGRATE podem aumentar temporariamente o RSS nos n\u00f3s de destino; durante esse per\u00edodo, observo os valores do alocador e ativo a desfragmenta\u00e7\u00e3o ap\u00f3s a movimenta\u00e7\u00e3o. Nas r\u00e9plicas, tenho em conta a mem\u00f3ria adicional para backlogs e buffers de r\u00e9plica \u2013 isso tamb\u00e9m \u00e9 tido em conta na <strong>Maxmemory<\/strong>- Or\u00e7amenta\u00e7\u00e3o.<\/p>\n\n<h2>Aprofundar os conhecimentos sobre observabilidade: MEMORY STATS e lat\u00eancia<\/h2>\n\n<ul>\n  <li>Eu uso <strong>ESTAT\u00cdSTICAS DE MEM\u00d3RIA<\/strong>, para ver a sobrecarga, a percentagem do conjunto de dados e os detalhes da fragmenta\u00e7\u00e3o. Isto ajuda a distinguir a fragmenta\u00e7\u00e3o da pilha da fragmenta\u00e7\u00e3o do sistema operativo.<\/li>\n  <li>Com <strong>MEMORY DOCTOR<\/strong> recebo indica\u00e7\u00f5es sobre se o modelo de dados, a desfragmenta\u00e7\u00e3o ou a limpeza s\u00e3o as op\u00e7\u00f5es que trazem mais benef\u00edcios a curto prazo.<\/li>\n  <li>Eu correlaciono <strong>lat\u00eancia<\/strong>-M\u00e9tricas (por exemplo, \u00ablatency doctor\u00bb) com fases de desfragmenta\u00e7\u00e3o e reescritas, para detetar efeitos secund\u00e1rios.<\/li>\n  <li>O <strong>SLOWLOG<\/strong> mostra-me se os comandos ficam desincronizados devido a a\u00e7\u00f5es de mem\u00f3ria \u2013 especialmente DEL, UNLINK e grandes s\u00e9ries de HSET\/HGET.<\/li>\n<\/ul>\n\n<h2>Guia pr\u00e1tico para a gest\u00e3o<\/h2>\n\n<ul>\n  <li>Linha de base: guardar a mem\u00f3ria INFO, registar a rela\u00e7\u00e3o, os valores do alocador e o conjunto de dados\/sobrecarga.<\/li>\n  <li>Or\u00e7amento: definir o `maxmemory` para valores realistas de 60\u201365 % de dados, 5\u201310 % de fragmenta\u00e7\u00e3o e 10\u201320 % de CoW.<\/li>\n  <li>Desfragmenta\u00e7\u00e3o: ativar o \u00abactivedefrag\u00bb, aumentar o valor gradualmente e com cuidado, e medir os efeitos ao longo de v\u00e1rias horas.<\/li>\n  <li>Modelo de dados: dividir objetos grandes, evitar blocos JSON, padronizar tamanhos.<\/li>\n  <li>Expira\u00e7\u00e3o: distribuir os TTLs, escolher a pol\u00edtica de evic\u00e7\u00e3o adequada, evitar ondas de elimina\u00e7\u00e3o.<\/li>\n  <li>Persist\u00eancia: planear reescritas, disponibilizar espa\u00e7o livre e verificar a desfragmenta\u00e7\u00e3o ap\u00f3s a conclus\u00e3o.<\/li>\n  <li>Purga\/Rein\u00edcio: se o r\u00e1cio for &gt; 2,0, tentar a purga; caso contr\u00e1rio, reiniciar de forma ordenada.<\/li>\n  <li>Contentor: THP desativado, Overcommit ativado, Limites\/Pedidos com margem; limitar rigorosamente o swap.<\/li>\n  <li>Monitoriza\u00e7\u00e3o: alertas aos valores de 1,5\/2,0\/inferior a 1,0; analisar tend\u00eancias por implementa\u00e7\u00f5es e lotes.<\/li>\n<\/ul>\n\n<h2>Exemplo: De 1,8 para 1,2 em 24 horas<\/h2>\n\n<p>Numa inst\u00e2ncia de 64 GB (maxmemory 40 GB), a <strong>r\u00e1cio_de_fragmenta\u00e7\u00e3o_de_mem\u00f3ria<\/strong> para 1,8, apesar de o \u00abused_memory\u00bb se situar entre 28 e 30 GB. Primeiro, eu <em>ativar desfragmenta\u00e7\u00e3o<\/em> Ativei (cycle-min 5, cycle-max 50) e desloquei o hor\u00e1rio da reescrita AOF noturna para um per\u00edodo mais calmo. Em seguida, reajustei os TTLs que, at\u00e9 ent\u00e3o, expiravam de hora a hora e substitu\u00ed v\u00e1rios valores JSON de grande dimens\u00e3o por hashes com tamanhos de campo est\u00e1veis. Uma medida espec\u00edfica <em>LIMPEZA DA MEM\u00d3RIA<\/em> Ap\u00f3s o pico de carga, o RSS tamb\u00e9m foi libertado. Resultado: ao fim de 24 horas, o r\u00e1cio desceu de forma est\u00e1vel para ~1,2, os picos de lat\u00eancia desapareceram e a mem\u00f3ria RAM do anfitri\u00e3o ganhou ~8 GB de espa\u00e7o livre. O <strong>Alocador<\/strong>- Valores confirmados: menor fragmenta\u00e7\u00e3o da pilha, RSS do SO dentro dos limites.<\/p>\n\n<h2>Comparar de forma sensata os ambientes de alojamento<\/h2>\n\n<p>Tenho o cuidado de garantir que haja <strong>RAM<\/strong>, valores previs\u00edveis de CPU e E\/S consistentes, se eu instalar o Redis no servidor do fornecedor de alojamento. Recursos dedicados e atualiza\u00e7\u00f5es flex\u00edveis evitam gargalos \u00e0 medida que a empresa cresce. \u00c9 aconselh\u00e1vel dispor de m\u00e9tricas claras relativas ao RSS, <strong>Troca<\/strong> e limites, para que eu consiga detetar atempadamente pontos de estrangulamento. Para configura\u00e7\u00f5es alem\u00e3s, recomendo o webhoster.de, porque l\u00e1 os recursos est\u00e3o dispon\u00edveis de forma fi\u00e1vel. Uma plataforma bem organizada mant\u00e9m o <strong>Fragmenta\u00e7\u00e3o<\/strong>O valor [-] dentro dos limites normais.<\/p>\n\n<h2>Resumo<\/h2>\n\n<p>Eu leio o <strong>Redis<\/strong> A taxa de fragmenta\u00e7\u00e3o da mem\u00f3ria como sinal de alerta precoce para perdas de RAM e lat\u00eancia. Valores pr\u00f3ximos de 1,0 s\u00e3o considerados saud\u00e1veis; a partir de 1,5, procedo \u00e0 desfragmenta\u00e7\u00e3o e a ajustes no modelo; abaixo de 1,0, interrompo o processo <strong>Troca<\/strong> imediatamente. Com a desfragmenta\u00e7\u00e3o ativa, uma gest\u00e3o inteligente da mem\u00f3ria m\u00e1xima e estruturas de dados compactas, mantenho a <strong>Mem\u00f3ria<\/strong>- Elevada efici\u00eancia. A monitoriza\u00e7\u00e3o cont\u00ednua identifica padr\u00f5es e evita a\u00e7\u00f5es ad hoc precipitadas. Desta forma, a inst\u00e2ncia mant\u00e9m-se \u00e1gil e o <strong>R\u00e1cio<\/strong> move-se onde deve estar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprenda a interpretar corretamente o r\u00e1cio de fragmenta\u00e7\u00e3o de mem\u00f3ria do Redis, a identificar intervalos normais e cr\u00edticos e a manter a mem\u00f3ria do Redis eficiente e est\u00e1vel atrav\u00e9s de um ajuste espec\u00edfico do Redis.<\/p>","protected":false},"author":1,"featured_media":21284,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-21291","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-datenbanken-administration-anleitungen"],"acf":[],"_wp_attached_file":null,"_wp_attachment_metadata":null,"litespeed-optimize-size":null,"litespeed-optimize-set":null,"_elementor_source_image_hash":null,"_wp_attachment_image_alt":null,"stockpack_author_name":null,"stockpack_author_url":null,"stockpack_provider":null,"stockpack_image_url":null,"stockpack_license":null,"stockpack_license_url":null,"stockpack_modification":null,"color":null,"original_id":null,"original_url":null,"original_link":null,"unsplash_location":null,"unsplash_sponsor":null,"unsplash_exif":null,"unsplash_attachment_metadata":null,"_elementor_is_screenshot":null,"surfer_file_name":null,"surfer_file_original_url":null,"envato_tk_source_kit":null,"envato_tk_source_index":null,"envato_tk_manifest":null,"envato_tk_folder_name":null,"envato_tk_builder":null,"envato_elements_download_event":null,"_menu_item_type":null,"_menu_item_menu_item_parent":null,"_menu_item_object_id":null,"_menu_item_object":null,"_menu_item_target":null,"_menu_item_classes":null,"_menu_item_xfn":null,"_menu_item_url":null,"_trp_menu_languages":null,"rank_math_primary_category":null,"rank_math_title":null,"inline_featured_image":null,"_yoast_wpseo_primary_category":null,"rank_math_schema_blogposting":null,"rank_math_schema_videoobject":null,"_oembed_049c719bc4a9f89deaead66a7da9fddc":null,"_oembed_time_049c719bc4a9f89deaead66a7da9fddc":null,"_yoast_wpseo_focuskw":null,"_yoast_wpseo_linkdex":null,"_oembed_27e3473bf8bec795fbeb3a9d38489348":null,"_oembed_c3b0f6959478faf92a1f343d8f96b19e":null,"_trp_translated_slug_en_us":null,"_wp_desired_post_slug":null,"_yoast_wpseo_title":null,"tldname":null,"tldpreis":null,"tldrubrik":null,"tldpolicylink":null,"tldsize":null,"tldregistrierungsdauer":null,"tldtransfer":null,"tldwhoisprivacy":null,"tldregistrarchange":null,"tldregistrantchange":null,"tldwhoisupdate":null,"tldnameserverupdate":null,"tlddeletesofort":null,"tlddeleteexpire":null,"tldumlaute":null,"tldrestore":null,"tldsubcategory":null,"tldbildname":null,"tldbildurl":null,"tldclean":null,"tldcategory":null,"tldpolicy":null,"tldbesonderheiten":null,"tld_bedeutung":null,"_oembed_d167040d816d8f94c072940c8009f5f8":null,"_oembed_b0a0fa59ef14f8870da2c63f2027d064":null,"_oembed_4792fa4dfb2a8f09ab950a73b7f313ba":null,"_oembed_33ceb1fe54a8ab775d9410abf699878d":null,"_oembed_fd7014d14d919b45ec004937c0db9335":null,"_oembed_21a029d076783ec3e8042698c351bd7e":null,"_oembed_be5ea8a0c7b18e658f08cc571a909452":null,"_oembed_a9ca7a298b19f9b48ec5914e010294d2":null,"_oembed_f8db6b27d08a2bb1f920e7647808899a":null,"_oembed_168ebde5096e77d8a89326519af9e022":null,"_oembed_cdb76f1b345b42743edfe25481b6f98f":null,"_oembed_87b0613611ae54e86e8864265404b0a1":null,"_oembed_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_oembed_time_27aa0e5cf3f1bb4bc416a4641a5ac273":null,"_tldname":null,"_tldclean":null,"_tldpreis":null,"_tldcategory":null,"_tldsubcategory":null,"_tldpolicy":null,"_tldpolicylink":null,"_tldsize":null,"_tldregistrierungsdauer":null,"_tldtransfer":null,"_tldwhoisprivacy":null,"_tldregistrarchange":null,"_tldregistrantchange":null,"_tldwhoisupdate":null,"_tldnameserverupdate":null,"_tlddeletesofort":null,"_tlddeleteexpire":null,"_tldumlaute":null,"_tldrestore":null,"_tldbildname":null,"_tldbildurl":null,"_tld_bedeutung":null,"_tldbesonderheiten":null,"_oembed_ad96e4112edb9f8ffa35731d4098bc6b":null,"_oembed_8357e2b8a2575c74ed5978f262a10126":null,"_oembed_3d5fea5103dd0d22ec5d6a33eff7f863":null,"_eael_widget_elements":null,"_oembed_0d8a206f09633e3d62b95a15a4dd0487":null,"_oembed_time_0d8a206f09633e3d62b95a15a4dd0487":null,"_aioseo_description":null,"_eb_attr":null,"_eb_data_table":null,"_oembed_819a879e7da16dd629cfd15a97334c8a":null,"_oembed_time_819a879e7da16dd629cfd15a97334c8a":null,"_acf_changed":null,"_wpcode_auto_insert":null,"_edit_last":null,"_edit_lock":null,"_oembed_e7b913c6c84084ed9702cb4feb012ddd":null,"_oembed_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_time_bfde9e10f59a17b85fc8917fa7edf782":null,"_oembed_03514b67990db061d7c4672de26dc514":null,"_oembed_time_03514b67990db061d7c4672de26dc514":null,"rank_math_news_sitemap_robots":null,"rank_math_robots":null,"_eael_post_view_count":"65","_trp_automatically_translated_slug_ru_ru":null,"_trp_automatically_translated_slug_et":null,"_trp_automatically_translated_slug_lv":null,"_trp_automatically_translated_slug_fr_fr":null,"_trp_automatically_translated_slug_en_us":null,"_wp_old_slug":null,"_trp_automatically_translated_slug_da_dk":null,"_trp_automatically_translated_slug_pl_pl":null,"_trp_automatically_translated_slug_es_es":null,"_trp_automatically_translated_slug_hu_hu":null,"_trp_automatically_translated_slug_fi":null,"_trp_automatically_translated_slug_ja":null,"_trp_automatically_translated_slug_lt_lt":null,"_elementor_edit_mode":null,"_elementor_template_type":null,"_elementor_version":null,"_elementor_pro_version":null,"_wp_page_template":null,"_elementor_page_settings":null,"_elementor_data":null,"_elementor_css":null,"_elementor_conditions":null,"_happyaddons_elements_cache":null,"_oembed_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_time_75446120c39305f0da0ccd147f6de9cb":null,"_oembed_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_time_3efb2c3e76a18143e7207993a2a6939a":null,"_oembed_59808117857ddf57e478a31d79f76e4d":null,"_oembed_time_59808117857ddf57e478a31d79f76e4d":null,"_oembed_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_time_965c5b49aa8d22ce37dfb3bde0268600":null,"_oembed_81002f7ee3604f645db4ebcfd1912acf":null,"_oembed_time_81002f7ee3604f645db4ebcfd1912acf":null,"_elementor_screenshot":null,"_oembed_7ea3429961cf98fa85da9747683af827":null,"_oembed_time_7ea3429961cf98fa85da9747683af827":null,"_elementor_controls_usage":null,"_elementor_page_assets":[],"_elementor_screenshot_failed":null,"theplus_transient_widgets":null,"_eael_custom_js":null,"_wp_old_date":null,"_trp_automatically_translated_slug_it_it":null,"_trp_automatically_translated_slug_pt_pt":null,"_trp_automatically_translated_slug_zh_cn":null,"_trp_automatically_translated_slug_nl_nl":null,"_trp_automatically_translated_slug_pt_br":null,"_trp_automatically_translated_slug_sv_se":null,"rank_math_analytic_object_id":null,"rank_math_internal_links_processed":"1","_trp_automatically_translated_slug_ro_ro":null,"_trp_automatically_translated_slug_sk_sk":null,"_trp_automatically_translated_slug_bg_bg":null,"_trp_automatically_translated_slug_sl_si":null,"litespeed_vpi_list":null,"litespeed_vpi_list_mobile":null,"rank_math_seo_score":null,"rank_math_contentai_score":null,"ilj_limitincominglinks":null,"ilj_maxincominglinks":null,"ilj_limitoutgoinglinks":null,"ilj_maxoutgoinglinks":null,"ilj_limitlinksperparagraph":null,"ilj_linksperparagraph":null,"ilj_blacklistdefinition":null,"ilj_linkdefinition":null,"_eb_reusable_block_ids":null,"rank_math_focus_keyword":"Redis Fragmentation","rank_math_og_content_image":null,"_yoast_wpseo_metadesc":null,"_yoast_wpseo_content_score":null,"_yoast_wpseo_focuskeywords":null,"_yoast_wpseo_keywordsynonyms":null,"_yoast_wpseo_estimated-reading-time-minutes":null,"rank_math_description":null,"surfer_last_post_update":null,"surfer_last_post_update_direction":null,"surfer_keywords":null,"surfer_location":null,"surfer_draft_id":null,"surfer_permalink_hash":null,"surfer_scrape_ready":null,"_thumbnail_id":"21284","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21291","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/comments?post=21291"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/21291\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/21284"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=21291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=21291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=21291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}