Tuvimos un problema de soporte técnico interesante dentro de nuestra propia red en la víspera de Año Nuevo. El desarrollador a cargo cuenta su historia a continuación:
Justo después de la 1:00 CET, comencé a recibir notificaciones de que el Límite de Recursos coincidía con la red para una carga promedio >10. Primero pensé que era una tarea programada, pero rápidamente me di cuenta de que nada tan «pesado» se programaría a la medianoche (GMT). Así que decidí dejar de ver la película aburrida que miraba y ver qué estaba pasando.
Encontré muchas llamadas fallidas por el mismo motivo: se excedió el CAC. También me di cuenta de que había muchas llamadas, aunque era Año Nuevo, y la mayoría de los negocios de nuestros clientes estaban cerrados por los feriados.
El comando superior mostró que todos los procesos de FreeSWITCHES y mysqld tenían un uso de CPU de >100%. Fue un misterio porque no hubo consultas de SQL y FreeSWITCH tuvo cero llamadas y la CPU fue >100%.
Primero, reinicié los FreeSWITCHES uno por uno e intenté diferentes interruptores para el reloj RT y la sincronización del reloj. Nada ayudó. FreeSWITCH compiló hace 2 años y nada cambió. ¿Cómo había pasado el anterior Año Nuevo?
La razón por la que FreeSWITCH rechazaba las llamadas era una restricción de que la CPU inactiva mínima debe ser del 5% para garantizar la calidad de la transcodificación. Decidí deshabilitar esto y dejé 3 FreeSWITCHES trabajando para mantener la carga menos y permitir que pasen las llamadas. FreeSWITCH ocuparía 3 núcleos y tendría espacio para llamadas. Probé varias llamadas y no tuve ningún problema con la calidad. Parecía que eso sería suficiente mientras intentaba encontrar el problema y resolverlo.
Así es como se veía cuando llegó la mañana y finalmente necesitaba dormir, incapaz de resolver el problema.
Más tarde ese día decidí probar un nuevo FreeSWITCH 1.6 y 1.8. Compilé, preparé y probé, pero no ayudó. El uso de la CPU nuevamente estaba >100%. Luego compilé una versión de depuración y la agregué como el cuarto FreeSWITCH en producción para obtener el volcado del núcleo y averiguar por qué el FreeSWITCH inactivo se estaba comiendo la CPU. Me di cuenta de que FreeSWITCH tenía un problema con los temporizadores. Ensayé otra, pero no funcionó. Hubo problemas con la función nanosleep en FreeSWITCH, pero ya estaba arreglado. De alguna manera, FreeSWITCH exprimió el tiempo y saltó a un bucle.
Luego verifiqué la hora en el host, fue correcta. Incluso /proc/interrupts parecía correcto.
Mi última opción fue intentar ajustar la hora en el host y sincronizar con NTP. El reinicio del ntp-client falló. Afortunadamente fue un problema con el DNS. En realidad, el host no pudo acceder a nuestro sistema local de resolución de DNS. Lo cambié temporalmente a un nameserver externo para resolver el servidor NTP y corregir la hora.
En el mismo momento en que el NTP finalizó la sincronización, todos los procesos volvieron a utilizar <5% de CPU.
Me di cuenta de que era un problema con el error de segundo salto en un kernel antiguo y afectaba a FreeSWITCH y MySQL, pero se corrigió con NTP cuando NTP sincronizó la hora.
