Saludos a todos...
Necesito su punto de vista y su ayuda por favor....
En mi institución usamos el Moodle 1.9 y manejamos una distribución por capas:
Servidor de BD: HP Proliant
2 procesadores Intel Xeon 3.40 GHz
4GB de Memoria.
Servidor web: IBM Blade
2 procesadores Intel Xeon 1.60 GHz
4GB de Memoria.
Manejamos alrededor de 30000 usuarios y en promedio 250 conexiones concurrentes. El problema es que con el HW que tenemos no parece suficiente porque existen fechas críticas en que sobrepasan las 200 conexiones, se bloquea la base de datos y el load average llega hasta 6, 10. Hemos optimizado algunas consultas con índices, y configurado el my.cnf, mejoró la situación pero no para los tiempos críticos.
Depende más del Webserver o del DatabaseServer??
Al servidor de Base de datos, lo hemos configurado de esta forma:
max_connections = 300
datadir=/database/mysql
log-bin=/var/log/mysql/bin.log
port = 3306
socket = /var/lib/mysql/mysql.sock
skip-locking
key_buffer = 1024M
max_allowed_packet = 1M
table_cache = 512
sort_buffer_size = 2M
read_buffer_size = 2M
read_rnd_buffer_size = 8M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size = 32M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 4
long_query_time=3
log-slow-queries=/var/log/mysql/log-slow-queries.log
y esta es la consulta que siempre se registra en slow_query, pero la verdad no se como optimizarla....Alguna sugerencia___???
SELECT c.id,c.sortorder,c.shortname,c.idnumber,c.category,c.fullname,c.teacher,c.teachers,c.student,c.students,c.guest,c.startdate,c.visible,c.newsitems,c.cost,c.enrol,c.groupmode,c.groupmodeforce,c.summary,
ctx.id AS ctxid, ctx.path AS ctxpath,
ctx.depth AS ctxdepth, ctx.contextlevel AS ctxlevel,
cc.path AS categorypath
FROM mdl_course c
JOIN mdl_course_categories cc
ON c.category=cc.id
JOIN mdl_context ctx
ON (c.id=ctx.instanceid AND ctx.contextlevel=50)
LEFT OUTER JOIN mdl_role_assignments ra
ON (ra.contextid=ctx.id AND ra.userid=16734)
LEFT OUTER JOIN mdl_role_capabilities rc
ON (rc.contextid=ctx.id AND (rc.capability='moodle/course:view' ))
WHERE (ra.id IS NOT NULL
OR rc.id IS NOT NULL)
AND c.enrolenddate > 1234830078
ORDER BY cc.name ASC, c.visible DESC,c.fullname ASC;
Como mejorar el rendimiento de Moodle (30000 usuarios)
Número de respuestas: 7
En respuesta a Martha Vanessa Agila P.
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Xavier Paz -
Según tengo entendido, el consumo de memoria está en 1 GB por cada 50 accesos concurrentes. Por tanto, en tu caso es normal que la plataforma se ralentice.
Por otro lado, ¿esa consulta es propia o es parte de alguna de las funciones de Moodle? ¿No hay forma de partirla?
Por otro lado, ¿esa consulta es propia o es parte de alguna de las funciones de Moodle? ¿No hay forma de partirla?
En respuesta a Xavier Paz
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
La consulta es propia de moodle, y lo de la memoria si vi en un post la relación 1GB - 50 usuarios, pero no es solo la memoria porque cuando pasa eso, pongo el top y el porcentaje de memora usado es máximo 10%, justo ahora esyoy con ese problema y mira el top:
top - 07:30:07 up 36 days, 19:48, 5 users, load average: 20.86, 10.32, 4.71
Tasks: 90 total, 3 running, 87 sleeping, 0 stopped, 0 zombie
Cpu(s): 79.2% us, 20.8% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4086472k total, 4014724k used, 71748k free, 202908k buffers
Swap: 4194296k total, 168k used, 4194128k free, 3192680k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29151 mysql 15 0 1232m 356m 3820 S 205 8.9 1899:46 mysqld
26641 apache 16 0 44040 17m 4660 S 0 0.5 0:02.38 httpd
Y solamente hay 43 conexiones de mysql
O la configuración del my.cnf influye en el procesador, es suficiente mi procesador para la configuración realizada_???? adjunto mi my,cnf
top - 07:30:07 up 36 days, 19:48, 5 users, load average: 20.86, 10.32, 4.71
Tasks: 90 total, 3 running, 87 sleeping, 0 stopped, 0 zombie
Cpu(s): 79.2% us, 20.8% sy, 0.0% ni, 0.0% id, 0.0% wa, 0.0% hi, 0.0% si
Mem: 4086472k total, 4014724k used, 71748k free, 202908k buffers
Swap: 4194296k total, 168k used, 4194128k free, 3192680k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29151 mysql 15 0 1232m 356m 3820 S 205 8.9 1899:46 mysqld
26641 apache 16 0 44040 17m 4660 S 0 0.5 0:02.38 httpd
Y solamente hay 43 conexiones de mysql
O la configuración del my.cnf influye en el procesador, es suficiente mi procesador para la configuración realizada_???? adjunto mi my,cnf
En respuesta a Martha Vanessa Agila P.
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Sergio Alfaro -
De acuerdo a lo que veo creo que debes necesariamente balancear las cargas.
Tengo algunas instalaciones que administro con mas de 35000 usuarios y se solucionó con eso.
A continuación te envío algunos links respecto al balance de cargas que me fueron muy util.
http://blogs.sun.com/dadelhardt/entry/loadbalancing_with_mod_jk_and_glassfish
http://tuxitos.es/2008/07/28/balanceo-de-carga-entre-servidores-web-apache/
A continuacion te copio un articulo muy interesante de un balanceo para Moodle publicado por Guadalupe Susana Ramos Palacios y Ulises Valderrama Abad
Tengo algunas instalaciones que administro con mas de 35000 usuarios y se solucionó con eso.
A continuación te envío algunos links respecto al balance de cargas que me fueron muy util.
http://blogs.sun.com/dadelhardt/entry/loadbalancing_with_mod_jk_and_glassfish
http://tuxitos.es/2008/07/28/balanceo-de-carga-entre-servidores-web-apache/
A continuacion te copio un articulo muy interesante de un balanceo para Moodle publicado por Guadalupe Susana Ramos Palacios y Ulises Valderrama Abad
Descripción del sistema
Un cluster es un conjunto de servidores Web que por medio y junto con un servidor llamado balanceador de carga, permite dar la apariencia de ser un solo servidor Web (virtual). El balanceador de carga debe contar con dos paquetes de software: ipvsadm y Linux Virtual Server (LVS), los cuales distribuyen las conexiones entre todos los servidores Web que responderán a un mismo dominio asociado a la dirección IP del balanceador.
Colocado al frente de los servidores Web, el balanceador de carga es el receptor de las peticiones hechas al dominio asociado a su dirección IP para repartirlas por la red local entre todos los servidores Web que responden a un dominio. Por medio de un criterio de distribución llamado Weighted Least-Connection (wlc) se asigna un valor de rendimiento a cada servidor, donde la asignación de peso a un servidor (weight de 1 a 3) determinará la cantidad de peticiones recibidas aplicando el criterio de weight. Con el criterio de least-connection se mandarán más peticiones al servidor que tenga menos conexiones activas, tratando de que los servidores con el mismo peso se mantengan con un número de conexiones similares.
El balanceador de carga es simplemente la puerta que da entrada al conjunto de servidores. Las peticiones llegan a un dominio y el balanceador las redirecciona a uno que en realidad hace el trabajo.
Es importante mencionar que todos los servidores Web deben responder al mismo dominio, contar con la misma información y proveer el mismo servicio, de forma que sin importar cuál de ellos responda, el usuario reciba la misma información en la respuesta.
Con el software ipvsadm el equipo balanceador de carga maneja diferentes criterios de balanceo, entre ellos:
- rr - Robin Robin: distribuye las peticiones en cantidades iguales entre los servidores del cluster.
- wrr - Weighted Round Robin: asigna las nuevas peticiones entre los servidores del cluster de manera proporcional a su peso. Los que tengan mayor peso recibirán más peticiones que los de menor peso. Los servidores con pesos iguales recibirán el mismo número de nuevas peticiones.
- lc - Least-Connection: asigna más peticiones entrantes al servidor con menor número de conexiones.
- wlc - Weighted Least-Connection: asigna peticiones entrantes a los servidores con menor número de conexiones y mayor peso.
- lblc - Locality-Based Least-Connection: asigna peticiones entrantes destinadas a una misma IP al mismo servidor, si éste no está sobrecargado. De otro modo, las asigna a los servidores con menor actividad y lo guarda para una futura asignación.
- lblcr - Locality-Based Least-Connection with Replication: asigna peticiones entrantes destinadas a la misma IP al nodo con menos conexiones del conjunto de servidores que tienen la misma IP. Si todos los nodos de este conjunto están sobrecargados, envía la petición a otro con menos conexiones en el cluster y lo agrega al conjunto. Si el servidor no ha sido modificado durante un tiempo especificado, el nodo más sobrecargado en este conjunto es removido para evitar un alto grado de replicación.
Por otra parte, los clusters desarrollados con Linux Virtual Server posibilitan la implementación de tres tipos de arquitectura para el manejo de las peticiones y el direccionamiento entre el balanceador de carga y los servidores web.
- Arquitectura de direccionamiento directo
- Arquitectura vía túnel de IP
- Arquitectura vía NAT
La arquitectura de direccionamiento directo consiste en tener conectados físicamente los servidores Web junto con el balanceador de carga dentro de un segmento LAN ininterrumpido por medio de un dispositivo activo de interconexión como un Switch Ethernet.
En esta arquitectura, el balanceador redirecciona las peticiones entrantes al servidor Web elegido, al cambiar la dirección MAC (Medium Access Control) del encabezado de los paquetes que contienen las peticiones, por aquella que le pertenece al servidor Web asignado y los retransmite a través de la red local (LAN).
El balanceador de carga es un equipo que no necesita demasiados recursos, pues su actividad consiste en redireccionar las peticiones a los servidores Web que son en realidad los que realizan todo el trabajo de la plataforma de educación a distancia. Puede considerarse un equipo con una capacidad mínima de memoria de 2GB, un procesador P IV a 2 GHz y espacio en disco de al menos 2GB. Requiere tener instalado SO Linux, Kernel 2.6.x o más e ipvsadm. Actualmente equipos más sofisticados que realizan la función de balanceo, con una arquitectura diseñada para ello.
Aunque los requerimientos de los servidores Web pueden variar, dependiendo del tipo de aplicación que alberguen y del de páginas electrónicas que contengan (estáticas o dinámicas), en el caso de la plataforma Moodle las características dependerán del número de cursos, alumnos, tutores y asesores que existan. En cuanto al SW, se requiere SO, Linux Red Hat EL 4, Apache 1.3.41, MySQL 5.0.41 y PHP 4.4.7
En diversas pruebas de este sistema se observa que el balanceador de carga redireccionó todas las peticiones entrantes haciendo que los servidores de Web atendieran el mismo número de ellas, obteniendo así lo esperado de acuerdo con el criterio de balanceo de Round Robin e impidiendo la sobresaturación de los equipos. Además, el balanceador no consume muchos recursos de hardware, pues sólo redirecciona las peticiones entrantes y los que sí consumen recursos son los servidores Web que atenderán las solicitudes enviadas por el balanceador.
Alcances del cluster balanceador de carga
- No hace uso excesivo de recursos de hardware por lo que puede implementarse fácilmente en un equipo con las características mínimas antes descritas.
- Puede ser fácilmente escalable. Sólo basta con agregar el nuevo servidor al balanceador para que comience a recibir peticiones.
- Funcionalidad permanente. A pesar de que uno de los servidores sufra una falla de software o hardware, el resto sigue respondiendo a las peticiones y el servidor dañado puede sacarse fácilmente del cluster dándolo de baja del balanceador.
- Bajo costo por trabajar con software libre y permite integrar equipos con diferentes características de hardware.
- Cuando la petición de un usuario es redireccionada a un servidor, éste atenderá la solicitud durante el tiempo en el que el usuario se encuentre conectado al sistema. Cuando el mismo usuario realiza una nueva petición, el balanceador se encargará de redireccionar su petición a uno de los servidores disponibles, por lo que puede o no ser atendido por el mismo servidor del cluster.
- Transparente para el usuario. Nunca percibirán si su petición es redireccionada a uno u otro servidor del cluster.
- No hay replica de la información contenida entre todos los servidores Web. Esta información debe ser exactamente igual en todos los servidores, por lo que para cumplir con este requisito, es necesario contar con un esquema de replicación entre estos equipos.
Limitaciones del cluster balanceador de carga
- El cluster tiene un punto de falla importante: el balanceador de carga. Si éste llegara a fallar, ningunos de los servidores Web podrá atender las peticiones de los usuarios pues es él quien decide cuál de los servidores atenderá a cada una de las peticiones. Por esta razón es importante contar con un esquema de alta disponibilidad en este equipo, ya que si en algún momento falla el balanceador principal, puede entrar en funcionamiento uno secundario.
- El cluster no presenta un “cuello de botella”. Todos los servidores de Web, una vez que han recibido la petición redirigida por el balanceador, atienden a dicha petición y envían la respuesta directamente al usuario, por lo que la respuesta no pasa de nuevo por el balanceador, evitando así un “cuello de botella”.
En respuesta a Martha Vanessa Agila P.
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Camilo Nieto -
Hola todos ,
Tengo un inconveniente parecido al de Martha Vanessa Agila , primero describire el HW que tenemos:
Servidor Virtualizado Linux Red Had 5.2 Enterprice, memoria de 8GB, 2 procesadores Intel Xeon 3.0 Ghz doble nucleo y 15000 usuarios.
Comento el problema y lo que se ha realizado hasta el momento:
Inicialmente, cuando ingresaron todos los estudiantes la plataforma se volvio lenta permanentemente, realizamos un processlist y encontramos que una consulta MDL-15748 y realizamos el cambio en el archivo accesslib.php; la plataforma quedo con una excelente velocidad.
despúes, la plataforma comenzó a ponerse lenta en diferentes puntos del día y varias veces, se realizó nuevamente monitoreo del servidor con el comando TOP y se encontró que el proceso de Mysql llegaban incluso al 320% y con la memoria ram ocupada con sólo 1.5GB.
luego se procedió en búsqueda de foros con iguales inconvenientes y se encontró el de Martha Vanessa, revisamos la configuración que ella tiene del Mysql y lo comparamos con el de nosotros y encontramos varias inconsistencias absurdas en la configuración que poseemos.
old_passwords=1
max_connections=8000
max_allowed_packet=8M
thread_cache_size=7800
key_buffer=256M
table_cache=512
sort_buffer_size=256M
read_buffer_size=256M
read_rnd_buffer_size=8M
thread_concurrency=8
innodb_file_per_table = 1
innodb_data_home_dir = /ibdata
innodb_data_file_path = "ibdata1:10M:autoextend"
innodb_autoextend_increment = 8
innodb_open_files=2048
innodb_buffer_pool_size=256M
innodb_additional_mem_pool_size=20M
open_files_limit = 32768
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_max_dirty_pages_pct = 90
innodb_flush_log_at_trx_commit=1
Si alguien podria asesorarme sobre estas variables con respecto a los 15000 usuarios le agradecería muchisimo y que cambios debo realizar en la configuración del Mysql, apache, php y el servidor.
bueno en fin, ahora últimamente estamos presentando lo mismo pero con la memoria casi ocupada en su totalidad.
En respuesta a Camilo Nieto
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Xavier Paz -
Por la periodicidad de los sucesos (varias veces al día) y la carga de la base de datos, parece que puede ser problema de las estadísticas.
El procesado y recolección de estadísticas es un proceso de mucha carga para la base de datos, y en versiones inferiores a 1.9.2 dentro de la serie 1.9 de Moodle, tiene un bug que hace que la consulta vaya muuuy lenta y no respete la periodicidad impuesta en la configuración de la plataforma.
Buscando y buscando, la única recomendacion que encontré fue actualizar a la versión 1.9.4, en la cual estos errores están supuestamente subsanados. La otra opción es desacctivar la recolección de estadísticas, y ejecutar dicha tarea manualmente cada cierto tiempo, en fechas donde haya menos actividad.
Mi recomendación es actualizar si es posible, y sino desactivar estadísticas.
P.D: una buena herramienta para monitorizar una base de datos MySQL es mytop (muy parecido a top) y para monotorizar el servidor nmon y nmon_analyzer con estadísticas en excel son muy buena opción.
El procesado y recolección de estadísticas es un proceso de mucha carga para la base de datos, y en versiones inferiores a 1.9.2 dentro de la serie 1.9 de Moodle, tiene un bug que hace que la consulta vaya muuuy lenta y no respete la periodicidad impuesta en la configuración de la plataforma.
Buscando y buscando, la única recomendacion que encontré fue actualizar a la versión 1.9.4, en la cual estos errores están supuestamente subsanados. La otra opción es desacctivar la recolección de estadísticas, y ejecutar dicha tarea manualmente cada cierto tiempo, en fechas donde haya menos actividad.
Mi recomendación es actualizar si es posible, y sino desactivar estadísticas.
P.D: una buena herramienta para monitorizar una base de datos MySQL es mytop (muy parecido a top) y para monotorizar el servidor nmon y nmon_analyzer con estadísticas en excel son muy buena opción.
En respuesta a Camilo Nieto
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Camilo Nieto -
Hola a todos,
Les escribo nuevamente a todos y mil disculpas por no responder antes pero me encontraba en el proceso de monitorización de la plataforma y les tengo buenas noticias en la institución se logró estabilizar la plataforma, resulta que teníamos inconvenientes con la configuración del Mysql por que los datos que se encontraban en la configuración eran desproporcionado como lo comenté anteriormente, datos anteriores de la configuración del Mysql:
old_passwords=1
max_connections=8000
max_allowed_packet=8M
thread_cache_size=7800
key_buffer=256M
table_cache=512
sort_buffer_size=256M
read_buffer_size=256M
read_rnd_buffer_size=8M
thread_concurrency=8
innodb_file_per_table = 1
innodb_data_home_dir = /ibdata
innodb_data_file_path = "ibdata1:10M:autoextend"
innodb_autoextend_increment = 8
innodb_open_files=2048
innodb_buffer_pool_size=256M
innodb_additional_mem_pool_size=20M
open_files_limit = 32768
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_max_dirty_pages_pct = 90
innodb_flush_log_at_trx_commit=1
datos actuales:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-innodb
skip-locking
old_passwords=1
max_connections=400
max_allowed_packet=8M
thread_cache_size=8
key_buffer=1024M
table_cache=4000
sort_buffer_size=2M
read_buffer_size=2M
read_rnd_buffer_size=8M
thread_concurrency=8
wait_timeout=15
query_cache_type=1
query_cache_limit=1M
query_cache_size=100M
log_error=/var/log/mysql/error.log
long_query_time=3
log_slow_queries=/var/log/mysql/slow_queries.log
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql.server]
user=mysql
basedir=/var/lib
nuestro servidor tiene: 2 procesadores doble nucleo Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, ram 8 GB, Servidor Virtualizado Linux Red Had 5.2 Enterprice, 15000 usuarios registrados y hemos alcanzado las 300 conexiones concurrentes.
Les escribo nuevamente a todos y mil disculpas por no responder antes pero me encontraba en el proceso de monitorización de la plataforma y les tengo buenas noticias en la institución se logró estabilizar la plataforma, resulta que teníamos inconvenientes con la configuración del Mysql por que los datos que se encontraban en la configuración eran desproporcionado como lo comenté anteriormente, datos anteriores de la configuración del Mysql:
old_passwords=1
max_connections=8000
max_allowed_packet=8M
thread_cache_size=7800
key_buffer=256M
table_cache=512
sort_buffer_size=256M
read_buffer_size=256M
read_rnd_buffer_size=8M
thread_concurrency=8
innodb_file_per_table = 1
innodb_data_home_dir = /ibdata
innodb_data_file_path = "ibdata1:10M:autoextend"
innodb_autoextend_increment = 8
innodb_open_files=2048
innodb_buffer_pool_size=256M
innodb_additional_mem_pool_size=20M
open_files_limit = 32768
innodb_log_file_size = 64M
innodb_log_buffer_size = 8M
innodb_max_dirty_pages_pct = 90
innodb_flush_log_at_trx_commit=1
datos actuales:
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
skip-innodb
skip-locking
old_passwords=1
max_connections=400
max_allowed_packet=8M
thread_cache_size=8
key_buffer=1024M
table_cache=4000
sort_buffer_size=2M
read_buffer_size=2M
read_rnd_buffer_size=8M
thread_concurrency=8
wait_timeout=15
query_cache_type=1
query_cache_limit=1M
query_cache_size=100M
log_error=/var/log/mysql/error.log
long_query_time=3
log_slow_queries=/var/log/mysql/slow_queries.log
[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid
[mysql.server]
user=mysql
basedir=/var/lib
nuestro servidor tiene: 2 procesadores doble nucleo Intel(R) Xeon(R) CPU E5450 @ 3.00GHz, ram 8 GB, Servidor Virtualizado Linux Red Had 5.2 Enterprice, 15000 usuarios registrados y hemos alcanzado las 300 conexiones concurrentes.
En respuesta a Camilo Nieto
Re: Como mejorar el rendimiento de Moodle (30000 usuarios)
de Miguel Lara -
Hola, Camilo, en la nueva configuración eliminaste las líneas de Innodb? Estoy con muchos problemas para que el chat funcione. Y no logro jugar bien entre la configuración de Apache y Mysql para que funcione. Gracias!