inconsistencia en VICIdial

[lalo2do]

Buen día

Espero que me puedan ayudar, tengo un Cluster Vicidial con la versión 3.1.14 64 bits estructurado de la
siguiente manera:


1 servidor de base de datos:
24 procesadores Intel(R) Xeon(R) CPU E5-2620 0 @ 2.00GHz
16 GB de RAM
1 TB en disco duro


Telefonia 1

4 procesadores Intel(R)Xeon(R)CPU E5502@ 1.87GHz
20 gb en RAM
140 GB en Disco duro

Telefonia 2
4 procesadores Intel(R) Xeon(R) CPU E5503@ 2.00GHz
16 GB en RAM
140 GB en disco duro

Telefonia 3
8 procesadores Intel(R) Xeon(R) CPU X3440@ 2.53GHz
8 GB en RAM
500 GB

Telefonia 4
8 procesadores Intel(R) Xeon(R) CPU E5506@ 2.13GHz
16 gb de RAM
500 gb de disco duro

Telefonia 5
4 procesadores Intel(R) Xeon(R) CPU E5502@ 1.87GHz
24 GB de RAM
300 gb de en disco duro

Telefonia 6
4 procesadores Intel(R) Xeon(R) CPU E5-24030@ 1.80GHz
14 gb RAM
500 gb en disco duro

1 Servidor web
12 procesadores Intel(R) Xeon(R) CPU E5-24200@ 1.90GHz
14 gb RAM
1 TB en Disco Duro


Con esto pensábamos que el sistema podría soportar unos 250 agentes (o mas) el problemas es que cuando llegamos a 200 agentes firmados en el sistema
empieza a tener problemas:

- los saca del sistema y los manda a una pantalla que dice click here for login again
- el softphone se cuelga
- la web tarda en desplegarce
- se cruzan las llamadas
- El Realtime muestra muchos agentes en dead cuando en realidad estan en llamada
- El Realtime ya no refresca en el tiempo establecido
- los pausa automaticamente
- tiene un desface cuando el agente ya tiene al cliente en la pantalla con los datos tarda en desplegarse
- no deja colgar llamadas para disponer una segunda.

ya realice varias cosas:

- al servidor WEB le actualice el eAccelerator a la ultima versión con eso bajo el procesamiento en el server
- en el servidor de base de datos

modificamos el archivo my.cnf y tiene los siguientes parámetros:


[client]
port = 3306
socket = /var/run/mysql/mysql.sock

[mysqld]
port = 3306
socket = /var/run/mysql/mysql.sock
datadir = /var/lib/mysql
skip-locking
skip-log-warnings
key_buffer_size = 1G
max_allowed_packet = 16M
table_open_cache = 5120
sort_buffer_size = 2M
read_buffer_size = 1M
net_buffer_length = 8K
read_rnd_buffer_size = 64M
myisam_sort_buffer_size = 128M
thread_cache_size = 16
query_cache_size = 128M
thread_concurrency = 24
skip-name-resolve
connect_timeout=120
long_query_time = 3
log_slow_queries
max_connections=1000
open_files_limit=5120
max_heap_table_size = 256M
concurrent_insert=2
expire_logs_days=3
skip-innodb
read-only = 0
low_priority_updates=1

log-bin=mysql-bin

binlog_format=mixed
binlog-do-db = asterisk
slave-skip-errors = 1062,1032

server-id = 1

log-bin=mysql-bin
replicate-do-db = asterisk
[safe_mysqld]
log-error = /var/log/mysql/mysqld.log
socket = /var/run/mysql/mysql.sock

[mysqldump]
socket = /var/run/mysql/mysql.sock
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash

[myisamchk]
key_buffer_size = 20M
sort_buffer_size = 20M
read_buffer = 2M
write_buffer = 2M

[mysqlhotcopy]
interactive-timeout

[mysqld_multi]
mysqld = /usr/bin/mysqld_safe
mysqladmin = /usr/bin/mysqladmin
log = /var/log/mysqld_multi.log


realice el siguiente update:

mysql -f asterisk < /usr/src/astguiclient/trunk/extras/upgrade_2.4.sql


y también estos alter table:

ALTER TABLE vicidial_live_agents MODIFY closer_campaigns VARCHAR(8000) default '';
ALTER TABLE vicidial_live_agents MODIFY external_ingroups VARCHAR(8000) default '';
ALTER TABLE vicidial_live_agents MODIFY agent_territories VARCHAR(1000) default '';
ALTER TABLE vicidial_live_agents ENGINE=MEMORY;
ALTER TABLE vicidial_manager ENGINE=MEMORY;


también corrí un mantenimiento con autorepair y optimize a la base de datos

sin embargo aun no consigo que el sistema trabaje con mas de 170 agentes, alguna idea, recomendación, observaciones!!!



Saludos

[Christian Cabrera]

Creo que tu sistema está mal propuesto.

1. MySQL se beneficia de muchos cores y mucha RAM, además de que los discos deben ser r a p i d o s. Si tienes 1TB de disco (innecesario para una BD), eso me hace pensar que son discos grandes y lentos. Para tu aplicación, yo usaría 2 discos SAS 15K de 300GB con RAID 1 o, si te sobran los recursos, RAID 1+0. 24 GB de RAM (o si se puede 32). Yo intentaria cambiarle los discos al BD ya que creo que por ahí va el problema.

2. Asterisk no aprovecha los cores extras, pero si la memoria, y el espacio en disco solo es importante si piensas dejar ahi las grabaciones (que tampoco quizá sea buena idea dejarlas regadas entodos los servidores). Si usas tarjetas Sangoma, recuerda configurar correctamente el chunk size para mejorar el rendimiento.

Es muy probable que estos servidores estén sub-utilizados en el tema de procesamiento, ya que solo tienes 200 agentes. Yo le cargaría a cada uno unos 30 agentes web, además de los telefónicos.


3. Un solo servidor web para 200 agentes es muy, muy poco. No le cuelgues más de 100 o tendrás problemas. Lo mejor que puedes hacer es dividir parte del tráfico web hacia los de telefonía.


4. Los cambios de ALTER TABLE que mencionas no creo que te beneficien, pues estás haciendo las tablas más grandes y por lo tanto, más lentas de consultar.

5. Si haces la parte web, asegúrate de tener el Apache optimizado en todos los equipos que lo usen.

6. Que tus supervisores ejecuten los reportes en un esclavo de MySQL (probablemente sea buena idea usar el servidor de web para esto).


No tengo instalaciones de 200 agentes, pero tengo de 100-120 utilizando un único servidor. Yo por 200 agentes, con 3 servidores sería más que suficiente, así que tienes que poder lograrlo con el hardware actual, solo hay que planearlo correctamente.

[Christian Cabrera]

Otro detalle:

Estoy encontrando varios posts que indican que hay problemas en Vicidial con MySQL 5.5, el cual es muy probable que tengas. Recomiendan que se haga un downgrade a la 5.1, quizá eso puede resolver tu problema. Los pasos para hacerlo los puedes encontrar en http://www.vicidial.org/VICIDIALforu...e+mysql#p94673

Otro posible beneficio: MariaDB es un reemplazo completo para MySQL, y se supone que tiene mejor rendimiento. Yo acabo de empezar a probarlo, y este foro a partir de este momento está usando MariaDB, la cual reemplazó por completo a MySQL y no he tenido problemas. Esa es quizá otro punto que quieras probar, aunque este es más severo porque en caso de tener problemas, te obliga a parar toda la operación. Con el downgrade, si reimportas correctamente toda la BD, garantizas que va a funcionar correctamente al día siguiente.

Suerte,