Solución de problemas de rendimiento de Redmine (pila de Bitnami)

Tengo una instancia de Redmine (Bitnami Stack) que es inusualmente lenta. Debido a que solo estoy tratando de llegar al fondo de esto, tengo algunas teorías que me gustaría discutir aquí. Entonces, si alguien tiene alguna idea sobre esto, no dude en ayudar :-)

Sistema:

Bitnami Stack con Redmine 1.4.x actualizado a Bitnami Stack con Redmine 2.1.0 de esta manera:

• mysqldump'd la vieja base de datos
• instalado el nuevo Bitnami Stack con Redmine 2.1.0
• importó el volcado limpiamente con la recreación de todas las tablas
• rastrillo db: migrar y todo eso

La pila se ejecuta en una máquina virtual con OpenSUSE 12.1. Los recursos no deberían ser un problema, ya que siempre hay múltiples gigabytes de RAM libre y los picos de CPU en las solicitudes de Redmine van solo hasta el 50% de 2 núcleos de CPU. Además, solo unos pocos usuarios acceden a él.

Lo que puede ser totalmente importante: el inicio de sesión del usuario se maneja a través de LDAP (ActiveDirectory).

Problema:

En cada solicitud, Redmine reacciona inusualmente lento. A veces se tarda 3 segundos, a veces incluso hasta 10 segundos para entregar la página.

Mis pensamientos:

• No sé si la "Creación de usuarios sobre la marcha" está marcada en la configuración de LDAP de Redmine, solo puedo comprobar esto más tarde hoy. ¿Pero podría ser un problema la falta de un cheque aquí? La autenticación toma un momento cuando iniciar sesión es normal y reconocido. Pero cuando no crea al usuario sobre la marcha, ¿mantiene solo una sesión o se vuelve a autenticar en cada solicitud, por lo que ese podría ser el problema?
• ¿Es Redmine 2.x quizás mucho más lento que 1.4.x que es simplemente normal?
• ¿La configuración de Apache2 + Passenger de Bitnami es defectuosa?
• Los índices MySQL no serían un problema dado el hecho de que MySQL está muy tranquilo en la CPU, ¿verdad?

Una cosa más que me parece muy extraña, pero tal vez un resultado de medición falso (necesito volver a verificar esto mañana cuando vea la máquina):

Traté de verificar si se trata de un problema de red (la red reacciona lentamente, tal vez DNS o algo; el servidor está en la red local). Parecía que las solicitudes en localhost (navegador directamente en OpenSUSE VM) eran rápidas, pero las solicitudes en la red no lo eran. Por lo general, pensaría en un problema de red, pero lo extraño es: cuando realmente mide los tiempos de conexión, la red es tan rápida como el infierno. Ping es bueno, los tiempos de entrega estáticos también. Parecía que solo las páginas calculadas del lado de Redmine son enviadas lentamente por el servidor de aplicaciones mientras Apache aún es rápido, pero solo cuando la solicitud es una solicitud de LAN remota. Muy extraño ... pero como mencioné anteriormente, tengo que volver a verificar este. Simplemente me parece ilógico.

Intente volver a verificar los registros de Redmine si hay algún problema relacionado con el procesamiento de las páginas o los inicios de sesión de los usuarios si considera que el inicio de sesión de LDAP AD es culpable.

Además, compruebe los registros de apache y mySQL: el servidor web puede estar ocupado con otra cosa o Ruby puede estar atascado al representar un complemento no compatible, por ejemplo. MySQL puede estar ejecutando una consulta de larga duración, etc.

Si reinicia todos los servicios que sirven a la instancia de Redmine, ¿se está ejecutando rápido al principio y se ralentiza después de un tiempo o es lento desde el principio?

Como se mencionó en la sección de comentarios: las E / S de disco también pueden tener la culpa. Intente ajustar los registros del servidor web mientras hace clic en la interfaz web de Redmine para tener una idea de lo que está tomando la mayor cantidad de tiempo en renderizar.

También intente probar su conexión de red a la instancia de redmine (no solo con ping / ICMP) sino que también intente cargar contenido estático (descargar) o enviar algunos archivos (cargar) a través del puerto 80 o 443.

Intente medir la pérdida de paquetes, el tiempo de ida y vuelta y la fluctuación (cuántos paquetes llegan fuera de secuencia) para tener una idea de si la red no tiene la culpa.