{"id":20116,"date":"2026-07-29T08:34:12","date_gmt":"2026-07-29T06:34:12","guid":{"rendered":"https:\/\/webhosting.de\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/"},"modified":"2026-07-29T08:34:12","modified_gmt":"2026-07-29T06:34:12","slug":"gestao-de-memoria-do-redis-configurar-a-memoria-de-forma-otimizada-desempenho-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/pt\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/","title":{"rendered":"Gest\u00e3o de mem\u00f3ria do Redis \u2013 Configurar a mem\u00f3ria de forma otimizada para obter o m\u00e1ximo desempenho"},"content":{"rendered":"<p>Configurei a mem\u00f3ria do Redis de forma a garantir a previsibilidade: limites claros, pol\u00edticas de evic\u00e7\u00e3o adequadas, TTLs bem definidos e monitoriza\u00e7\u00e3o cont\u00ednua evitam picos de lat\u00eancia e perdas de dados. Este guia apresenta configura\u00e7\u00f5es concretas para <strong>mem\u00f3ria m\u00e1xima<\/strong>, Eviction, desfragmenta\u00e7\u00e3o e estruturas de dados, para que o Redis funcione de forma segura e r\u00e1pida sob carga.<\/p>\n\n<h2>Pontos centrais<\/h2>\n<ul>\n  <li><strong>mem\u00f3ria m\u00e1xima<\/strong> fazer um c\u00e1lculo realista e estabelecer esse valor como limite de seguran\u00e7a<\/li>\n  <li><strong>Pol\u00edtica de despejo<\/strong> escolher de acordo com o padr\u00e3o do cache<\/li>\n  <li><strong>Conce\u00e7\u00e3o TTL<\/strong> Combinar o Jitter com o Stampedes<\/li>\n  <li><strong>Desfragmenta\u00e7\u00e3o<\/strong> ativar e verificar os indicadores<\/li>\n  <li><strong>Monitoriza\u00e7\u00e3o<\/strong> com alertas a partir de ~75 % de utiliza\u00e7\u00e3o do %<\/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\/07\/redis-speicher-management-6823.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Compreender o armazenamento Redis: planeamento em vez de intui\u00e7\u00e3o<\/h2>\n<p>Planeio sempre um or\u00e7amento de armazenamento que inclua dados, <strong>Despesas gerais<\/strong> e a reserva. Para al\u00e9m das chaves e dos valores, a replica\u00e7\u00e3o, o buffer do cliente, a persist\u00eancia AOF\/RDB e as estruturas internas ocupam mem\u00f3ria RAM adicional. Quem considerar apenas o volume de dados \u00fateis subestima a ocupa\u00e7\u00e3o real e corre o risco de enfrentar gargalos. Come\u00e7o por calcular o conjunto de dados ativo, acrescento uma sobrecarga de 20\u201340 %, dependendo das funcionalidades, e reservo espa\u00e7o adicional para o sistema operativo e as ferramentas. Desta forma, a inst\u00e2ncia mant\u00e9m-se responsiva mesmo em picos de carga e alcan\u00e7a lat\u00eancias consistentes.<\/p>\n\n<h2>Definir corretamente o maxmemory: definir a margem de manobra<\/h2>\n<p>Eu fixo <strong>mem\u00f3ria m\u00e1xima<\/strong> normalmente entre 50 e 75 % da mem\u00f3ria RAM do servidor, para que as caches do kernel, os agentes e o registo de logs tenham espa\u00e7o suficiente. Em hosts dedicados exclusivamente ao cache, costumo come\u00e7ar com 70\u201375 %; em m\u00e1quinas partilhadas, sou mais conservador. A configura\u00e7\u00e3o \u00e9 feita no ficheiro redis.conf (por exemplo, \u201cmaxmemory 2gb\u201d) ou em tempo de execu\u00e7\u00e3o atrav\u00e9s de \u201cCONFIG SET maxmemory 2gb\u201d. A partir desse limite, a pol\u00edtica de evic\u00e7\u00e3o entra em a\u00e7\u00e3o ou as opera\u00e7\u00f5es de grava\u00e7\u00e3o falham, o que utilizo deliberadamente como mecanismo de prote\u00e7\u00e3o. Quem ignorar este limite arrisca-se a situa\u00e7\u00f5es imprevis\u00edveis de falta de mem\u00f3ria.<\/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\/07\/redis_memory_mgmt_setup_4821.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Escolher de forma seletiva as pol\u00edticas de despejo<\/h2>\n<p>Eu passo a <strong>Despejo<\/strong>-A pol\u00edtica deve ser adaptada ao padr\u00e3o de acesso, pois determina a taxa de acertos e a estabilidade. Para caches cl\u00e1ssicas, a pol\u00edtica \u201callkeys-lru\u201d costuma ser a mais eficaz, uma vez que as chaves raramente utilizadas s\u00e3o eliminadas em primeiro lugar. Em configura\u00e7\u00f5es com TTLs consistentes, a pol\u00edtica \u201cvolatile-lru\u201d pode fazer sentido, uma vez que apenas as chaves que est\u00e3o prestes a expirar s\u00e3o afetadas. S\u00f3 utilizo pol\u00edticas aleat\u00f3rias, como \u201callkeys-random\u201d, quando n\u00e3o h\u00e1 dados de utiliza\u00e7\u00e3o que possam ser aproveitados. A pr\u00e1tica demonstra que uma pol\u00edtica clara, TTLs bem definidos e um valor realista para \u00abmaxmemory\u00bb geram um comportamento previs\u00edvel sob carga.<\/p>\n\n<h3>LRU vs. LFU e ajuste preciso da amostragem<\/h3>\n<p>Quando se trata de acessos fortemente assim\u00e9tricos, costumo optar por <strong>LFU<\/strong>-Pol\u00edticas (\u201callkeys-lfu\u201d ou \u201cvolatile-lfu\u201d), porque mant\u00eam os ficheiros mais frequentemente utilizados de forma mais robusta na cache. Atrav\u00e9s de <em>lfu-log-factor<\/em> controlo a sensibilidade em rela\u00e7\u00e3o \u00e0 frequ\u00eancia de acesso, com <em>lfu-decay-time<\/em> a rapidez com que a \u201cpopularidade\u201d se desvanece. Para o LRU\/LFU, isso influencia <em>maxmemory-samples<\/em> A qualidade da sele\u00e7\u00e3o: 5 \u00e9 o padr\u00e3o; 10\u201315 melhora a decis\u00e3o com um consumo moderado de CPU. Estou a avaliar os efeitos, uma vez que um n\u00famero mais elevado de amostras pode aumentar minimamente a lat\u00eancia, mas torna as evic\u00e7\u00f5es mais eficientes.<\/p>\n\n<h2>Estrat\u00e9gias da TTL para combater a press\u00e3o sobre a mem\u00f3ria<\/h2>\n<p>Atribuo a todas as chaves de cache um <strong>TTL<\/strong>, para que as entradas desatualizadas desapare\u00e7am automaticamente. Tempos de vida diferentes para p\u00e1ginas, objetos e sess\u00f5es mant\u00eam a mem\u00f3ria utiliz\u00e1vel e aumentam a taxa de acertos. Uma pequena percentagem aleat\u00f3ria por TTL evita \u201cstampedes\u201d quando muitas chaves expiram simultaneamente. Quem utiliza \u00abvolatile-*\u00bb deve certificar-se de que as chaves relevantes possuem, de facto, um TTL. Verifico regularmente os padr\u00f5es de expira\u00e7\u00e3o e ajusto os tempos de acordo com os dados reais de acesso.<\/p>\n\n<h3>Ajustar com precis\u00e3o o esfor\u00e7o de expira\u00e7\u00e3o ativa e os gatilhos<\/h3>\n<p>Costumo aumentar o valor de muitas chaves TTL <em>active-expire-effort<\/em>, para que as verifica\u00e7\u00f5es em segundo plano removam rapidamente as entradas expiradas, sem bloquear o servidor. Combino isto com TTLs ligeiramente desfasados (jitter de 5\u201310 %), para evitar que as entradas expirem simultaneamente e, consequentemente, que se verifique uma onda repentina de reconstru\u00e7\u00f5es. Em cargas de trabalho com objetos grandes e raramente lidos, ativo <em>lazyfree-lazy-expire<\/em>, para realizar a liberta\u00e7\u00e3o de mem\u00f3ria em segundo plano e evitar picos de lat\u00eancia causados pelo trabalho de liberta\u00e7\u00e3o de mem\u00f3ria.<\/p>\n\n<h2>Reduzir a fragmenta\u00e7\u00e3o: activedefrag e monitoriza\u00e7\u00e3o<\/h2>\n<p>Ativo a op\u00e7\u00e3o ativa <strong>Desfragmenta\u00e7\u00e3o<\/strong> em conjuntos de dados din\u00e2micos, para colmatar lacunas de mem\u00f3ria. Um r\u00e1cio de fragmenta\u00e7\u00e3o significativamente superior a 1,0 indica que est\u00e1 a ser utilizada mais mem\u00f3ria RAM f\u00edsica do que o necess\u00e1rio. A partir de valores cerca de 1,4, analiso a situa\u00e7\u00e3o com mais detalhe e decido se devo proceder a um ajuste fino da desfragmenta\u00e7\u00e3o ou \u00e0 redistribui\u00e7\u00e3o dos dados. As inst\u00e2ncias em execu\u00e7\u00e3o h\u00e1 muito tempo, com tamanhos de chave altamente vari\u00e1veis, beneficiam de forma mensur\u00e1vel. Desta forma, evito a ocupa\u00e7\u00e3o desnecess\u00e1ria de mem\u00f3ria e mantenho as lat\u00eancias est\u00e1veis.<\/p>\n\n<h3>Configurar corretamente o Jemalloc e o sistema operativo<\/h3>\n<p>Certifico-me de que o THP (Transparent Huge Pages) est\u00e1 desativado e de que o servidor n\u00e3o utiliza a mem\u00f3ria de swap, pois ambos prejudicam a lat\u00eancia. <em>vm.overcommit_memory=1<\/em> evita falhas de bifurca\u00e7\u00e3o nas reescritas RDB\/AOF; no entanto, prevejo uma margem adicional (10\u201330 %) para amortecer picos de \u00abcopy-on-write\u00bb. No Linux, ajuda <em>LIMPEZA DA MEM\u00d3RIA<\/em> ocasionalmente, ajustar o RSS ao n\u00edvel real de utiliza\u00e7\u00e3o. Para a desfragmenta\u00e7\u00e3o, prefiro <em>activedefrag-cycle-min\/max<\/em> e <em>activedefrag-ignore-bytes<\/em> para que o trabalho decorra de forma constante, mas n\u00e3o agressiva.<\/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\/07\/redis-memory-optimization-6382.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Utilizar estruturas de dados e codifica\u00e7\u00f5es de forma eficiente<\/h2>\n<p>Escolho os tipos de dados com base no perfil de mem\u00f3ria, e n\u00e3o apenas por conveni\u00eancia, pois cada byte <strong>contagens<\/strong>. Hashes pequenos, listas, conjuntos e conjuntos ordenados beneficiam frequentemente de codifica\u00e7\u00f5es compactas, como o listpack. Divido valores muito grandes em blocos mais f\u00e1ceis de gerir, para que as atualiza\u00e7\u00f5es se mantenham granulares e as evic\u00e7\u00f5es sejam mais precisas. Para campos grandes que raramente s\u00e3o lidos, utilizo a compress\u00e3o na aplica\u00e7\u00e3o antes da grava\u00e7\u00e3o. Nomes de chaves curtos reduzem a sobrecarga por entrada e t\u00eam um impacto not\u00e1vel quando se trata de milh\u00f5es de chaves.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tipo de dados<\/th>\n      <th>Utiliza\u00e7\u00e3o<\/th>\n      <th>Dica de codifica\u00e7\u00e3o<\/th>\n      <th>Nota sobre a mem\u00f3ria<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>String<\/td>\n      <td>Valores individuais, contadores<\/td>\n      <td>Diretamente, com compress\u00e3o na aplica\u00e7\u00e3o, se for o caso<\/td>\n      <td><strong>Teclas Grandes<\/strong> evitar a divis\u00e3o de valores<\/td>\n    <\/tr>\n    <tr>\n      <td>Haxixe<\/td>\n      <td>Objetos com campos<\/td>\n      <td>listpack quando h\u00e1 poucos campos<\/td>\n      <td>Agrupar objetos pequenos, utilizar campos com modera\u00e7\u00e3o<\/td>\n    <\/tr>\n    <tr>\n      <td>Ast\u00facia<\/td>\n      <td>Filas, feeds<\/td>\n      <td>listpack para listas curtas<\/td>\n      <td>Limitar a dura\u00e7\u00e3o, utilizar o recorte<\/td>\n    <\/tr>\n    <tr>\n      <td>Conjunto\/ZConjunto<\/td>\n      <td>Quantidades, classifica\u00e7\u00f5es<\/td>\n      <td>listpack\/skiplist por tamanho<\/td>\n      <td>Segmentar grandes cole\u00e7\u00f5es<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Verifico regularmente o comando \u201credis-cli \u2013bigkeys\u201d para identificar valores at\u00edpicos e analisar o perfil de mem\u00f3ria <strong>direcionado<\/strong> para otimizar. Desta forma, a inst\u00e2ncia mant\u00e9m mais dados relevantes na RAM e processa os pedidos mais rapidamente.<\/p>\n\n<h3>Ajustar com precis\u00e3o os valores-limite de codifica\u00e7\u00e3o<\/h3>\n<p>Eu controlo <em>hash-max-listpack-entries\/valor<\/em>, <em>set-max-intset-entries<\/em> e <em>zset-max-listpack-entries\/valor<\/em>, para aproveitar as codifica\u00e7\u00f5es Listpack o m\u00e1ximo poss\u00edvel, sem sobrecarregar a CPU. Para as listas, controlo com <em>list-max-listpack-size<\/em> e <em>profundidade de compress\u00e3o da lista<\/em> a compacta\u00e7\u00e3o. Limito os fluxos com <em>stream-node-max-bytes\/entries<\/em>. No total, estas medidas permitem, muitas vezes, uma redu\u00e7\u00e3o do consumo de RAM na ordem dos dois d\u00edgitos.<\/p>\n\n<h2>Monitoriza\u00e7\u00e3o e alertas: dete\u00e7\u00e3o precoce<\/h2>\n<p>Acompanho a percentagem de mem\u00f3ria utilizada, as evacua\u00e7\u00f5es, a taxa de acertos da cache e o r\u00e1cio de fragmenta\u00e7\u00e3o, porque <strong>Tend\u00eancias<\/strong> s\u00e3o mais importantes do que instant\u00e2neos. Se a utiliza\u00e7\u00e3o ultrapassar de forma sustentada cerca de 75 %, planeio amplia\u00e7\u00f5es de capacidade. Uma taxa de evic\u00e7\u00e3o crescente, acompanhada por uma taxa de acertos em queda, indica pol\u00edticas incorretas, TTLs demasiado curtas ou um or\u00e7amento insuficiente. Defino alertas e correlaciono os picos com implementa\u00e7\u00f5es, picos de tr\u00e1fego ou tarefas em lote. Desta forma, resolvo as causas, em vez de me limitar a atenuar os sintomas.<\/p>\n\n<h3>Diagn\u00f3stico da mem\u00f3ria: m\u00e9tricas e comandos<\/h3>\n<p>Utilizo o \u201cINFO memory\u201d, o \u201cMEMORY STATS\u201d e o \u201cMEMORY DOCTOR\u201d para identificar padr\u00f5es. Com o comando \u201cMEMORY USAGE key SAMPLES N\u201d, determino a pegada exata dos objetos. Para al\u00e9m de \u201c\u2013bigkeys\u201d, utilizo \u201credis-cli \u2013memkeys\u201d e \u201c\u2013hotkeys\u201d, quando dispon\u00edveis, para otimizar de forma espec\u00edfica as chaves que consomem muita mem\u00f3ria ou que s\u00e3o consultadas com especial frequ\u00eancia. O \u201cLATENCY DOCTOR\u201d ajuda a determinar se as evic\u00e7\u00f5es, as desfragmenta\u00e7\u00f5es ou os forks est\u00e3o a causar picos de lat\u00eancia.<\/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\/07\/redis_speicherverwaltung_5683.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Planear a escalabilidade: vertical vs. cluster<\/h2>\n<p>Fa\u00e7o o escalonamento vertical quando determinados n\u00f3s precisam de mais RAM ou CPU, e o escalonamento horizontal quando o sharding reduz a lat\u00eancia e <strong>Capacidade<\/strong> melhor distribu\u00eddo. Antes das atualiza\u00e7\u00f5es, ajusto os limites, os instant\u00e2neos e as configura\u00e7\u00f5es das r\u00e9plicas, para que a transi\u00e7\u00e3o ocorra sem uma onda de evic\u00e7\u00e3o. Em caso de tr\u00e1fego muito vari\u00e1vel, um cluster ajuda a distribuir a carga das \u00abhot keys\u00bb por v\u00e1rios n\u00f3s. Em cen\u00e1rios de alojamento, verifico cuidadosamente o isolamento, por exemplo, com <a href=\"https:\/\/webhosting.de\/pt\/redis-partilhado-vs-dedicado-desempenho-seguranca-cacheboost\/\">Partilhado vs. dedicado<\/a>. Uma estrat\u00e9gia clara evita um sobredimensionamento dispendioso e reduz os riscos em caso de varia\u00e7\u00f5es de carga.<\/p>\n\n<h3>Reequil\u00edbrio e chaves de grande dimens\u00e3o no cluster<\/h3>\n<p>Planeio as janelas de reequil\u00edbrio de forma a que as chaves de grande dimens\u00e3o n\u00e3o sejam migradas e removidas simultaneamente. As chaves de grande dimens\u00e3o sobrecarregam o comando MIGRATE e podem fazer aumentar os buffers do cliente. Por isso, segmento os valores de grande dimens\u00e3o ao n\u00edvel da aplica\u00e7\u00e3o, para que as transfer\u00eancias entre clusters se mantenham granulares e com baixo risco.<\/p>\n\n<h2>O Redis no ambiente de alojamento: WordPress na pr\u00e1tica<\/h2>\n<p>Defino TTLs claras na pilha do WordPress para a cache de p\u00e1ginas, a cache de objetos e as sess\u00f5es, para que a mem\u00f3ria <strong>f\u00e1cil de segurar<\/strong> permanece. As configura\u00e7\u00f5es t\u00edpicas utilizam \u201cmaxmemory-policy allkeys-lru\u201d e um limite de 60\u201375 % de RAM. No que diz respeito \u00e0 cache de objetos, verifico os nomes das chaves, uma vez que os prefixos extremamente longos geram uma sobrecarga percet\u00edvel. Abordo sistematicamente os erros frequentes relacionados com prefixa\u00e7\u00e3o, TTLs ou falhas; consulte <a href=\"https:\/\/webhosting.de\/pt\/erro-de-configuracao-do-cache-de-objetos-do-redis-otimizacao-do-desempenho-do-wordpress\/\">Evitar erros no cache de objetos<\/a>. A desfragmenta\u00e7\u00e3o ativa estabiliza sites de longa dura\u00e7\u00e3o com picos de tr\u00e1fego irregulares.<\/p>\n\n<h3>Classes TTL e preven\u00e7\u00e3o de marcas<\/h3>\n<p>Defino classes de TTL (por exemplo, p\u00e1ginas HTML com TTL curto, resultados de consultas com TTL m\u00e9dio, perfis de utilizador com TTL mais longo) e atribuo a cada classe um jitter de 5\u201315 %. Observo picos de erros ap\u00f3s as implementa\u00e7\u00f5es: quando muitas caches s\u00e3o recriadas simultaneamente, aumentei temporariamente os TTLs ou utilizo tarefas de aquecimento para nivelar a carga.<\/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\/07\/redis_memory_5381.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Persist\u00eancia e replica\u00e7\u00e3o: calcular o or\u00e7amento de armazenamento<\/h2>\n<p>Para o AOF\/RDB e a replica\u00e7\u00e3o, tenho sempre em conta um <strong>Mem\u00f3ria<\/strong>, porque os instant\u00e2neos e os buffers de r\u00e9plica consomem RAM. Instant\u00e2neos de grande dimens\u00e3o podem causar press\u00e3o na mem\u00f3ria a curto prazo, caso estejam a decorrer grava\u00e7\u00f5es simult\u00e2neas. Quem utiliza r\u00e9plicas deve ter em conta os picos de carga durante a ressincroniza\u00e7\u00e3o e verificar os tamanhos dos buffers. Resumo os detalhes sobre estrat\u00e9gias e compromissos no artigo sobre <a href=\"https:\/\/webhosting.de\/pt\/guia-sobre-persistencia-rdb-e-aof-no-redis-para-servidores-de-alojamento\/\">RDB e AOF<\/a> em conjunto. Desta forma, a inst\u00e2ncia mant\u00e9m a sua capacidade de resposta mesmo em caso de eventos de c\u00f3pia de seguran\u00e7a e de failover.<\/p>\n\n<h3>Overheads de bifurca\u00e7\u00e3o, backlog e aprova\u00e7\u00e3o ass\u00edncrona<\/h3>\n<p>Para as reescritas RDB\/AOF, prevejo 10\u201330 % de RAM adicional devido ao \u00abCopy-on-Write\u00bb. <em>aof-use-rdb-pre\u00e2mbulo<\/em> acelera os rein\u00edcios, <em>auto-aof-rewrite-percentage\/size<\/em> controlar as reescritas program\u00e1veis. Para a replica\u00e7\u00e3o, dimensiono <em>tamanho-da-filha-de-respostas<\/em> de forma a que eventuais problemas moment\u00e2neos na rede n\u00e3o obriguem a uma ressincroniza\u00e7\u00e3o completa. Eu defino <em>replica-ignore-maxmemory<\/em> deletando deliberadamente, consoante a fun\u00e7\u00e3o, para que as r\u00e9plicas n\u00e3o sejam eliminadas enquanto est\u00e3o a recuperar o atraso. Em caso de elimina\u00e7\u00f5es em massa, ativo <em>evic\u00e7\u00e3o pregui\u00e7osa-pregui\u00e7osa<\/em> e <em>servidor-lazyfree-lazy-del<\/em>, para dissociar a liberta\u00e7\u00e3o de mem\u00f3ria do momento cr\u00edtico da consulta.<\/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\/07\/redis-speicheroptimum-1834.png\" alt=\"\" width=\"1536\" height=\"1024\"\/>\n<\/figure>\n\n\n<h2>Buffer do cliente e Pub\/Sub: definir limites r\u00edgidos<\/h2>\n<p>Eu fixo <em>limite do buffer de sa\u00edda do cliente<\/em> para <em>normal<\/em>, <em>r\u00e9plica<\/em> e <em>pubsub<\/em> de forma rigorosa, para que nenhum cliente isolado leve a inst\u00e2ncia ao estado de OOM. Quando h\u00e1 muito tr\u00e1fego Pub\/Sub, calibro os buffers Pub\/Sub de forma conservadora. Da mesma forma, mantenho <em>limite-do-buffer-de-consultas-do-cliente<\/em> tenho isso em conta, para que comandos individuais de grande dimens\u00e3o n\u00e3o ocupem mem\u00f3ria RAM de forma inesperada. Em ambientes multi-tenant, separo as cargas de trabalho em inst\u00e2ncias pr\u00f3prias quando o perfil de buffer varia significativamente.<\/p>\n\n<h2>Configura\u00e7\u00e3o concreta: um perfil de arranque robusto<\/h2>\n<p>Costumo come\u00e7ar com o seguinte perfil e ajust\u00e1-lo com base em m\u00e9tricas reais:<\/p>\n<pre><code>maxmemory 70%\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\n\n# TTL\/Expire\nactive-expire-effort 7\nlazyfree-lazy-expire sim\n\n# Lazyfree para grandes elimina\u00e7\u00f5es\nlazyfree-lazy-eviction sim\nlazyfree-lazy-server-del sim\n\n# Desfragmenta\u00e7\u00e3o\nactivedefrag sim\nactivedefrag-ignore-bytes 100mb\nactivedefrag-cycle-min 10\nactivedefrag-cycle-max 50\n\n# Estruturas de dados\nhash-max-listpack-entries 512\nhash-max-listpack-value 256\nzset-max-listpack-entries 512\nzset-max-listpack-value 128\nset-max-intset-entries 512\nlist-max-listpack-size -2\nlist-compress-depth 1\n\n# Replica\u00e7\u00e3o\/Buffer\nrepl-backlog-size 256mb\nclient-output-buffer-limit normal 0 0 0\nclient-output-buffer-limit replica 256mb 64mb 60\nclient-output-buffer-limit pubsub 64mb 16mb 60\n<\/code><\/pre>\n<p>Considero isto um ponto de partida, n\u00e3o um dogma. Cada ambiente tem os seus pr\u00f3prios formatos de dados, padr\u00f5es de tr\u00e1fego e limites de lat\u00eancia.<\/p>\n\n<h2>Testes sob carga: verificar em vez de supor<\/h2>\n<p>Testo as configura\u00e7\u00f5es com testes de carga realistas (por exemplo, perfis mistos de GET\/SET\/EXPIRE), observando, ao mesmo tempo, as evi\u00e7\u00f5es, a taxa de acertos, a lat\u00eancia P99 e o r\u00e1cio de fragmenta\u00e7\u00e3o. Simulo tamb\u00e9m eventos como reescrita AOF, instant\u00e2neo RDB, ressincroniza\u00e7\u00e3o de r\u00e9plicas e elimina\u00e7\u00f5es em massa, para medir a margem de seguran\u00e7a e os efeitos do Lazyfree. S\u00f3 quando o caminho se mant\u00e9m est\u00e1vel durante os picos \u00e9 que implemento as altera\u00e7\u00f5es em produ\u00e7\u00e3o.<\/p>\n\n<h2>Contentores e multi-tenant: definir limites claros<\/h2>\n<p>Eu fixo <strong>mem\u00f3ria m\u00e1xima<\/strong> abaixo do limite do contentor, para que o OOM-Killer do Cgroup n\u00e3o entre em a\u00e7\u00e3o primeiro. Isolamos cargas de trabalho com perfis de buffer e TTL diferentes em inst\u00e2ncias separadas, em vez de misturar bases de dados \u2013 pois o Redis partilha <em>mem\u00f3ria m\u00e1xima<\/em> n\u00e3o por base de dados. No Kubernetes, planeio o PodDisruptionBudget e as atualiza\u00e7\u00f5es cont\u00ednuas de forma a que nenhum aquecimento simult\u00e2neo provoque ondas de evic\u00e7\u00e3o.<\/p>\n\n<h2>Lista de verifica\u00e7\u00e3o pr\u00e1tica e implementa\u00e7\u00e3o<\/h2>\n<p>Come\u00e7o com uma clara <strong>Plano por etapas<\/strong>: O Passo 1 determina o or\u00e7amento de mem\u00f3ria, incluindo sobrecarga e reserva; o Passo 2 define o `maxmemory` para 50\u201375 % e seleciona a pol\u00edtica adequada; o Passo 3 define TTLs com baixo jitter para todas as chaves da cache; O passo 4 otimiza as estruturas de dados, divide as \u00abBig Keys\u00bb e encurta os nomes; o passo 5 ativa o \u00abactivedefrag\u00bb e monitoriza a taxa de fragmenta\u00e7\u00e3o; o passo 6 configura m\u00e9tricas e alarmes; o passo 7 testa picos de carga de forma realista e planeia a escalabilidade atempadamente. Medei cada altera\u00e7\u00e3o, em vez de me basear em suposi\u00e7\u00f5es. S\u00f3 assim consigo identificar progressos reais. Este ritmo estabelece um modelo operacional fi\u00e1vel.<\/p>\n\n<h2>Conclus\u00e3o: A mem\u00f3ria como ferramenta ativa de otimiza\u00e7\u00e3o do desempenho<\/h2>\n<p>Trato as mem\u00f3rias do Redis como control\u00e1veis <strong>Alavanca<\/strong> em termos de lat\u00eancia, d\u00e9bito e fiabilidade. Quem define limites de forma clara, escolhe pol\u00edticas de forma consciente e utiliza os TTLs de forma consistente, obt\u00e9m um comportamento previs\u00edvel em situa\u00e7\u00f5es de carga elevada. A monitoriza\u00e7\u00e3o, o controlo da fragmenta\u00e7\u00e3o e os tipos de dados estruturados permitem tirar partido de capacidade adicional da mesma mem\u00f3ria RAM. A escalabilidade funciona ent\u00e3o como uma medida planeada, e n\u00e3o como um recurso de emerg\u00eancia. Desta forma, a mem\u00f3ria do Redis permanece control\u00e1vel, a taxa de acertos na cache mant\u00e9m-se elevada e a aplica\u00e7\u00e3o continua r\u00e1pida \u2014 desde um projeto de pequena dimens\u00e3o at\u00e9 uma plataforma com elevado tr\u00e1fego.<\/p>","protected":false},"excerpt":{"rendered":"<p>Guia pr\u00e1tico para a gest\u00e3o de mem\u00f3ria do Redis: como configurar a mem\u00f3ria de forma ideal, incluindo maxmemory, pol\u00edticas de evic\u00e7\u00e3o e monitoriza\u00e7\u00e3o \u2013 com foco na mem\u00f3ria do Redis para obter o m\u00e1ximo desempenho.<\/p>","protected":false},"author":1,"featured_media":20109,"comment_status":"","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"inline_featured_image":false,"footnotes":""},"categories":[781],"tags":[],"class_list":["post-20116","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":"126","_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 memory","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":"20109","footnotes":null,"_links":{"self":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20116","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=20116"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/posts\/20116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media\/20109"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/media?parent=20116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/categories?post=20116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/pt\/wp-json\/wp\/v2\/tags?post=20116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}