Cómo solucionar el desbordamiento de memoria de red5 en Linux

Como marco multimedia de código abierto, Red5 implementa el protocolo RTMP y completa la transmisión y análisis de datos de video, audio y multimedia. También estamos utilizando sus servicios, pero encontramos un problema de pérdida de memoria. ¿Cómo se descubrió esta pérdida de memoria?

Fenómenos: el servidor funcionó durante aproximadamente dos días y ocurrieron dos situaciones:

p>

1. Desbordamiento de memoria

2. La memoria no se desborda, pero no se puede proporcionar ningún servicio y el servidor no puede recibir ninguna solicitud

Análisis:

1. Se amplió la memoria de la máquina virtual. Como resultado, el servidor funcionó durante mucho tiempo y la memoria aún se desbordó.

2 Descarté la instantánea del montón y la analicé con Eclispse Memory. Analizador se encontró que existía una gran cantidad de objetos RTMPMinaConnection en el objeto ConcurrentHashMap ¿Por qué hay muchas conexiones? ¿Por qué no se libera la memoria incluso con una gran cantidad de solicitudes de clientes?

3. Considere tres preguntas:

1) ¿Por qué hay una gran cantidad de conexiones? ¿De dónde vienen las conexiones?

2) ¿Por qué no se liberan una gran cantidad de conexiones?

3) ¿Por qué el servidor no puede proporcionar ningún servicio incluso si tiene suficiente memoria cuando el número de conexiones alcanza un cierto nivel?

Basándonos en una gran cantidad de observaciones, encontramos el servidor red5. Usamos Haproxy para representar la solicitud rtmp, y HA aún intentó conectarse incluso si no había ninguna solicitud para detectar si el servidor proxy estaba activo. Y el tiempo de mantenimiento de red5 una vez finalizado, intentará cerrar la conexión. Después de cerrar, al mirar el código fuente, se descubre que aunque la conexión está cerrada, de hecho no se elimina del concurrentHashupMap. Este tipo de Ha detecta constantemente si red5 está activo creando un estado de conexión de latido, y después de que red5 cerró la conexión, no se eliminó del concurrentHashMap, lo que provocó un desbordamiento de memoria final. no se eliminaron, se alcanzó el número máximo permitido de conexiones inactivas establecido por red5, que es 60000 de forma predeterminada, lo que provocó el fenómeno que acabamos de ver: incluso si hay suficiente memoria, no se puede proporcionar ningún servicio.

El proceso de encontrar este error fue doloroso y ni siquiera tenía ni idea, a través de muchas pruebas y análisis del código fuente, encontré este problema. Ahora hemos actualizado a red5 versión 0.9.1 y la situación actual es buena. Al mismo tiempo, para garantizar la estabilidad del servidor, también hemos verificado el código fuente relevante y podemos confirmar que este problema se ha solucionado. en la versión 0.9.1. Creo que el servidor red5 estará en un estado muy estable después del lanzamiento de nuestro producto.

Para descubrir este problema, el uso de algunas herramientas es fundamental:

En primer lugar, debe poder analizar instantáneas del montón, y el analizador de memoria de eclipse es realmente una herramienta muy poderosa. herramienta. Nos proporcionó mucha información útil.

En segundo lugar, el software de código abierto no es fiable. Sólo si realizamos un análisis en profundidad de su código podremos obtener buenos resultados. Afortunadamente, el código fuente abierto también nos proporciona una base para encontrar los entresijos del problema. También podemos optimizar el software de código abierto. En contenidos futuros, también registraré todo el proceso de optimización del servidor red5. Creo que todavía podemos optimizarlo en muchos lugares.

Lo encontré en línea~~