Hola,
Si se me permite colaborarte, al igual que los compañeros han expuesto hay varios factores conforme la población crece a tomar en cuenta para “tunear” el emulador y poder llegar a un rendimiento decente sin sacrificar otros aspectos o gastar demasiado dinero en un mounstro de máquina.
Complementando un poco el tema de DB:
[ul][li]Te recomiendo primero si estas en debian utlilzar un motor de base de datos llamado XtraDB, basicamente es un InnoDB pero tuneado, y la empresa que lo distribuye es PERCONA, este software es de distribución libre y es como un mysql tuneado, el apt-get hace todo, basta con saber instalarla, que no es tan dificil y estás del otro lado, este motor de base de datos le da MUCHISIMA y cuando digo muchisima es muchisisisisima mas velocidad y calidad al momento de trabajar con volúmentes de datos altos. Para ponerte un par de datos reales, con 780 pj mysql no abastece por mas hilos y parámetros que le tunees, es mas, hay parámetros que el mysql no acepta al menos para emuladores, con xtradb a cerca de 1200 pj recién te pide tunearlo, con la config original te aguanta tranquilamente los 900-1200 pj dependiendo de si es un SSD y la cantidad de núcleos de la máquina.[/li][/ul]
[ul][li]Sobre lo que son hilos y parámetros, hay dos que tres parámetros en las configs de mysql que podrías ponerle atención, principalmente hay que poner un pool de InnoDB y MyISAM al menos 2x mas grande que el tamaño de la db, porque cuando empieza a llegar al borde, pagína, y eso amigo mío es malo ya que las distros base de OVH traen un swap de 1.3GB como tope, lo que no te conviene, te dará muchos mas problemas. Asi que empieza por ahi, cuando digo pool son 5 cosas: innodb_buffer_pool_size, join_buffer_size, ( tiene estrecha relación con sort_buffer_size, read_buffer_size, read_rnd_buffer_size pero el más pesado en tc es el join)[/li][/ul]
[ul][li]Sobre tuneo extremo, hay 3 parámetros que quiero dejar aquí escritos para que lean y puedan llevar el tuning de la db a otro nivel, porque pasados los 1500pj la cosa se pone fea, y hay que meterle mucha caña a la db, los parámetros son: innodb_flush_method, innodb_table_locks, innodb_flush_log_at_trx_commit, y los 3 que más me gustan a mi: innodb_io_capacity, transaction-isolation, innodb_adaptive_checkpoint[/li][/ul]
Complementos en tema configuracion emu:
[ul][li]Sobre manejo de hilos para conexiones sincronicas/asincronicas, trata de llegar a poner la siguiente cantidad de hilos como tope en las configs, esto lamentablemente no está en la wiki y no se encuentra fácilmente en los foros de Trinitycore, pero si, lo explicó Machiavelli en su día y también hay logs de IRC regados por la internet que lo explican muy bien, aquí los datos: pon el workerthreads a un máximo de 2xN threads posibles, si tu nucleo aguanta 4 hilos por nucleo (en teoría, ahora parece ser que funciona hilos totales soportados) tu límiete de workerthreads será 8, para characers, world y auth, pero si estás en la misma máquina las 3 dbs, trata de distribuirlo entre los 3 los 8 hilos posibles asi por ejemplo: login = 1 characters = 6 world = 1, normalmente char es la que más transacciones demanda, ponle mucho ojo a eso.[/li][/ul]
[ul][li]Sobre manejo hilos por mapa, casi relativo a lo comentado arriba es que la cantidad de hilos max para el map.threading ha de ser hasta el tope hasta un 20% más, pero no mas de ahí ya que el core no hace buen handling de ello (recordemos que el nucleo usa 1 solo procesador físico en linux), y si metes mas de 4-5 hilos en este caso para los mapas, empezarás a tener comportamiento Y CRASHES no deseados y no válidos como backtrace para los issues de trinitycore. Con 3 hilos es más que suficiente para 500pj, si el worldserver empieza a comerte demasiado micro, bájale, pero tomando en cuenta esto último que te digo.[/li][/ul]
[ul][li]Sobre configs de worldserver, mas que nada los sistemas de consumo y transaccion de base de datos son los que más lento hacen el emu, a menos que tengas bucles en código y ahí si tu diff se dispara y el server no se cae hasta que freezea básicamente, hay que ponerle especial atención a los parámetros de worldserver que usan la db muy seguido, como es el save de pjs, normalmente con ponerlo a 15mins el rollback es aceptable, también como truco adicional yo te recomendaría retocar 4 cosas: wheater (no lo necesitas y si, consume mas de lo debido comprobado), DetectPosCollision desactivalo, eso carga y da lag, si disminuye la calidad pero no es grande la diferencia en jugabilidad en sí, o ponla a 5y para que no estime mucho el calculo, normalmente ese viene puesto en 1.5y, MaxOverspeedPings a 2, ya que no necesitas gente logueada AFK mas de 5-10mins en el server, eso da carga innecesaria en el mismo, me explico, este parámetro permite el check de tiempos que haces con otros parametros de si cuando un pj pasa mas de X tiempo afk, cuantas veces afk en tiempo está para kickearlo automaticamente, eso son pool de conexiones para otros jugadores activos que lo necesitan y se traduce en menos lag general en el reino, ese yo lo tengo en 2 y por último el más importante GridUnload, ese tiene que estar en 0, fijo, cuando tu población crece, los mapas (cargados) en la ram, se vuelven de uso muy frecuente asi que tenerlos pre-cargados en la misma le da una ventaja especial, aparte de que haces que el núcleo (la mayoria de codigo de grids, cells, y visitors) no sobrecargue al sistema y evitas crashes, esta ultima parte estoy seguro te va a interesar.[/li][/ul]
Eso como unos pocos consejos que te puedo dar ahora mismo, que tengo el tiempo encima xD, este temilla me está animando a postear una guía completa de consejos útiles y “trucos” o tips, para tunear un server a un buen nivel, claro con su parte estética bien montada y tal, basado en lo que es mi experiencia en dedicados y emuladores, que me ha servido y creo nos viene bien a todos desde que esto está hecho para aprender y compartir conocimiento.
Espero os haya ayudado ^^
Saludos
Eilo