memory-leaks redis stackexchange.redis

memory leaks - Cómo determinar la fuga de memoria Redis?



memory-leaks stackexchange.redis (1)

Nuestros servidores redis son, desde ayer, gradualmente (200MB / hora) usando más memoria, mientras que la cantidad de claves (330K) y sus datos (132MB redis-rdb-tools ) se mantienen casi iguales.

La salida de la información de redis-cli muestra 6.89G de memoria utilizada?

redis_version:2.4.10 redis_git_sha1:00000000 redis_git_dirty:0 arch_bits:64 multiplexing_api:epoll gcc_version:4.4.6 process_id:3437 uptime_in_seconds:296453 uptime_in_days:3 lru_clock:1905188 used_cpu_sys:8605.03 used_cpu_user:1480.46 used_cpu_sys_children:1035.93 used_cpu_user_children:3504.93 connected_clients:404 connected_slaves:0 client_longest_output_list:0 client_biggest_input_buf:0 blocked_clients:0 used_memory:7400076728 used_memory_human:6.89G used_memory_rss:7186984960 used_memory_peak:7427443856 used_memory_peak_human:6.92G mem_fragmentation_ratio:0.97 mem_allocator:jemalloc-2.2.5 loading:0 aof_enabled:0 changes_since_last_save:1672 bgsave_in_progress:0 last_save_time:1403172198 bgrewriteaof_in_progress:0 total_connections_received:3616 total_commands_processed:127741023 expired_keys:0 evicted_keys:0 keyspace_hits:18817574 keyspace_misses:8285349 pubsub_channels:0 pubsub_patterns:0 latest_fork_usec:1619791 vm_enabled:0 role:slave master_host:***BLOCKED*** master_port:6379 master_link_status:up master_last_io_seconds_ago:0 master_sync_in_progress:0 db0:keys=372995,expires=372995 db6:keys=68399,expires=68399

El problema comenzó cuando actualizamos nuestro código de cliente (.net) de BookSleeve 1.1.0.4 a ServiceStack v3.9.71 para prepararnos para una actualización a Redis 2.8. Pero muchas otras cosas se actualizaron en Y nuestra tienda de estado de sesión (también redis, pero con cliente de puerto) no muestra los mismos síntomas.

¿A dónde va todo el recuerdo de Redis? ¿Cómo puedo solucionar el problema de su uso?

Editar: Acabo de reiniciar esta instancia y la memoria volvió a 350M y ahora está subiendo de nuevo. Los 10 objetos más grandes siguen siendo del mismo tamaño, que van de 100 K a 25 M para el n ° 1. La cantidad de teclas se ha reducido a 270 K (330 K antes).


Aquí hay algunas fuentes de consumo de memoria "oculto" en Redis:

  • Marc ya mencionó los buffers mantenidos por el maestro para alimentar al esclavo. Si un esclavo se está quedando atrás de su maestro (porque se ejecuta en un cuadro más lento, por ejemplo), entonces se consumirá algo de memoria en el maestro.

  • cuando se detectan comandos de larga ejecución, Redis los registra en el área SLOWLOG, lo que requiere algo de memoria. Es posible que desee utilizar el comando SLOWLOG LEN para verificar el número de registros que tiene aquí.

  • Los búfers de comunicación también pueden tomar memoria. Por lo que recuerdo, con las versiones antiguas de Redis (y 2.4 es bastante viejo, realmente debería actualizar), no tenía límites, lo que significa que si transfiere un objeto grande en un punto, el búfer de comunicación asociado a esta conexión de cliente crecerá y nunca encogerse Si hay muchos clientes que ocasionalmente se ocupan de objetos grandes, podría ser una posible explicación. Si usa comandos que recuperan datos muy grandes de Redis (en una toma), también puede ser una explicación. Por ejemplo, un comando KEYS * simple aplicado en un servidor Redis que almacena millones de claves consumirá una cantidad significativa de memoria.

Mencionaste que tienes objetos tan grandes como 25 MB. Tiene conexiones de cliente 404, si cada una de ellas necesita acceder a dichos objetos en un punto en el tiempo, consumirá 10 GB de memoria.