He configurado un pequeño programa Python que utiliza una conexión websocket para adquirir datos de una API y escribirlos en una base de datos postgresql.
Solo hay dos programas (de usuario) ejecutándose: la conexión websocket que recibe datos y los escribe en la base de datos, y otro programa que es básico, un bucle while que se ejecuta cada 15 segundos y verifica si se están escribiendo datos.
Ambos programas se demonizan con el supervisor y cuando no se escriben datos durante 15 segundos, se reinicia el supervisor (para manejar la conexión websocket inactiva).
También fui (muy) vago y usé Django ORM para hacer la conexión a la base de datos por mí en lugar de psycopg2 directamente.
Funciona, pero tengo una carga de CPU alta y constante en el servidor. Es un servidor de memoria de 1CPU y 1Gb (AWS micro). El comando superior genera lo siguiente:
top - 17:10:58 up 19 days, 15:03, 1 user, load average: 1,57, 1,63, 1,58
Tasks: 116 total, 1 running, 115 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0,3 us, 0,3 sy, 0,0 ni, 0,0 id, 99,0 wa, 0,0 hi, 0,0 si, 0,3 st
KiB Mem : 1014552 total, 63440 free, 86572 used, 864540 buff/cache
KiB Swap: 1048572 total, 987380 free, 61192 used. 615096 avail Mem
Bueno, el sistema va lento y ocasionalmente falla.
Puedo ver que esto se debe a una alta carga de IO (99 wa). Muchos procesos de sueño. Pero estoy escribiendo un promedio de 400 MB por día sólo en la base de datos.
Intenté modificar la configuración de Postgresql para una carga de escritura alta siguiendo la documentación y configurando un archivo de memoria de intercambio (1 GB), pero eso no ayudó a aliviar el promedio de carga.
Entonces, para un usuario sin experiencia como yo, no sé si esta es la carga que debería esperar. ¿Puedo optimizar esta configuración? Si elimino django ORM y escribo el programa usando solo psycopg2, ¿mejoraría? ¿Debo realizar un método de verificación diferente para conexiones websocket inactivas? ¿Existe alguna configuración de servidor que pueda optimizarse para este caso de necesidad?
¡Gracias!
Respuesta1
Me las arreglo para descubrir cómo solucionarlo usando este enlacehttp://bencane.com/2012/08/06/troubleshooting-high-io-wait-in-linux/
Básicamente lo ejecuté iotopy eso generó qué proceso estaba causando una alta carga de IO. Allí descubrí que la carga se debía a leer la base de datos y no a escribir. Entonces me di cuenta de que estaba haciendo algo estúpido: estaba consultando mucho la base de datos entera contando el número de entradas mientras comprobaba si estaba grabando. Eso fue un promedio de 500 MB/s de lectura. Así que cambié el código para verificar el número de clave principal de la última entrada en lugar de contar las entradas y... funcionó. El promedio de carga ahora es 0,01. Gracias @match por el aviso