Hola todos,
Desearía comentaros un problema de nuestra instalación local de Moodle en la ULPGC, a ver si entre todos averiguamos que está pasando. Desde hace un par de días la base de datos de Moodle parece tener problemas y no responde, ocasionalmente. Cuando un usuario intenta entrar en Moodle encuantra el famoso mensaje (lo he visto mucho en los foros):
<>Error: Moodle could not connect to the database.
It's possible the database itself is just not working at the moment.>The admin should
also check that the database details have been correctly specified in config.phpDatabase host: localhost
Database name: moodle2
Database user: moodle2user
Antes de nada indicar que yo no soy el administrador del sistema. Yo sólo me encargo "no-oficialmente" de coordinar, impulsar y promover el sisteam desde el punto de vista docente, no técnico.
Usamos Moodle 1.4 sobre linux (creo que RH) y MySQL
Lo que me preocupa de este error es que nuestar instalación si está bien configurada. Ha estado trabajando bien durante unos meses. de repente, da este error. No es por un error de configuración de config.php.
Tenemso otro servidor corriendo sobre hardware mucho mensos potente y va bien.
Tampoco creo que sea por la carga, actualmenet hay unos 300 usuarios creados, pero consultando los registros se observa que apenas entran 4-5 al día, y no simultáneamente. Eso no da para "cargarse" un servidor, imagino.
Pero estoy preocupado porque el martes empiezan las clase en la ULPGC, y para entonces ibamos a cargar las cuentas de alumnos (un montón). Si da problemas ahora, ¿qué no sucederá entonces?
El lunes vendrán los informáticos y espero que resuleven el problema, pero me gustaría obtener información sobre las
¿posibles causas que pueden echar abajo MySQL?
Se que muchas conexiones simultáneas no son posibles, pero ¿cuanto es muchas?
Además, existen algunso "procesos" más onerosos que otrso, ¿que deban evitarse? Nosotrso tenemos ajustado dbpersit=false en config.php. ¿algún otro sitio donde mirar?
Agradecería toda la información posible, o punteros a sitios donde informarme (si tener que leer el manual de MySQL completo)
- Enrique Castro -
En respuesta a Enrique Castro
Re: "Caída" de la base de datos: causas?
A mí me sucedió igual hace meses con un servidor que tenía pocos usuarios simultáneos, aunque con gran demanda del server (chat, descarga de archivos, lectura de ligas multimedia, etc.). En el archivo my.cnf hay que abrir más sesiones a la base de datos.
Igualmente, he encontrado que si te contectas localmente al server desde "atrás" de un proxy, en se disminuìa la velocidad de transacciones, o de plano se tenía la caída que señalas. En este caso, configurè el "no usar proxy para direcciones locales", dentro de cada navegador web de los alumnos.
Saludos,
Jc
Igualmente, he encontrado que si te contectas localmente al server desde "atrás" de un proxy, en se disminuìa la velocidad de transacciones, o de plano se tenía la caída que señalas. En este caso, configurè el "no usar proxy para direcciones locales", dentro de cada navegador web de los alumnos.
Saludos,
Jc
Me gustaría saber si te refieres a la instalación de la Facultad de Teleformación, o si es otra instalación...
Yo, en primer lugar, descartaría el nº de entradas, y me centraría en que están haciendo cambios con cierta asiduidad, y es posible que alguien se olvide que hay que reinicializar los servicios tras los cambios(httpd, mysql, etc...)
Como su mismo nombre indica, el problema es de conexión a las bases de datos, no es otro tipo de problema.
La tabla central del campus virtual (moodle14) está también detenida.
Saludos
(Yo fui alumno de Teformación hasta el curso pasado, que me Licencié con la Webct)
Hola Enrique,
en plan rapidillo se me ocurren las siguientes cositas:
- Versión de MySQL, que sea la 4.x. Mucho más rápida que la 3.x si se activan las opciones de caché que tiene (variables query_cache_type y query_cache_size).
- Versión de PHP, que sea la 4.x más reciente. Con cada versión se mejorán muchas cosas, especialmente en asuntos como las conexiones y similares.
- La variable 'wait_timeout' de MySQL, por defecto viene a un valor muy grande. Esto puede producir que se queden conexiones sin usar abiertas durante mucho tiempo. Ponerle un valor entre 15-60 puede ayudar a que se liberen con mayor rapidez.
- La variable 'max_connections' de MySQL tiene que estar LIGERAMENTE por encima de la variable 'maxclients' de apache. Esto hará que, para cada hilo de ejecución de apache haya siempre una conexión mysql disponible.
- Estas 2 variables es mejor NO tenerlas con valores demasiado altos (150-200) como mucho inicialmente si el servidor es majo, para ir comprobando como va el servidor de carga cuando haya muchas conexiones simultaneas. Se pueden ir monitorizando y ampliando poco a poco hasta que se vea que no queda memoria y empieza a hacer 'swapping' a disco.
- El dbpersist está mejor a false. En un principio Moodle lo tenía por defecto a true, pero tras bastantes pruebas (incluso recomendado por el autor de las librerías ADOdb, que son las que usa Moodle), se cambió el valor por defecto (en la 1.2, creo que se modificó).
En cualquier caso, todas estas ideas son aplicables a un servidor que está en explotación (con carga real) y da problemas. La verdad es que el caso que tu comentas es algo extraño, ya que la carga (4-5) es ridícula. Pero no está mal que reviséis esas variables por si hay alguna que se sale de lo normal.
También podría ser que tuviérais algún problema con el software (Apache, MySQL, configuración, otras aplicaciones MySQL en el mismo servidor...) o con el hardware (disco, memoria...) pero ahí ya entramos en un mundo que desconozco...
Espero que os sirva de algo, ciao
en plan rapidillo se me ocurren las siguientes cositas:
- Versión de MySQL, que sea la 4.x. Mucho más rápida que la 3.x si se activan las opciones de caché que tiene (variables query_cache_type y query_cache_size).
- Versión de PHP, que sea la 4.x más reciente. Con cada versión se mejorán muchas cosas, especialmente en asuntos como las conexiones y similares.
- La variable 'wait_timeout' de MySQL, por defecto viene a un valor muy grande. Esto puede producir que se queden conexiones sin usar abiertas durante mucho tiempo. Ponerle un valor entre 15-60 puede ayudar a que se liberen con mayor rapidez.
- La variable 'max_connections' de MySQL tiene que estar LIGERAMENTE por encima de la variable 'maxclients' de apache. Esto hará que, para cada hilo de ejecución de apache haya siempre una conexión mysql disponible.
- Estas 2 variables es mejor NO tenerlas con valores demasiado altos (150-200) como mucho inicialmente si el servidor es majo, para ir comprobando como va el servidor de carga cuando haya muchas conexiones simultaneas. Se pueden ir monitorizando y ampliando poco a poco hasta que se vea que no queda memoria y empieza a hacer 'swapping' a disco.
- El dbpersist está mejor a false. En un principio Moodle lo tenía por defecto a true, pero tras bastantes pruebas (incluso recomendado por el autor de las librerías ADOdb, que son las que usa Moodle), se cambió el valor por defecto (en la 1.2, creo que se modificó).
En cualquier caso, todas estas ideas son aplicables a un servidor que está en explotación (con carga real) y da problemas. La verdad es que el caso que tu comentas es algo extraño, ya que la carga (4-5) es ridícula. Pero no está mal que reviséis esas variables por si hay alguna que se sale de lo normal.
También podría ser que tuviérais algún problema con el software (Apache, MySQL, configuración, otras aplicaciones MySQL en el mismo servidor...) o con el hardware (disco, memoria...) pero ahí ya entramos en un mundo que desconozco...
Espero que os sirva de algo, ciao
Que tal Eloy, soy Rene y junto con otros compañeros llevamos el servidor en cuestion. Por lo que estamos preocupados es por la version de redhat que tenemos, no si tendra algo que ver, aunque no debería.
Tenemos lo siguiente:
RedHat 7.3
php 4.1.2
mysql Ver 11.18 Distrib 3.23.58
Server version: Apache/1.3.27 (Unix) (Red-Hat/Linux)
Saludos,
Hola Rene,
La versión 7.3 de RedHat es la que mejor fama tiene (mucho mejor que la 8, desde luego y la 9 y Fedora no las he probado), aunque va siendo algo viejilla. En cualquier caso no debería producir mayor problema.
Otra cosa son las versiones de PHP, MySQL y Apache. De apache, sin pasar a la 2.x, la última que hay es la 1.3.31 aunque la vuestra supongo que estará bien.
Pero SOBRE TODO, hay dos cosas que son demasiado antiguas, MySQL y PHP. La recomendación con MySQL es actualizar a la 4.x más reciente (se nota mucho con las caches activadas). Y con PHP no lo llamaría recomendación sino OBLIGACIÓN. Desde la 4.1.2 que estáis corriendo hasta la 4.3.9 actual ha llovido muchísimo. El número de bugs corregidos es impresionante y seguro que si actualizáis el sistema será mucho más estable (yo utilizo la 4.3.8).
Supongo que esos paquetes estarán disponibles para RH7.3. En caso contrario tendríais que recompilarlos....supongo que no necesitarán nada que no tenga RH 7.3
En resumen, que si bien la versión de RedHat es acertada y la de apache parece no estar mal, creo que resultaría interesante la actualización de MySQL y, sobre todo, de PHP.
Ciao
PD: Insisto en que los problemas que os presenta el servidor podrían no deberse a todo el tema de versiones y configuraciones que hemos comentado en esta discussión, aunque por lo menos así tendréis una base instalada bastante más estable. Tenéis otros servidores con la misma configuración? Dan los mismos problemas?
La versión 7.3 de RedHat es la que mejor fama tiene (mucho mejor que la 8, desde luego y la 9 y Fedora no las he probado), aunque va siendo algo viejilla. En cualquier caso no debería producir mayor problema.
Otra cosa son las versiones de PHP, MySQL y Apache. De apache, sin pasar a la 2.x, la última que hay es la 1.3.31 aunque la vuestra supongo que estará bien.
Pero SOBRE TODO, hay dos cosas que son demasiado antiguas, MySQL y PHP. La recomendación con MySQL es actualizar a la 4.x más reciente (se nota mucho con las caches activadas). Y con PHP no lo llamaría recomendación sino OBLIGACIÓN. Desde la 4.1.2 que estáis corriendo hasta la 4.3.9 actual ha llovido muchísimo. El número de bugs corregidos es impresionante y seguro que si actualizáis el sistema será mucho más estable (yo utilizo la 4.3.8).
Supongo que esos paquetes estarán disponibles para RH7.3. En caso contrario tendríais que recompilarlos....supongo que no necesitarán nada que no tenga RH 7.3
En resumen, que si bien la versión de RedHat es acertada y la de apache parece no estar mal, creo que resultaría interesante la actualización de MySQL y, sobre todo, de PHP.
Ciao
PD: Insisto en que los problemas que os presenta el servidor podrían no deberse a todo el tema de versiones y configuraciones que hemos comentado en esta discussión, aunque por lo menos así tendréis una base instalada bastante más estable. Tenéis otros servidores con la misma configuración? Dan los mismos problemas?
Gracias Eloy, el problema está solucionado, aunque el tiempo lo confirmará. Era un problema de permisos del mysql, que nada tiene que ver con moodle . Sencillamente no se generaba el pid de mysql y este al consultar este fichero y no encontrarlo se bloqueaba.
De todas formas corregimeros el tema de las versiones.
Saludos,
¿Alguien tiene una buena guía de administración de MySQL para recomendar? Además de MySQLAdmin como herramienta de administración, recomiendan alguna otra? para ver los errores, performance y funcionamiento en gral.
Gracias y saludos
Paola