Hola a todos !!
soy administrador moodle en la URV,tengo instalado el 1.5.4+ el problema q me tiene preocupado es la tabla mdl_log ( ha crecido desmesuradamente, unos 10 millones de registros ) y ralentiza mucho el servicio. Para accelerar un poco el moodle he vaciado los logs de los cursos del año anterior y he creado un INDEX en el campo info.
Ha mejorado, pero estoy por crear otro INDEX en el campo url, ya q me he fijado q en la tabla de mdl_log del 1.6 tb esta creado este index tb.
Otra solucion q he pensado en aplicar es pasar a postgreSQL, pero la base de datos en dos RAIDs de disco, uno solo para mdl_log y el resto de tablas, con el otro. Habeis probado esta solucion ??
Otra solución posible q estos dias me esta rondando es instalar Oracle para la base de datos, pero como veo q es de nueva implantación no me acabo de fiar para una instalacion tan grande.
Detalles de la instalacion:
Tenemos 21250 usuarios, unos 5000 usuarios q lo usan regularmente. El servidor de moodle esta instalado en un balanceador de carga para el apache y los datos, y la base de datos es una mysql 4.3 sin balanceador de carga.
Saludos
Creo que si planteas esto en el foro en inglés 'Hardware and performance' tendrás más probabilidades de obtener una respuesta útil que aquí. Yo al menos no manejo instalaciones tan grandes y mi experiencia con asuntos como los que planteas es entre cero y nada (tomando el menor de los dos límites 
)
Saludos. Iñaki.
Saludos. Iñaki.
Gracias por el consejo. Tb lo enviaré allí.
Buen día :
No sé si es el mejor consejo, pero, si no estás verificando los registros log's continuamente , por cuestiones de Auditoría Informática, sigue los sgts. pasos :
1. Exporta la tabla mld_log,
2. Luego depura dicha tabla.. borrando el contenido que ya tienes exportado,
3. Establece un periodo para hacer los dos pasos anteriores, guardando adecuamente los registros, por lo tanto, los medios magnéticos que almacenan estos últimos.
Salu2
No sé si es el mejor consejo, pero, si no estás verificando los registros log's continuamente , por cuestiones de Auditoría Informática, sigue los sgts. pasos :
1. Exporta la tabla mld_log,
2. Luego depura dicha tabla.. borrando el contenido que ya tienes exportado,
3. Establece un periodo para hacer los dos pasos anteriores, guardando adecuamente los registros, por lo tanto, los medios magnéticos que almacenan estos últimos.
Salu2
En respuesta a Joan Vicent Navarro Ferreres
Re: Problemas de rendimiento
Hola Joan Vicent,
si bien es cierto, que la tabla de logs puede llegar a alcanzar unas dimensiones impresionantes, la verdad es que no debería influir demasiado en el rendimiento global del sistema.
En ella se realizan continuamente inserciones de 1 registro que no tendrían porque degradar el sistema demasiado.
Otro cantar son los accesos que se realizan a la misma, especialmente por algunos bloques, como el de actividad reciente o el de usuarios online. Estos accesos, si no se realizan mediante los correspondientes índices, si que pueden tener su impacto, sobre todo, en la portada de los cursos, que es donde se ejecutan. Es de suponer que liberando a la portada de alguno de estos bloques, ganes algo de velocidad en ella. El resto de las páginas no deberían verse demasiado afectados por el tamaño de la tabla de logs.
En cuanto al índice que comentas, por URL, la verdad es que ahorita mismo no puedo imaginarme en dónde exáctamente es utilizado, pero no me suena que sea del todo crítico y que vayas a experimentar una mejora notable (aunque es posible que me esté equivocando).
Una utilidad que es recomendable ejecutar periódicamente si la BD está comenzando a tener cierta envergadura, es el ANALYZE table (que, con unos nombres u otros lo tienen todas las BD) y lo que hace es calcular los usos optimos (índices a utilizar, orden de mezclas...) que realizará la BD al ejecutar distintas consultas. Si nunca lo has ejecutado, seguramente tenga su impacto. Idem del OPTIMIZE table, que sirve para re-ordenar la estructura interna de las tablas, que es posible que, con el tiempo, tengan un magnífico desorden interno, lo que se traduce en una pérdida de rendimiento general.
En cuanto a Oracle, bueno, no está mal del todo el motorcillo, pero considera que la 1.7 es la primera versión que soporta Oracle, por lo que, indefectiblemente, está mucho más expuesta a errores y problemas aún no detectados (especialmente conociendo las "tonterías" que obliga esa BD a implementar en el código para que, operaciones de lo más sencillo en otras BD, funcionen correctamente). Así que yo iría utilizádola en desarrollo y tal y cual, pero, sinceramente, entrar con ella directamente a producción, uhm... tú mismo.
Por último, es casi seguro que, en la parte de tunning de Apache/MySQL puedes hacer grandes cosas (número de conexiones, cachés, aceleradores de PHP, timeouts...). Muchas veces es increíble lo que se puede conseguir tocando 2 ó 3 parámetros. Te recomiendo que eches un vistazo al foro que te comentaban antes, ya que allí hay volcada un montón de casuística con soluciones concretas, eso sí, siempre partiendo de saber qué es lo que va lento en tu/s servidores (con datos de carga, memoria, accesos concurrentes...).
En fín, todo un mundo, pero con solución casi siempre
Ciao
si bien es cierto, que la tabla de logs puede llegar a alcanzar unas dimensiones impresionantes, la verdad es que no debería influir demasiado en el rendimiento global del sistema.
En ella se realizan continuamente inserciones de 1 registro que no tendrían porque degradar el sistema demasiado.
Otro cantar son los accesos que se realizan a la misma, especialmente por algunos bloques, como el de actividad reciente o el de usuarios online. Estos accesos, si no se realizan mediante los correspondientes índices, si que pueden tener su impacto, sobre todo, en la portada de los cursos, que es donde se ejecutan. Es de suponer que liberando a la portada de alguno de estos bloques, ganes algo de velocidad en ella. El resto de las páginas no deberían verse demasiado afectados por el tamaño de la tabla de logs.
En cuanto al índice que comentas, por URL, la verdad es que ahorita mismo no puedo imaginarme en dónde exáctamente es utilizado, pero no me suena que sea del todo crítico y que vayas a experimentar una mejora notable (aunque es posible que me esté equivocando).
Una utilidad que es recomendable ejecutar periódicamente si la BD está comenzando a tener cierta envergadura, es el ANALYZE table (que, con unos nombres u otros lo tienen todas las BD) y lo que hace es calcular los usos optimos (índices a utilizar, orden de mezclas...) que realizará la BD al ejecutar distintas consultas. Si nunca lo has ejecutado, seguramente tenga su impacto. Idem del OPTIMIZE table, que sirve para re-ordenar la estructura interna de las tablas, que es posible que, con el tiempo, tengan un magnífico desorden interno, lo que se traduce en una pérdida de rendimiento general.
En cuanto a Oracle, bueno, no está mal del todo el motorcillo, pero considera que la 1.7 es la primera versión que soporta Oracle, por lo que, indefectiblemente, está mucho más expuesta a errores y problemas aún no detectados (especialmente conociendo las "tonterías" que obliga esa BD a implementar en el código para que, operaciones de lo más sencillo en otras BD, funcionen correctamente). Así que yo iría utilizádola en desarrollo y tal y cual, pero, sinceramente, entrar con ella directamente a producción, uhm... tú mismo.
Por último, es casi seguro que, en la parte de tunning de Apache/MySQL puedes hacer grandes cosas (número de conexiones, cachés, aceleradores de PHP, timeouts...). Muchas veces es increíble lo que se puede conseguir tocando 2 ó 3 parámetros. Te recomiendo que eches un vistazo al foro que te comentaban antes, ya que allí hay volcada un montón de casuística con soluciones concretas, eso sí, siempre partiendo de saber qué es lo que va lento en tu/s servidores (con datos de carga, memoria, accesos concurrentes...).
En fín, todo un mundo, pero con solución casi siempre
Ciao
En respuesta a Eloy Lafuente (stronk7)
Re: Problemas de rendimiento
Hola !!
perdon por el retraso en contestar. Analyze y Optimize han mejorado el rendimiento, ya lo tenia previsto, no el analyze, pero si el optimize. Lo de tocar los parametros sera complicado, ya q la maquina de explotacion "no tengo poderes de dios" y probando sobre la maquina de desarrollo, no es lo mismo.
el problema basico es q si alguien sacaba informes ( varios concurrentes ), a parte de no acabar la peticion, se bloqueaban las peticiones y el rendimiento del moodle era patetico ( 10 Mll de registros son muchos ).
Ahora estoy probando todas las posibilidades q se me plantean. Ya os pasare informe de la situacion.
perdon por el retraso en contestar. Analyze y Optimize han mejorado el rendimiento, ya lo tenia previsto, no el analyze, pero si el optimize. Lo de tocar los parametros sera complicado, ya q la maquina de explotacion "no tengo poderes de dios" y probando sobre la maquina de desarrollo, no es lo mismo.
el problema basico es q si alguien sacaba informes ( varios concurrentes ), a parte de no acabar la peticion, se bloqueaban las peticiones y el rendimiento del moodle era patetico ( 10 Mll de registros son muchos ).
Ahora estoy probando todas las posibilidades q se me plantean. Ya os pasare informe de la situacion.
En respuesta a Joan Vicent Navarro Ferreres
Re: Problemas de rendimiento
Hola Vicent.
Nosotros en la UPC tenemos actualmente un log de unos 19Mll de registros y el sistema no se resiente para nada (a no ser que realices consultas duras directamente sobre la tabla, por supuesto
)
Como tenemos un crecimiento de unos 2-3Mll por mes, estamos pensando en "cocinar" los datos y vaciar la tabla por periodos, aunque lo haremos para tener indicadores agregados optimizados más que por rendimiento.
Igual que vosotros, estamos en la versión 1.5.4+ de moodle pero utilizamos PostgreSQL y no hemos tenido que crear ningún índice adicional en esa tabla.
Si el problema crees que es ese, te recomiendo que intentes vaciar la tabla o pasarte a postgreSQL.
Saludines,
NAcho
Nosotros en la UPC tenemos actualmente un log de unos 19Mll de registros y el sistema no se resiente para nada (a no ser que realices consultas duras directamente sobre la tabla, por supuesto
)Como tenemos un crecimiento de unos 2-3Mll por mes, estamos pensando en "cocinar" los datos y vaciar la tabla por periodos, aunque lo haremos para tener indicadores agregados optimizados más que por rendimiento.
Igual que vosotros, estamos en la versión 1.5.4+ de moodle pero utilizamos PostgreSQL y no hemos tenido que crear ningún índice adicional en esa tabla.
Si el problema crees que es ese, te recomiendo que intentes vaciar la tabla o pasarte a postgreSQL.
Saludines,
NAcho
En respuesta a Nacho Ruiz de Erenchun
Re: Problemas de rendimiento
IEPPPP, veo q tienes una situación como la q yo quiero.
Balanceador de carga httpd y una base de datos Postgres detras, con 2 RAIDs separados ( un solo para la table de logs ) ????
veo q usas la solución q me esta dando vueltas por la cabeza desde hace dias, sin actualizar el moodle.
la otra q he pensado q puede ser actualizar a la 1.7 pero con postgres o Oracle, pero por lo he estado viendo Oracle, no tiene muchos segudiores, por no decir casi ninguno ( al tener licencia es una alternativa a probar ).
La q si q veo q no hay forma es con mysql ( con un log tan gran se "hunde en la miseria" ).
Lo de vaciar ya lo he hecho ( destruyendo los logs de los cursos del año pasado, no destruimos los cursos del cursos anterior)
Balanceador de carga httpd y una base de datos Postgres detras, con 2 RAIDs separados ( un solo para la table de logs ) ????
veo q usas la solución q me esta dando vueltas por la cabeza desde hace dias, sin actualizar el moodle.
la otra q he pensado q puede ser actualizar a la 1.7 pero con postgres o Oracle, pero por lo he estado viendo Oracle, no tiene muchos segudiores, por no decir casi ninguno ( al tener licencia es una alternativa a probar ).
La q si q veo q no hay forma es con mysql ( con un log tan gran se "hunde en la miseria" ).
Lo de vaciar ya lo he hecho ( destruyendo los logs de los cursos del año pasado, no destruimos los cursos del cursos anterior)
En respuesta a Joan Vicent Navarro Ferreres
Re: Problemas de rendimiento
Joan,
supongo que te quedaste a nuestra ponencia sobre rendimiento en la última MoodleMoot. Allí expusimos nuestra arquitectura y puedes utilizarla como base para vuestras mejoras.
Por si te la perdiste (o quieres recordarla), la tienes en línea gracias a Javi Legarreta y su equipo --> http://www.sre.urv.es/moodlemootcd/dimarts19/eribot02.pdf
Saludines,
NAcho
supongo que te quedaste a nuestra ponencia sobre rendimiento en la última MoodleMoot. Allí expusimos nuestra arquitectura y puedes utilizarla como base para vuestras mejoras.
Por si te la perdiste (o quieres recordarla), la tienes en línea gracias a Javi Legarreta y su equipo --> http://www.sre.urv.es/moodlemootcd/dimarts19/eribot02.pdf
Saludines,
NAcho
pero por lo he estado viendo Oracle, no tiene muchos segudiores, por no decir casi ninguno
Nosotros en la Universidad de Mondragon estamos arrancando ahora una instalación que va con Oracle. De momento ya llevamos 3 bugs encontrados (hola Eloy, el tercero aún lo ho he metido en el tracker ), así que la cosa va con mucha calma.
Por suerte tenemos gente que controla Oracle y entre unos y otros vamos puliendo la cosa.
Desde el punto de vista del rendimiento no tenemos datos de comparativa muy válidos, ya que la otra instalación de producción usa una máquina y un entorno de ejecución muy diferente (Linux+Postgres frente a Windows+Oracle).
Saludos. Iñaki.
Windows + Oracle ! 
Mi combinación preferida!
Sin comentarios...
Ciao
Mi combinación preferida!
Sin comentarios...
Ciao
Es decisión de quienes lo están montando y lo van a mantener. En todo caso, la culpa la tenéis vosotros, por implementar soporte para Oracle 
Antes de salir la 1.7, la maqueta iba con Postgres, pero al aparecer la posibilidad de usar Oracle (que ya se usa para todo el sistema de gestión académica y tener mucha experiencia con él) se pasó todo a Oracle para no tener que dar soporte (y tener gente que dominara) otro sgbd más.
Lo de Windows es poco más o menos más de lo mismo. En todo caso, yo puedo sugerir cosas (y a veces incluso me hacen caso), pero la decisión está completamente fuera de mis manos.
La instancia que se usa en producción en la Facultad de Empresariales (que es donde me dejan romper cosas) si va con Linux + Postgres, pero seguramente a finales de curso se migre al sistema Windows + Oracle, que es el que en teoría dará servicio a toda la universidad de forma conjunta.
En todo caso, como suelo decir yo en estos casos: mientras no me toque administrarlo o mantenerlo a mí, que pongan lo que quieran
Saludos. Iñaki.
Antes de salir la 1.7, la maqueta iba con Postgres, pero al aparecer la posibilidad de usar Oracle (que ya se usa para todo el sistema de gestión académica y tener mucha experiencia con él) se pasó todo a Oracle para no tener que dar soporte (y tener gente que dominara) otro sgbd más.
Lo de Windows es poco más o menos más de lo mismo. En todo caso, yo puedo sugerir cosas (y a veces incluso me hacen caso), pero la decisión está completamente fuera de mis manos.
La instancia que se usa en producción en la Facultad de Empresariales (que es donde me dejan romper cosas) si va con Linux + Postgres, pero seguramente a finales de curso se migre al sistema Windows + Oracle, que es el que en teoría dará servicio a toda la universidad de forma conjunta.
En todo caso, como suelo decir yo en estos casos: mientras no me toque administrarlo o mantenerlo a mí, que pongan lo que quieran
Saludos. Iñaki.
Bueno,
yo lo puedo decir más claro, pero no más alto. Y que conste que Oracle me suena de algo desde hace ya unos cuantos lustros (es mi base de datos del alma, con la que aprendí todo lo que sé, con la que sigo trabajando, codo con codo, en el día a día de los avatares de nuestros sistemas de gestión
).
Pero sobre todo, que conste que soy una de las personas que se han pegado (he dicho pegado, sí, buena definición, pardiez!
) con la actual implementación en Moodle de Oracle y, aunque funciona, la cantidad de "DIRTY HACKS" que hay en el código para que funcione debería desanimar a nada que se pierdan 5 minutos mirando, por poner un ejemplo, algo tan central y utilizado como dmllib.php (el corazón del manejo de BD de Moodle).
Seguro que lo habéis/han hecho en tu Universidad así que ahí va la pregunta de lo más inocente. ¿Qué tal han ido las pruebas de rendimiento? ¿Alguna comparativa?
Y me voy callando, que son demasiadas varas para ponerme tal camisa. Que si quieres arroz, Catalina. El que avisa no es traidor! Aunque, como a mí tampoco me va a tocar administrarlo, plim.
Ciao
yo lo puedo decir más claro, pero no más alto. Y que conste que Oracle me suena de algo desde hace ya unos cuantos lustros (es mi base de datos del alma, con la que aprendí todo lo que sé, con la que sigo trabajando, codo con codo, en el día a día de los avatares de nuestros sistemas de gestión
Pero sobre todo, que conste que soy una de las personas que se han pegado (he dicho pegado, sí, buena definición, pardiez!
Seguro que lo habéis/han hecho en tu Universidad así que ahí va la pregunta de lo más inocente. ¿Qué tal han ido las pruebas de rendimiento? ¿Alguna comparativa?
Y me voy callando, que son demasiadas varas para ponerme tal camisa. Que si quieres arroz, Catalina. El que avisa no es traidor! Aunque, como a mí tampoco me va a tocar administrarlo, plim.
Ciao
> Seguro que lo habéis/han hecho en tu Universidad así que ahí va la pregunta de lo más inocente. ¿Qué tal han ido las pruebas de rendimiento? ¿Alguna comparativa?
La verdad, por ahora las pruebas han sido no demasiado buenas, por lo que me cuentan (yo no llevo directamente el tema, sólo como de vez en cuando con quien lo lleva y solemos charlar del asunto, y de vez en cuando me pide ayuda para alguna pega con el código).
No sé hasta que punto han hecho 'tunning' del sistema. Si sé que tienen la cosa repartida en dos máquinas (Oracle está aparte, y el resto en el mismo servidor). En todo caso, creo que por ahora se están centrando sobre todo en que funcione de forma estable (ya conoces los bugs que hemos ido encontrando y luego pasarán a la fase de ajuste.
Sé que es comparar peras con manzanas, porque ni el hardware del servidor es el mismo (la máquina Linux tiene más RAM y los procesadores son más rapidos) ni el sistema operativo ni la arquitectura es la misma (dos máquinas separadas, frente a una con todo, además de tener instado el acelerador APC en la máquina Linux), ni los temas de Moodle (que algo pueden influir) pero las diferencias de tiempo de generación de las páginas es bastante significativa entre la máquina Linux + Postgres y la solución Windows + Oracle.
Según los datos que perfdebug imprime en el pie de las páginas, hay una diferencia de casi 5x a favor de Linux + Postgres (entre 0,3 y 2 segundos en la máquina Linux según las páginas, frente a de 3 a 9 segundos en la máquina Oracle). Repito: que nadie tome los anteriores datos como significativos de nada, porque estamos comparando dos instalaciones completamente diferentes.
En todo caso hay muchos más condicionantes que el mero rendimiento como he comentado en mi mensaje anterior. Y esos condicionantes son importantes para quienes tienen que mantener la plataforma, así que entiendo (aunque no comparta del todo) su decisión.
Recuerda que siempre puedes echar más hierro al asunto para que vaya más deprisa (y suele ser más fácil conseguir más hierro que gente experta en un área dada; especialmente si hay cierta reticiencia a formarse en el área en cuestión o la incorporación de nuevo personal es problemática -por decirlo suavemente- )
Saludos. Iñaki.
Tengo entendido que mysql tiene sistemas de ficheros "de pago" que aceptan transacciones y volumenes absurdos de datos. Lo que no haria es jugarmela con oracle... tuve mis experiencias con el en el pasado y no lo aconsejaria para un entorno de tipo Moodle a no ser que te guste el Logo
En la UPC tenemos postgres (como ya ha dicho nacho ) y tira de maravilla...
Ludo
En la UPC tenemos postgres (como ya ha dicho nacho ) y tira de maravilla...
Ludo
Hola, Nacho.
Veo que administras un sitio de muchísimo tráfico y me gustaría pedirte consejo para mi instalación de Moodle, que actualmente (por tercera vez en los últimos meses) está fuera de servicio debido a un fallo con el servidor de nuestro ISP (Hosting LMI, que para colmo está "desaparecido, sin dar la cara").
En mi instalación teníamos ya registrados 1200 usuarios e íbamos creciendo exponencialmente antes de que todo se fuese al traste. Estamos buscando una alternativa de hosting de calidad y que sea fiable para un sitio Moodle grande como el nuestro. Actualmente estamos haciendo pruebas con ARSYS y un servdor dedicado, pero por ahora nos da problemas con la versión de php y otras cosillas.
¿Dónde lo tenéis alojado vosotros? ¿Puedes hacerme una recomendación?
Un millón de gracias por tu atención.
Carlos Guerrero,
Co-administrador de www.safaedu/aulavirtual (cuando funcionaba, claro)
Hola, Carlos.
Te recomiendo Comvive Servidores (www.comvive.com) son de Sevilla y trabajan muy bien (lo mismo están cerca de ti
Los servidores van sobre Debian 3.1 y la configuración según desees (procesador, RAM, discos duros, etc.)
Siento lo de Hosting LMI parece que ha habido algún problema en la directiva y se han separado en 2 empresas.
Saludos y a cuidarse.
Te recomiendo Comvive Servidores (www.comvive.com) son de Sevilla y trabajan muy bien (lo mismo están cerca de ti
Los servidores van sobre Debian 3.1 y la configuración según desees (procesador, RAM, discos duros, etc.)
Siento lo de Hosting LMI parece que ha habido algún problema en la directiva y se han separado en 2 empresas.
Saludos y a cuidarse.
Muchas gracias, Jose.
Habrá que valorarlo.
Saludos
Perdona por no responderte antes.
Al ser el campus de la UPC, nuestro moodle está alojado en el CPD de la propia universidad y somos nosotros los que velamos por la disponibilidad del servicio.
Lamento no poder orientarte en este aspecto.
Un saludo,
NAcho
Al ser el campus de la UPC, nuestro moodle está alojado en el CPD de la propia universidad y somos nosotros los que velamos por la disponibilidad del servicio.
Lamento no poder orientarte en este aspecto.
Un saludo,
NAcho