{"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":"como-interpretar-correctamente-el-indice-de-fragmentacion-de-la-memoria-de-redis-analisis-de-la-memoria","status":"publish","type":"post","link":"https:\/\/webhosting.de\/es\/redis-memory-fragmentation-ratio-richtig-interpretieren-speicheranalyse\/","title":{"rendered":"C\u00f3mo interpretar correctamente y optimizar el \u00edndice de fragmentaci\u00f3n de memoria de Redis"},"content":{"rendered":"<p><strong>Fragmentaci\u00f3n de Redis<\/strong> determina cu\u00e1nta memoria se pierde entre la RSS asignada por el sistema operativo y los datos de Redis realmente utilizados, y c\u00f3mo puedo evitar la latencia, el intercambio y las ca\u00eddas del sistema. Te explico el <strong>\u00cdndice de fragmentaci\u00f3n de memoria de Redis<\/strong> orientado a la pr\u00e1ctica, muestra valores l\u00edmite razonables y ofrece medidas claras para el ajuste, la supervisi\u00f3n y la modelizaci\u00f3n de datos.<\/p>\n\n<h2>Puntos centrales<\/h2>\n\n<ul>\n  <li><strong>Definici\u00f3n de<\/strong>: Interpretar correctamente la relaci\u00f3n entre \u00abused_memory_rss\u00bb y \u00abused_memory\u00bb.<\/li>\n  <li><strong>Valores l\u00edmite<\/strong>: Actuar a partir de 1,5; por debajo de 1,0, comprobar de inmediato.<\/li>\n  <li><strong>Causas<\/strong>: Tama\u00f1os variables de los objetos, oleadas de extinci\u00f3n, tiempos de ejecuci\u00f3n prolongados.<\/li>\n  <li><strong>Medidas<\/strong>: Desfragmentaci\u00f3n activa, elaboraci\u00f3n de presupuestos, optimizaci\u00f3n del modelo de datos.<\/li>\n  <li><strong>Monitoreo<\/strong>: Configurar alertas sobre los valores de Ratio y 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>\u00bfQu\u00e9 significa exactamente \u00abmem_fragmentation_ratio\u00bb?<\/h2>\n\n<p>Utilizo el valor caracter\u00edstico <strong>relaci\u00f3n_fragmentaci\u00f3n_mem<\/strong>, para ver la relaci\u00f3n entre el RSS y el consumo de datos. El cociente entre <strong>memoria_utilizada_rss<\/strong> dividido entre <strong>memoria_utilizada<\/strong> muestra lo bien que Redis aprovecha la RAM. Los valores cercanos a 1,0 indican una <strong>eficiente<\/strong> Utilizaci\u00f3n con pocos espacios libres. Los valores elevados indican que en el proceso hay muchas \u00e1reas libres que el asignador no puede reutilizar. Nunca eval\u00fao este valor de forma aislada, sino junto con el tama\u00f1o, la carga de trabajo y <strong>Asignador<\/strong>-M\u00e9tricas.<\/p>\n\n<h2>Interpretar correctamente los valores orientativos<\/h2>\n\n<p>Ordeno el <strong>Ratio<\/strong> en zonas fijas, para que las decisiones sigan siendo reproducibles. Para m\u00ed, unos ligeros excesos en torno a 1,1 son normales <strong>Sobrecarga<\/strong>. A partir de aproximadamente 1,5, planeo tomar medidas, porque, de lo contrario, la RAM se agota o el sistema se acerca a los l\u00edmites de OOM. Por debajo de 1,0, reacciono de inmediato, ya que eso indica que <strong>Intercambiar<\/strong> . La siguiente tabla resume los \u00e1mbitos y acciones t\u00edpicos.<\/p>\n\n<table>\n  <thead>\n    <tr>\n      <th><strong>Ratio<\/strong><\/th>\n      <th><strong>Significado<\/strong><\/th>\n      <th><strong>medida inmediata<\/strong><\/th>\n    <\/tr>\n  <\/thead>\n  <tbody>\n    <tr>\n      <td>Menos de 1,0<\/td>\n      <td><strong>Intercambiar<\/strong>-Riesgo, latencia elevada<\/td>\n      <td>Comprobar la RAM\/memoria m\u00e1xima y reducir el volumen de datos<\/td>\n    <\/tr>\n    <tr>\n      <td>1,0\u20131,1<\/td>\n      <td><strong>Sano<\/strong> con un ligero sobrecoste<\/td>\n      <td>Seguir observando, no hay nada urgente<\/td>\n    <\/tr>\n    <tr>\n      <td>1,1\u20131,5<\/td>\n      <td><strong>Normal<\/strong>, fragmentaci\u00f3n moderada<\/td>\n      <td>Observar las tendencias, anotar las causas<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e1s de 1,5<\/td>\n      <td><strong>Aumentado<\/strong>, desperdicio de memoria<\/td>\n      <td>Active Defrag, comprobar el modelo, probar Purge<\/td>\n    <\/tr>\n    <tr>\n      <td>M\u00e1s de 2,0<\/td>\n      <td><strong>Alta<\/strong>, presi\u00f3n sobre la capacidad<\/td>\n      <td>Desfragmentaci\u00f3n agresiva; plantearse reiniciar el sistema<\/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>C\u00f3mo se produce la fragmentaci\u00f3n<\/h2>\n\n<p>Veo un alto <strong>Fragmentaci\u00f3n<\/strong> sobre todo cuando hay muchas operaciones de escritura y borrado. El asignador, normalmente <strong>jemalloc<\/strong>, crea almacenes en las arenas que no siempre se reciclan a la perfecci\u00f3n. Cuando las claves se reducen, crecen o desaparecen por completo, quedan huecos. A menudo, los nuevos objetos no encajan en esos huecos, lo que hace que el RSS se mantenga m\u00e1s alto que los datos reales. Con tiempos de ejecuci\u00f3n prolongados, estos se acumulan <strong>Lagunas<\/strong>, hasta que el ratio aumente notablemente.<\/p>\n\n<h2>S\u00edntomas y riesgos en el trabajo<\/h2>\n\n<p>Creciente <strong>Latencia<\/strong>, lo primero que me llama la atenci\u00f3n son los errores OOM repentinos y el aumento del RSS. Aunque el used_memory se mantenga en niveles moderados, la instancia puede llegar a <strong>RAM<\/strong>-Llegar al l\u00edmite. Cuando el sistema tiene que almacenar p\u00e1ginas en memoria, los tiempos de respuesta se disparan. Los servicios responden con lentitud y aumentan los tiempos de espera, lo que desestabiliza las aplicaciones. Por eso, siempre tengo en cuenta tambi\u00e9n la <strong>Intercambiar<\/strong>-Las m\u00e9tricas a la vista.<\/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>Leer \u00abINFO MEMORY\u00bb de forma segura<\/h2>\n\n<p>Acerca de <strong>INFORMACI\u00d3N<\/strong> En cuanto a la memoria, compruebo los valores de used_memory, used_memory_rss y mem_fragmentation_ratio. Adem\u00e1s, presto atenci\u00f3n a <strong>allocator_frag_ratio<\/strong> y \u00aballocator_rss_ratio\u00bb, para detectar diferencias entre el mont\u00f3n y el sistema operativo. Un valor elevado de \u00abmem_fragmentation_ratio\u00bb con un valor normal de \u00aballocator\u00bb me indica que el sistema operativo no recupera bien las p\u00e1ginas. Por el contrario, unos valores elevados de \u00aballocator\u00bb apuntan a problemas internos <strong>Pila<\/strong>-Fragmentaci\u00f3n. Documento las combinaciones para que se pongan de manifiesto las tendencias y las medidas surtan efecto de forma precisa.<\/p>\n\n<h2>La desfragmentaci\u00f3n activa en la pr\u00e1ctica<\/h2>\n\n<p>Activo el <strong>Activo<\/strong> Desfragmentaci\u00f3n, cuando la relaci\u00f3n aumenta o las cargas de trabajo var\u00edan considerablemente. En este proceso, Redis reorganiza los objetos y los agrupa de forma m\u00e1s compacta para que el sistema operativo pueda liberar p\u00e1ginas. Pruebo el control paso a paso para mantener el consumo de CPU dentro de unos l\u00edmites razonables. Para empezar, utilizo configuraciones probadas y luego las ajusto con precisi\u00f3n. Este art\u00edculo me ofrece una buena introducci\u00f3n: <a href=\"https:\/\/webhosting.de\/es\/redis-desfragmentacion-activa-reduccion-de-la-fragmentacion-de-la-memoria-optimizacion-del-monton\/\">Desfragmentaci\u00f3n activa<\/a>-Art\u00edculo.<\/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>He puesto <strong>Valores l\u00edmite<\/strong> de modo que Defrag se active solo cuando sea realmente necesario. Los valores de \u00abCycle\u00bb limitan el presupuesto de CPU para que los picos de carga no se vean afectados. Tras realizar los ajustes, observo las m\u00e9tricas durante varias horas. Solo cuando la relaci\u00f3n, la latencia y la CPU parecen estar en equilibrio, aplico los <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 los par\u00e1metros con precisi\u00f3n sin efectos secundarios<\/h2>\n\n<p>Aumento la <strong>Valores umbral<\/strong> solo en peque\u00f1os pasos, para evitar efectos secundarios. Un ciclo demasiado agresivo, aunque reduce la fragmentaci\u00f3n, supone una carga para la <strong>CPU<\/strong> notable. Cuando hay mucha actividad durante el d\u00eda, pospongo las pruebas para momentos m\u00e1s tranquilos, de modo que los efectos sigan siendo f\u00e1cilmente medibles. Resulta \u00fatil realizar una comparaci\u00f3n antes y despu\u00e9s del ajuste con una configuraci\u00f3n id\u00e9ntica <strong>Carga de trabajo<\/strong>. As\u00ed es como puedo saber si la desfragmentaci\u00f3n reduce realmente la ratio o si solo redistribuye la carga.<\/p>\n\n<h2>Utilizar \u00abLazy Free\u00bb de forma consciente<\/h2>\n\n<p>Utilizo <strong>Lazy Free<\/strong>, cuando desaparecen o se renombran muchas claves grandes a la vez. En lugar de bloquearse de forma sincronizada, <em>UNLINK<\/em>, <em>FLUSHDB ASYNC<\/em> y <em>FLUSHALL ASYNC<\/em> Libera memoria en segundo plano. Esto reduce los picos de latencia, pero puede aumentar la fragmentaci\u00f3n a corto plazo, ya que las p\u00e1ginas se reciclan de forma as\u00edncrona. Controlo este comportamiento mediante los par\u00e1metros de lazyfree (por ejemplo, lazyfree-lazy-eviction, lazyfree-lazy-server-del), compruebo los efectos sobre la CPU y superviso <strong>lazyfree_pending_objects<\/strong> en la memoria INFO. Si quedan muchos objetos pendientes, aumento ligeramente los presupuestos de desfragmentaci\u00f3n o espac\u00edo las oleadas de eliminaci\u00f3n para que el mont\u00f3n no se fragmenten en muchos huecos peque\u00f1os.<\/p>\n\n<h2>Programar una limpieza manual y un reinicio<\/h2>\n\n<p>Si el Ratio se dispara, tomar\u00e9 medidas dr\u00e1sticas <strong>Palanca<\/strong>. Con MEMORY PURGE le pido al asignador que devuelva las p\u00e1ginas no utilizadas al sistema operativo. Con DEBUG MALLOC-STATS puedo analizar m\u00e1s a fondo el <strong>Arenas<\/strong> y los patrones de asignaci\u00f3n. Si el ratio se mantiene por encima de 2,0, tengo previsto realizar un reinicio coordinado tras una instant\u00e1nea o una sincronizaci\u00f3n AOF. Este paso requiere la <strong>Estructura de almacenamiento<\/strong> Vuelve atr\u00e1s y recupera el RSS inmediatamente.<\/p>\n\n<h2>Planificar Maxmemory de forma inteligente<\/h2>\n\n<p>Estoy planeando <strong>memoria m\u00e1xima<\/strong> nunca hasta el l\u00edmite f\u00edsico de la RAM. Como regla general, reservo entre 60 y 65 % para datos, entre 5 y 10 % como b\u00fafer de fragmentaci\u00f3n y entre 10 y 20 % para <strong>Copy-on-Write<\/strong>. El resto se destina al sistema operativo, a los agentes y al funcionamiento. Esta distribuci\u00f3n evita <strong>OOM<\/strong>-Sorpresas y le da un respiro a Defrag. Aqu\u00ed encuentro una gu\u00eda pr\u00e1ctica: <a href=\"https:\/\/webhosting.de\/es\/gestion-de-memoria-de-redis-configuracion-optima-de-la-memoria-rendimiento-cache\/\">Configurar la memoria de forma \u00f3ptima<\/a>.<\/p>\n\n<h2>Persistencia, RDB\/AOF y \u00abcopy-on-write\u00bb<\/h2>\n\n<p>Siempre tengo en cuenta los efectos de <strong>Persistencia<\/strong> la fragmentaci\u00f3n. En BGSAVE y las reescrituras AOF, Copy-on-Write duplica las p\u00e1ginas modificadas. En esta fase, el RSS aumenta, aunque el used_memory apenas crece. Por eso, tengo previsto realizar reescrituras completas en franjas horarias tranquilas, compruebo <em>auto-aof-porcentaje-de-reescritura<\/em> y <em>-tama\u00f1o m\u00ednimo-<\/em> y mantengo espacio libre disponible para CoW. Los picos de escritura intensos durante una reescritura hacen que las \u00e1reas se fragmenten r\u00e1pidamente; la desfragmentaci\u00f3n posterior recupera el RSS. En las r\u00e9plicas, presto especial atenci\u00f3n a la primera resincronizaci\u00f3n completa: las importaciones masivas junto con CoW son un factor cl\u00e1sico que provoca picos elevados a corto plazo <strong>relaci\u00f3n_fragmentaci\u00f3n_mem<\/strong>. Si el valor sigue siendo elevado una vez finalizado el proceso, ejecuto una desfragmentaci\u00f3n r\u00e1pida o compruebo <em>PURGA DE MEMORIA<\/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>Por debajo de 1,0: el swap es el freno<\/h2>\n\n<p>Si el ratio es inferior a 1,0, se frena <strong>Intercambiar<\/strong> el sistema. Cada ciclo de fallo de p\u00e1gina supone una p\u00e9rdida de tiempo apreciable y hace que se incumplan los objetivos de latencia. A continuaci\u00f3n, compruebo el estado de la RAM y reduzco <strong>memoria m\u00e1xima<\/strong> o reduzco los datos en la instancia. Adem\u00e1s, compruebo par\u00e1metros del sistema como vm.swappiness para que el n\u00facleo lo haga con menos frecuencia <strong>externaliza<\/strong>. El objetivo sigue siendo mantener la instancia exclusivamente en la memoria RAM y evitar las recuperaciones de p\u00e1ginas.<\/p>\n\n<h2>Tener en cuenta la configuraci\u00f3n de los contenedores y del n\u00facleo<\/h2>\n\n<p>En los contenedores, siempre mido la fragmentaci\u00f3n en el contexto de <strong>cgroups<\/strong>-L\u00edmites. Comparo los datos de RSS con los l\u00edmites de memoria y establezco <em>vm.overcommit_memory=1<\/em>, para que Redis no falle por un exceso de compromiso. <strong>P\u00e1ginas enormes transparentes<\/strong> Las desactivo porque sobrecargan el RSS y dificultan la desfragmentaci\u00f3n. Adem\u00e1s, observo que <em>oom_kill<\/em>-Contador del cgroup y reacciono con antelaci\u00f3n cuando el n\u00facleo empieza a saturarse. En Kubernetes, me encargo de establecer solicitudes y l\u00edmites realistas y reservo margen por pod, para que BGSAVE y las reescrituras no lleguen al l\u00edmite de forma involuntaria. Importante: el aislamiento de contenedores no altera la l\u00f3gica interna del mont\u00f3n; la desfragmentaci\u00f3n, la liberaci\u00f3n diferida y el mantenimiento del modelo siguen siendo las herramientas fundamentales contra <strong>Fragmentaci\u00f3n<\/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>Optimizar el modelo de datos y los indicadores clave<\/h2>\n\n<p>Sostengo <strong>objetos<\/strong> peque\u00f1as y uniformes, para que el asignador se desv\u00ede menos. Las listas, conjuntos o tablas hash muy grandes las divido en varias claves m\u00e1s peque\u00f1as. En lugar de cadenas JSON enormes, utilizo compactas <strong>Tipos de datos<\/strong> como los hash con campos que cambian con menos frecuencia. En el caso de las sesiones, los contadores y las cach\u00e9s, estandarizo los tama\u00f1os para que las asignaciones sean m\u00e1s predecibles. De este modo, reduzco la <strong>Fragmentaci\u00f3n<\/strong>, antes de empezar a modificar las configuraciones.<\/p>\n\n<h2>Pol\u00edtica de expulsi\u00f3n y comportamiento durante el proceso<\/h2>\n\n<p>Elijo el <strong>Pol\u00edtica de desalojo<\/strong> en funci\u00f3n de la carga de trabajo. Cuando los conjuntos de claves var\u00edan mucho, las variantes LRU\/LFU distribuyen las eliminaciones de forma m\u00e1s uniforme y evitan picos. Evito las caducidades masivas a la hora en punto y distribuyo los TTL para que el \u00abActive-Expire\u00bb no elimine miles de objetos a la vez. Par\u00e1metros como <em>hz<\/em> y <em>active-expire-effort<\/em> Lo ajusto con cuidado para no sobrecargar la CPU. Un patr\u00f3n de ejecuci\u00f3n estable genera asignaciones predecibles, y eso es precisamente lo que mantiene la <strong>relaci\u00f3n_fragmentaci\u00f3n_mem<\/strong> plana.<\/p>\n\n<h2>Redis Cluster y sharding<\/h2>\n\n<p>En lo que respecta al crecimiento, apuesto por <strong>Fragmentaci\u00f3n<\/strong> o cl\u00fasteres, ya que los montones m\u00e1s peque\u00f1os por fragmento generan menos huecos a largo plazo. Durante el reequilibrio, planifico las ventanas de migraci\u00f3n de modo que los picos de escritura y las reescrituras no coincidan. Las grandes oleadas de MIGRATE pueden aumentar temporalmente el RSS en los nodos de destino; mientras tanto, superviso los valores del asignador y activo la desfragmentaci\u00f3n tras el traslado. En las r\u00e9plicas, tengo en cuenta la memoria adicional para los trabajos pendientes y los b\u00faferes de r\u00e9plica; esto tambi\u00e9n se tiene en cuenta en la <strong>Maxmemory<\/strong>-Elaboraci\u00f3n del presupuesto.<\/p>\n\n<h2>Profundizar en la observabilidad: MEMORY STATS y latencia<\/h2>\n\n<ul>\n  <li>Utilizo <strong>ESTAD\u00cdSTICAS DE MEMORIA<\/strong>, para ver la sobrecarga, la proporci\u00f3n de conjuntos de datos y los detalles de la fragmentaci\u00f3n. Esto ayuda a diferenciar la fragmentaci\u00f3n del mont\u00f3n de la del sistema operativo.<\/li>\n  <li>Con <strong>MEMORY DOCTOR<\/strong> Me indican si, a corto plazo, lo m\u00e1s eficaz es el modelo de datos, la desfragmentaci\u00f3n o la purga.<\/li>\n  <li>Yo correlaciono <strong>latencia<\/strong>-M\u00e9tricas (por ejemplo, \u00ablatency doctor\u00bb) con fases de desfragmentaci\u00f3n y reescrituras, para detectar efectos secundarios.<\/li>\n  <li>El <strong>SLOWLOG<\/strong> Me indica si los comandos se desincronizan debido a operaciones de memoria, especialmente las de DEL, UNLINK y las series largas de HSET\/HGET.<\/li>\n<\/ul>\n\n<h2>Gu\u00eda pr\u00e1ctica para la gesti\u00f3n<\/h2>\n\n<ul>\n  <li>Referencia: guardar la memoria INFO, documentar la relaci\u00f3n, los valores del asignador y el conjunto de datos\/sobrecarga.<\/li>\n  <li>Presupuesto: configurar \u00abmaxmemory\u00bb con unos valores realistas de 60-65 % de datos, 5-10 % de fragmentaci\u00f3n y 10-20 % de CoW.<\/li>\n  <li>Desfragmentaci\u00f3n: activar \u00abactivedefrag\u00bb, aumentar el valor de forma c\u00edclica y con precauci\u00f3n, y medir los efectos a lo largo de varias horas.<\/li>\n  <li>Modelo de datos: dividir los objetos grandes, evitar los bloques JSON, estandarizar los tama\u00f1os.<\/li>\n  <li>Caducidad: distribuir los TTL, elegir la pol\u00edtica de expulsi\u00f3n adecuada, evitar las oleadas de eliminaci\u00f3n.<\/li>\n  <li>Persistencia: planificar las reescrituras, asignar margen de espacio libre y comprobar la desfragmentaci\u00f3n una vez finalizada.<\/li>\n  <li>Purga\/reinicio: si la relaci\u00f3n es superior a 2,0, intentar realizar una purga; en caso contrario, reiniciar de forma ordenada.<\/li>\n  <li>Contenedor: desactivar THP, activar Overcommit, l\u00edmites\/solicitudes con margen; limitar estrictamente el swap.<\/li>\n  <li>Supervisi\u00f3n: alertas a 1,5\/2,0\/menos de 1,0; evaluar las tendencias seg\u00fan las implementaciones y los lotes.<\/li>\n<\/ul>\n\n<h2>Ejemplo: De 1,8 a 1,2 en 24 horas<\/h2>\n\n<p>En una instancia de 64 GB (maxmemory 40 GB), la <strong>relaci\u00f3n_fragmentaci\u00f3n_mem<\/strong> a 1,8, aunque \u00abused_memory\u00bb se situaba entre 28 y 30 GB. Primero hice lo siguiente: <em>activedefrag<\/em> Lo he activado (cycle-min 5, cycle-max 50) y he cambiado la hora de la reescritura nocturna de AOF a un horario m\u00e1s tranquilo. A continuaci\u00f3n, reequilibr\u00e9 los TTL que hasta entonces caducaban cada hora y sustitu\u00ed varios valores JSON enormes por hash con tama\u00f1os de campo estables. Una medida espec\u00edfica <em>PURGA DE MEMORIA<\/em> Tras el pico de carga, se liber\u00f3 adem\u00e1s memoria RSS. Resultado: al cabo de 24 horas, la relaci\u00f3n se estabiliz\u00f3 en ~1,2, los picos de latencia desaparecieron y la memoria RAM del servidor recuper\u00f3 ~8 GB de espacio libre. La <strong>Asignador<\/strong>-Valores confirmados: menor fragmentaci\u00f3n del heap, RSS del sistema operativo en orden.<\/p>\n\n<h2>Comparar de forma adecuada los entornos de alojamiento web<\/h2>\n\n<p>Me aseguro de que haya suficiente <strong>RAM<\/strong>, una CPU predecible y valores de E\/S constantes si alojo Redis en el proveedor de alojamiento. Los recursos dedicados y las actualizaciones flexibles evitan los cuellos de botella a medida que crece el negocio. Es recomendable disponer de m\u00e9tricas claras sobre RSS, <strong>Intercambiar<\/strong> y l\u00edmites, para poder detectar a tiempo los cuellos de botella. Para configuraciones alemanas, recomiendo webhoster.de, porque all\u00ed los recursos est\u00e1n disponibles de forma fiable. Una plataforma bien organizada mantiene el <strong>Fragmentaci\u00f3n<\/strong>El valor se mantiene dentro de los l\u00edmites normales.<\/p>\n\n<h2>Resumen<\/h2>\n\n<p>Leo el <strong>Redis<\/strong> El \u00edndice de fragmentaci\u00f3n de la memoria como se\u00f1al de alerta temprana de p\u00e9rdidas de RAM y latencia. Los valores cercanos a 1,0 son normales; a partir de 1,5, pongo en marcha la desfragmentaci\u00f3n y los ajustes del modelo; por debajo de 1,0, lo detengo. <strong>Intercambiar<\/strong> al instante. Gracias a la desfragmentaci\u00f3n activa, a una gesti\u00f3n inteligente de la memoria m\u00e1xima y a estructuras de datos compactas, mantengo la <strong>Memoria<\/strong>-Alta eficiencia. La supervisi\u00f3n continua permite detectar patrones y evita las medidas precipitadas y puntuales. De este modo, la instancia mantiene su capacidad de respuesta, y el <strong>Ratio<\/strong> se mueve all\u00ed donde debe estar.<\/p>","protected":false},"excerpt":{"rendered":"<p>Aprende a interpretar correctamente el \u00edndice de fragmentaci\u00f3n de memoria de Redis, a identificar los rangos normales y cr\u00edticos, y a mantener tu memoria de Redis eficiente y estable mediante un ajuste espec\u00edfico de 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\/es\/wp-json\/wp\/v2\/posts\/21291","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=21291"}],"version-history":[{"count":0,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/posts\/21291\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media\/21284"}],"wp:attachment":[{"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/media?parent=21291"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/categories?post=21291"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/webhosting.de\/es\/wp-json\/wp\/v2\/tags?post=21291"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}