{"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":"gestion-de-memoria-de-redis-configuracion-optima-de-la-memoria-rendimiento-cache","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-memory-management-speicher-optimal-konfigurieren-performance-cache\/","title":{"rendered":"Gesti\u00f3n de la memoria en Redis: c\u00f3mo configurar la memoria de forma \u00f3ptima para obtener el m\u00e1ximo rendimiento"},"content":{"rendered":"<p>Configurar\u00e9 la memoria de Redis de manera que se pueda planificar: unos l\u00edmites claros, pol\u00edticas de expulsi\u00f3n adecuadas, tiempos de vida (TTL) bien definidos y una supervisi\u00f3n continua evitan picos de latencia y p\u00e9rdidas de datos. Esta gu\u00eda muestra ajustes concretos para <strong>memoria m\u00e1xima<\/strong>, Eviction, desfragmentaci\u00f3n y estructuras de datos, para que Redis funcione de forma segura y r\u00e1pida bajo carga.<\/p>\n\n<h2>Puntos centrales<\/h2>\n<ul>\n  <li><strong>memoria m\u00e1xima<\/strong> calcular de forma realista y establecerlo como l\u00edmite de seguridad<\/li>\n  <li><strong>Pol\u00edtica de desalojo<\/strong> elegir el patr\u00f3n de cach\u00e9 adecuado<\/li>\n  <li><strong>Dise\u00f1o TTL<\/strong> Combinar \u00abJitter\u00bb con \u00abStampedes\u00bb<\/li>\n  <li><strong>Desfragmentaci\u00f3n<\/strong> activar y comprobar los indicadores clave<\/li>\n  <li><strong>Monitoreo<\/strong> con alertas a partir de ~75 % de ocupaci\u00f3n %<\/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>Entender el almacenamiento en Redis: planificaci\u00f3n en lugar de corazonadas<\/h2>\n<p>Siempre preveo un presupuesto para almacenamiento que cubra los datos, <strong>Sobrecarga<\/strong> y la reserva. Adem\u00e1s de las claves y los valores, la replicaci\u00f3n, el b\u00fafer del cliente, la persistencia AOF\/RDB y las estructuras internas ocupan memoria RAM adicional. Quien solo tenga en cuenta el volumen de datos \u00fatiles subestima el espacio realmente ocupado y se arriesga a sufrir cuellos de botella. En primer lugar, calculo el conjunto de datos activos, a\u00f1ado una sobrecarga de 20-40 % en funci\u00f3n de las caracter\u00edsticas y reservo espacio adicional para el sistema operativo y las herramientas. De este modo, la instancia sigue siendo receptiva incluso en picos de carga y alcanza latencias consistentes.<\/p>\n\n<h2>Configurar correctamente maxmemory: definir el margen de maniobra<\/h2>\n<p>He puesto <strong>memoria m\u00e1xima<\/strong> Normalmente entre 50 y 75 % de la RAM del servidor, para que las cach\u00e9s del kernel, los agentes y el registro de logs tengan margen. En servidores dedicados exclusivamente a la cach\u00e9, suelo empezar con un valor de entre 70 y 75 %, mientras que en m\u00e1quinas compartidas soy m\u00e1s conservador. La configuraci\u00f3n se realiza en el archivo redis.conf (por ejemplo, \u201cmaxmemory 2gb\u201d) o en tiempo de ejecuci\u00f3n mediante \u201cCONFIG SET maxmemory 2gb\u201d. Una vez alcanzado el l\u00edmite, se aplica la pol\u00edtica de expulsi\u00f3n o las operaciones de escritura fallan, lo que utilizo deliberadamente como mecanismo de protecci\u00f3n. Quien ignore este l\u00edmite se expone a situaciones impredecibles de falta de memoria.<\/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>Elegir de forma selectiva las pol\u00edticas de desahucio<\/h2>\n<p>Me paso a la <strong>Desahucio<\/strong>-Adapta la pol\u00edtica al patr\u00f3n de acceso, ya que determina la tasa de aciertos y la estabilidad. En las cach\u00e9s cl\u00e1sicas, \u201callkeys-lru\u201d suele ser la mejor opci\u00f3n, ya que las claves que se utilizan con menos frecuencia son las primeras en eliminarse. En configuraciones con TTL fijos, \u201cvolatile-lru\u201d puede resultar adecuado, ya que solo se modifican las claves que est\u00e1n a punto de caducar. Solo utilizo pol\u00edticas aleatorias como \u201callkeys-random\u201d cuando no se dispone de datos de uso aprovechables. La pr\u00e1ctica demuestra que una pol\u00edtica clara, unos TTL bien definidos y un \u00abmaxmemory\u00bb realista generan un comportamiento predecible bajo presi\u00f3n.<\/p>\n\n<h3>LRU frente a LFU y ajuste preciso del muestreo<\/h3>\n<p>Cuando se trata de accesos muy sesgados, suelo optar por <strong>LFU<\/strong>-Pol\u00edticas (\u201callkeys-lfu\u201d o \u201cvolatile-lfu\u201d), ya que mantienen los archivos m\u00e1s utilizados de forma m\u00e1s estable en la cach\u00e9. A trav\u00e9s de <em>factor de registro lfu<\/em> ajusto la sensibilidad en funci\u00f3n de la frecuencia de acceso, con <em>tiempo de decaimiento de lfu<\/em> lo r\u00e1pido que se desvanece la \u201cpopularidad\u201d. Influye en LRU\/LFU <em>maxmemory-samples<\/em> La calidad de la selecci\u00f3n: 5 es el valor predeterminado; entre 10 y 15 mejora la decisi\u00f3n con un consumo moderado de CPU. Mido el impacto, ya que un mayor n\u00famero de muestras puede aumentar m\u00ednimamente la latencia, pero hace que las expulsiones sean m\u00e1s eficientes.<\/p>\n\n<h2>Estrategias de TTL para hacer frente a la presi\u00f3n sobre la memoria<\/h2>\n<p>Asigno a todas las claves de cach\u00e9 un <strong>TTL<\/strong>, para que las entradas obsoletas desaparezcan autom\u00e1ticamente. Establecer diferentes duraciones para p\u00e1ginas, objetos y sesiones permite mantener la memoria utilizable y aumenta la tasa de aciertos. Una peque\u00f1a proporci\u00f3n aleatoria por TTL evita las \u201cestampidas\u201d cuando caducan muchas claves al mismo tiempo. Quien utilice \u00abvolatile-*\u00bb debe asegurarse de que las claves relevantes tengan un TTL. Yo compruebo peri\u00f3dicamente los patrones de caducidad y ajusto los tiempos en funci\u00f3n de los datos reales de acceso.<\/p>\n\n<h3>Ajustar con precisi\u00f3n el \u00abActive-Expire-Effort\u00bb y los desencadenantes<\/h3>\n<p>A menudo aumento el valor de muchas claves TTL <em>active-expire-effort<\/em>, para que los escaneos en segundo plano eliminen r\u00e1pidamente las entradas caducadas sin bloquear el servidor. Lo combino con TTL ligeramente escalonados (jitter de 5 a 10 %), para evitar que caduquen todas a la vez y, con ello, que se produzca una avalancha repentina de reconstrucciones. En cargas de trabajo con objetos grandes que se consultan con poca frecuencia, activo <em>lazyfree-lazy-expire<\/em>, para que la liberaci\u00f3n de memoria se realice en segundo plano y as\u00ed evitar picos de latencia debidos a las operaciones de liberaci\u00f3n de memoria.<\/p>\n\n<h2>Reducir la fragmentaci\u00f3n: activedefrag y supervisi\u00f3n<\/h2>\n<p>Activo la opci\u00f3n activa <strong>Desfragmentaci\u00f3n<\/strong> en conjuntos de datos din\u00e1micos, para eliminar huecos de memoria. Un \u00edndice de fragmentaci\u00f3n claramente superior a 1,0 indica que se est\u00e1 ocupando m\u00e1s memoria RAM f\u00edsica de la necesaria. A partir de un valor aproximado de 1,4, eval\u00fao la situaci\u00f3n con m\u00e1s detalle y decido si es necesario realizar un ajuste fino de la desfragmentaci\u00f3n o una redistribuci\u00f3n de los datos. Las instancias que llevan mucho tiempo en ejecuci\u00f3n y con tama\u00f1os de clave muy variables se benefician de forma apreciable. De este modo, evito una ocupaci\u00f3n innecesaria de la memoria y mantengo estables las latencias.<\/p>\n\n<h3>Configurar correctamente Jemalloc y el sistema operativo<\/h3>\n<p>Me aseguro de que THP (Transparent Huge Pages) est\u00e9 desactivado y de que el servidor no utilice el espacio de intercambio, ya que ambas cosas empeoran la latencia. <em>vm.overcommit_memory=1<\/em> Evita fallos de bifurcaci\u00f3n en las reescrituras de RDB\/AOF; no obstante, preveo un margen adicional (10\u201330 %) para amortiguar los picos de \u00abcopy-on-write\u00bb. En Linux, ayuda <em>PURGA DE MEMORIA<\/em> De vez en cuando, ajustar el RSS al nivel real de uso. Para la desfragmentaci\u00f3n, prefiero <em>activedefrag-cycle-min\/max<\/em> y <em>activedefrag-ignore-bytes<\/em> para que el trabajo se desarrolle de forma constante, pero sin ser agresivo.<\/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 de forma eficiente las estructuras de datos y las codificaciones<\/h2>\n<p>Elijo los tipos de datos en funci\u00f3n del perfil de almacenamiento, no solo por comodidad, ya que cada byte <strong>cuenta<\/strong>. Los hash peque\u00f1os, las listas, los conjuntos y los conjuntos ordenados suelen beneficiarse de codificaciones compactas como listpack. Los valores muy grandes los divido en bloques manejables, para que las actualizaciones sigan siendo granulares y las expulsiones se apliquen con mayor precisi\u00f3n. Para campos grandes que se leen con poca frecuencia, utilizo la compresi\u00f3n de la aplicaci\u00f3n antes de escribirlos. Los nombres de clave cortos reducen la sobrecarga por entrada y su efecto se nota considerablemente cuando hay millones de claves.<\/p>\n<table>\n  <thead>\n    <tr>\n      <th>Tipo de datos<\/th>\n      <th>Utilice<\/th>\n      <th>Consejo sobre la codificaci\u00f3n<\/th>\n      <th>Nota sobre el almacenamiento<\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Cadena<\/td>\n      <td>Valores individuales, contadores<\/td>\n      <td>Directamente; si es necesario, compresi\u00f3n en la aplicaci\u00f3n<\/td>\n      <td><strong>Teclas grandes<\/strong> evitar la divisi\u00f3n de valores<\/td>\n    <\/tr>\n    <tr>\n      <td>Hash<\/td>\n      <td>Objetos con campos<\/td>\n      <td>listpack cuando hay pocos campos<\/td>\n      <td>Agrupar objetos peque\u00f1os, utilizar los campos con moderaci\u00f3n<\/td>\n    <\/tr>\n    <tr>\n      <td>Astucia<\/td>\n      <td>Colas, feeds<\/td>\n      <td>listpack para listas cortas<\/td>\n      <td>Limitar la duraci\u00f3n, utilizar el recorte<\/td>\n    <\/tr>\n    <tr>\n      <td>Set\/ZSet<\/td>\n      <td>Cifras, clasificaciones<\/td>\n      <td>listpack\/skiplist por tama\u00f1o<\/td>\n      <td>Segmentar colecciones grandes<\/td>\n    <\/tr>\n  <\/tbody>\n<\/table>\n<p>Compruebo peri\u00f3dicamente \u201credis-cli \u2013bigkeys\u201d para detectar valores at\u00edpicos y analizar el perfil de almacenamiento <strong>objetivo<\/strong> para optimizarla. De este modo, la instancia mantiene m\u00e1s datos relevantes en la RAM y procesa las solicitudes m\u00e1s r\u00e1pidamente.<\/p>\n\n<h3>Ajustar con precisi\u00f3n los valores l\u00edmite de codificaci\u00f3n<\/h3>\n<p>Compruebo <em>entradas de la lista hash-max-listpack\/valor<\/em>, <em>set-max-intset-entries<\/em> y <em>zset-max-listpack-entries\/valor<\/em>, para aprovechar al m\u00e1ximo las codificaciones de listas sin sobrecargar la CPU. Para las listas, utilizo <em>list-max-listpack-size<\/em> y <em>profundidad de compresi\u00f3n de la lista<\/em> la compresi\u00f3n. Limito los flujos con <em>stream-node-max-bytes\/entries<\/em>. En conjunto, estas medidas suelen suponer un ahorro de RAM de dos d\u00edgitos en porcentaje.<\/p>\n\n<h2>Supervisi\u00f3n y alertas: detecci\u00f3n temprana<\/h2>\n<p>Hago un seguimiento del porcentaje de memoria utilizada, las expulsiones, la tasa de aciertos de la cach\u00e9 y el \u00edndice de fragmentaci\u00f3n, porque <strong>Tendencias<\/strong> son m\u00e1s importantes que las lecturas puntuales. Si la carga de trabajo supera de forma permanente aproximadamente el 75 %, planifico ampliaciones de capacidad. Un aumento de la tasa de expulsi\u00f3n (eviction) junto con una disminuci\u00f3n de la tasa de aciertos (hit) indica pol\u00edticas incorrectas, tiempos de vida (TTL) demasiado cortos o un presupuesto insuficiente. Configurar\u00e9 alertas y correlacionar\u00e9 los picos con las implementaciones, los picos de tr\u00e1fico o los trabajos por lotes. De este modo, resolver\u00e9 las causas, en lugar de limitarme a mitigar los s\u00edntomas.<\/p>\n\n<h3>Diagn\u00f3stico del almacenamiento: m\u00e9tricas y comandos<\/h3>\n<p>Utilizo \u201cINFO memory\u201d, \u201cMEMORY STATS\u201d y \u201cMEMORY DOCTOR\u201d para detectar patrones. Con \u201cMEMORY USAGE key SAMPLES N\u201d determino la huella exacta de los objetos. Adem\u00e1s de \u201c\u2013bigkeys\u201d, utilizo \u201credis-cli \u2013memkeys\u201d y \u201c\u2013hotkeys\u201d, cuando est\u00e1n disponibles, para optimizar de forma espec\u00edfica las claves que consumen mucha memoria o que se consultan con especial frecuencia. \u201cLATENCY DOCTOR\u201d ayuda a determinar si las expulsiones, las desfragmentaciones o las bifurcaciones provocan picos de latencia.<\/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>Planificar la escalabilidad: vertical frente a cl\u00faster<\/h2>\n<p>Realizo un escalado vertical cuando algunos nodos necesitan m\u00e1s RAM o CPU, y un escalado horizontal cuando el sharding reduce la latencia y <strong>Capacidad<\/strong> mejor distribuido. Antes de las actualizaciones, ajusto los l\u00edmites, las instant\u00e1neas y la configuraci\u00f3n de las r\u00e9plicas para que la transici\u00f3n se realice sin una avalancha de expulsiones. Cuando el tr\u00e1fico var\u00eda mucho, un cl\u00faster ayuda a descargar la carga de las claves activas en varios nodos. Para escenarios de alojamiento, compruebo minuciosamente el aislamiento, por ejemplo, con <a href=\"https:\/\/webhosting.de\/es\/redis-compartido-frente-a-dedicado-rendimiento-seguridad-cacheboost\/\">Compartido vs. dedicado<\/a>. Una estrategia clara evita un sobredimensionamiento costoso y reduce los riesgos en caso de cambios de carga.<\/p>\n\n<h3>Reequilibrio y claves grandes en el cl\u00faster<\/h3>\n<p>Planifico las ventanas de reequilibrio de tal forma que las claves grandes no se migren ni se evac\u00faen al mismo tiempo. Las claves grandes sobrecargan la operaci\u00f3n MIGRATE y pueden hacer que los b\u00faferes de los clientes se saturen. Por eso, segmento los valores grandes a nivel de aplicaci\u00f3n, para que los desplazamientos entre cl\u00fasteres sean granulares y presenten un riesgo m\u00ednimo.<\/p>\n\n<h2>Redis en el entorno de alojamiento web: WordPress en la pr\u00e1ctica<\/h2>\n<p>En la pila de WordPress configuro tiempos de vida (TTL) claros para la cach\u00e9 de p\u00e1ginas, la cach\u00e9 de objetos y las sesiones, para que la memoria <strong>de f\u00e1cil agarre<\/strong> . Las configuraciones t\u00edpicas utilizan \u201cmaxmemory-policy allkeys-lru\u201d y un l\u00edmite de RAM de 60-75 %. En el caso de la cach\u00e9 de objetos, compruebo los nombres de las claves, ya que los prefijos extremadamente largos generan una sobrecarga apreciable. Abordo de forma sistem\u00e1tica los errores habituales relacionados con los prefijos, los TTL o las faltas de acierto; v\u00e9ase <a href=\"https:\/\/webhosting.de\/es\/error-de-configuracion-de-la-cache-de-objetos-redis-optimizacion-del-rendimiento-de-wordpress\/\">C\u00f3mo evitar errores en la cach\u00e9 de objetos<\/a>. La desfragmentaci\u00f3n activa estabiliza los sitios web de larga duraci\u00f3n con picos de tr\u00e1fico irregulares.<\/p>\n\n<h3>Clases TTL y prevenci\u00f3n de marcas<\/h3>\n<p>Defino clases de TTL (por ejemplo, p\u00e1ginas HTML con TTL corto, resultados de consultas con TTL medio y perfiles de usuario con TTL m\u00e1s largo) y asigno a cada clase un jitter de 5 a 15 %. Observo picos de errores tras las implementaciones: cuando se reconstruyen muchas cach\u00e9s al mismo tiempo, aumento temporalmente los TTL o utilizo tareas de calentamiento para nivelar la 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>Persistencia y replicaci\u00f3n: calcular el presupuesto de almacenamiento<\/h2>\n<p>Para AOF\/RDB y la replicaci\u00f3n, siempre tengo en cuenta un <strong>Memoria<\/strong>, ya que las instant\u00e1neas y los b\u00faferes de r\u00e9plica consumen RAM. Las instant\u00e1neas de gran tama\u00f1o pueden generar una presi\u00f3n sobre la memoria a corto plazo si se est\u00e1n ejecutando escrituras simult\u00e1neas. Quien utilice r\u00e9plicas debe tener en cuenta los picos de carga durante la resincronizaci\u00f3n y comprobar los tama\u00f1os de los b\u00faferes. Resumo los detalles sobre estrategias y compensaciones en la entrada sobre <a href=\"https:\/\/webhosting.de\/es\/guia-sobre-la-persistencia-de-redis-rdb-aof-y-servidores-de-alojamiento\/\">RDB y AOF<\/a> juntos. De este modo, la instancia sigue estando operativa incluso en caso de copias de seguridad y conmutaci\u00f3n por error.<\/p>\n\n<h3>Sobrecargas de bifurcaci\u00f3n, trabajo pendiente y autorizaci\u00f3n as\u00edncrona<\/h3>\n<p>Para las reescrituras de RDB\/AOF, preveo entre 10 y 30 % de RAM adicional debido al \u00abcopy-on-write\u00bb. <em>aof-use-rdb-pre\u00e1mbulo<\/em> acelera los reinicios, <em>auto-aof-rewrite-percentage\/size<\/em> controlar las reescrituras programables. Para la replicaci\u00f3n, dimensiono <em>tama\u00f1o-de-la-cola-de-respuestas<\/em> de modo que los problemas puntuales de la red no obliguen a realizar una resincronizaci\u00f3n completa. Yo utilizo <em>replica-ignore-maxmemory<\/em> deliberadamente, seg\u00fan el rol, para que las r\u00e9plicas no se desactualicen cuando se ponen al d\u00eda. En caso de eliminaciones masivas, activo <em>lazyfree-lazy-eviction<\/em> y <em>lazyfree-lazy-server-del<\/em>, con el fin de desacoplar la liberaci\u00f3n de memoria del momento cr\u00edtico de la 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>B\u00fafer del cliente y Pub\/Sub: establecer l\u00edmites estrictos<\/h2>\n<p>He puesto <em>l\u00edmite del b\u00fafer de salida del cliente<\/em> para <em>normal<\/em>, <em>r\u00e9plica<\/em> y <em>pubsub<\/em> de forma estricta, para que ning\u00fan cliente por s\u00ed solo provoque un error OOM en la instancia. Cuando hay mucho tr\u00e1fico de Pub\/Sub, configuro los b\u00faferes de Pub\/Sub de forma conservadora. Del mismo modo, mantengo <em>l\u00edmite del b\u00fafer de consultas del cliente<\/em> tengo en cuenta para evitar que algunas \u00f3rdenes grandes consuman memoria RAM de forma inesperada. En entornos multitenant, separo las cargas de trabajo en instancias independientes cuando el perfil de b\u00fafer var\u00eda considerablemente.<\/p>\n\n<h2>Configuraci\u00f3n concreta: un perfil de inicio resistente<\/h2>\n<p>Suelo empezar con el siguiente perfil y lo ajusto en funci\u00f3n de m\u00e9tricas reales:<\/p>\n<pre><code>maxmemory 70%\nmaxmemory-policy allkeys-lfu\nmaxmemory-samples 10\n\n# TTL\/Caducidad\nactive-expire-effort 7\nlazyfree-lazy-expire s\u00ed\n\n# Lazyfree para eliminaciones a gran escala\nlazyfree-lazy-eviction s\u00ed\nlazyfree-lazy-server-del s\u00ed\n\n# Desfragmentaci\u00f3n\nactivedefrag s\u00ed\nactivedefrag-ignore-bytes 100mb\nactivedefrag-cycle-min 10\nactivedefrag-cycle-max 50\n\n# Estructuras de datos\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# Replicaci\u00f3n\/B\u00fafer\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 que esto es un valor de referencia, no un dogma. Cada entorno tiene sus propios formatos de datos, patrones de tr\u00e1fico y m\u00e1rgenes de latencia.<\/p>\n\n<h2>Pruebas bajo carga: verificar en lugar de suponer<\/h2>\n<p>Compruebo las configuraciones con pruebas de carga realistas (por ejemplo, perfiles mixtos de GET\/SET\/EXPIRE) y, al hacerlo, observo las expulsiones, la tasa de aciertos, la latencia P99 y el \u00edndice de fragmentaci\u00f3n. Adem\u00e1s, simulo eventos como la reescritura AOF, la instant\u00e1nea RDB, la resincronizaci\u00f3n de r\u00e9plicas y las eliminaciones masivas, para medir el margen de capacidad y los efectos de \u00ablazyfree\u00bb. Solo cuando la ruta se mantiene estable durante los picos, implemento los cambios en producci\u00f3n.<\/p>\n\n<h2>Contenedores y multitenant: establecer l\u00edmites claros y bien definidos<\/h2>\n<p>He puesto <strong>memoria m\u00e1xima<\/strong> por debajo del l\u00edmite del contenedor, para que el OOM-Killer del cgroup no act\u00fae en primer lugar. A\u00edslo las cargas de trabajo con diferentes perfiles de b\u00fafer y TTL en instancias separadas, en lugar de mezclar bases de datos, ya que Redis comparte <em>memoria m\u00e1xima<\/em> no por base de datos. En Kubernetes, planifico el PodDisruptionBudget y las actualizaciones progresivas de tal forma que los calentamientos simult\u00e1neos no provoquen oleadas de expulsi\u00f3n.<\/p>\n\n<h2>Lista de comprobaci\u00f3n pr\u00e1ctica y puesta en pr\u00e1ctica<\/h2>\n<p>Empiezo con una clara <strong>Plan por pasos<\/strong>: El paso 1 determina el presupuesto de memoria, incluyendo la sobrecarga y la reserva; el paso 2 establece maxmemory entre 50 y 75 % y selecciona la pol\u00edtica adecuada; el paso 3 define los TTL con una variaci\u00f3n m\u00ednima para todas las claves de cach\u00e9; el paso 4 optimiza las estructuras de datos, divide las claves grandes y acorta los nombres; el paso 5 activa \u00abactivedefrag\u00bb y supervisa el \u00edndice de fragmentaci\u00f3n; el paso 6 configura m\u00e9tricas y alertas; el paso 7 comprueba de forma realista los picos de carga y planifica el escalado con antelaci\u00f3n. Mido cada cambio, en lugar de darlo por sentado. Solo as\u00ed puedo detectar avances reales. Este ritmo establece un modelo operativo fiable.<\/p>\n\n<h2>Conclusi\u00f3n: la memoria como herramienta activa para optimizar el rendimiento<\/h2>\n<p>Trato las memorias Redis como elementos controlables <strong>Palanca<\/strong> en cuanto a latencia, rendimiento y fiabilidad. Quien establezca l\u00edmites de forma clara, elija pol\u00edticas de forma consciente y utilice los TTL de manera sistem\u00e1tica, obtendr\u00e1 un comportamiento predecible incluso bajo presi\u00f3n. La supervisi\u00f3n, el control de la fragmentaci\u00f3n y los tipos de datos estructurados permiten sacar un mayor rendimiento de la misma memoria RAM. La escalabilidad se convierte as\u00ed en un paso planificado, no en un recurso de emergencia. De este modo, la memoria de Redis sigue siendo manejable, la tasa de aciertos de la cach\u00e9 se mantiene alta y la aplicaci\u00f3n sigue siendo r\u00e1pida, desde un proyecto peque\u00f1o hasta una plataforma muy concurrida.<\/p>","protected":false},"excerpt":{"rendered":"<p>Gu\u00eda pr\u00e1ctica sobre la gesti\u00f3n de la memoria en Redis: c\u00f3mo configurar la memoria de forma \u00f3ptima, incluyendo maxmemory, pol\u00edticas de expulsi\u00f3n y supervisi\u00f3n, con especial atenci\u00f3n a la memoria de Redis para obtener el m\u00e1ximo rendimiento.<\/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":"122","_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\/es\/wp-json\/wp\/v2\/posts\/20116","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/comments?post=20116"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/20116\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/20109"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=20116"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=20116"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=20116"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}