Rendimiento y lagUn plugin que registra cada bloque roto, cada entrada, cada transacción de economía está escribiendo sin parar. Apúntalo a un archivo .db en vez de a un servidor de base de datos de verdad, y cada una de esas escrituras puede acabar haciendo cola detrás del hilo principal, que es una forma bastante rebuscada de perder TPS por una función que nadie llamaría crítica para el rendimiento.
El mecanismo
SQLite no es un servidor: es una librería que lee y escribe un archivo plano directamente, sin ningún proceso aparte gestionando el acceso. Para mantener ese archivo consistente, el modo por defecto de SQLite permite un escritor a la vez: mientras hay una escritura en marcha, cualquier otra conexión que quiera escribir tiene que esperar a que termine, y por defecto incluso los lectores se pueden quedar esperando.
Un plugin que registra cambios de bloques, chat o transacciones de economía escribe sin parar, y cada una de esas escrituras tiene que conseguir ese bloqueo del archivo. Si las llamadas a la base de datos del plugin pasan por el hilo principal en vez de por uno en segundo plano, esa espera se convierte en una espera que hace el juego entero: cada jugador, cada entidad, congelados durante lo que dure una escritura a disco.
SQLite frente a un servidor MySQL
SQLite (archivo .db) | MySQL | |
|---|---|---|
| Qué es | Una librería enlazada dentro del plugin, escribiendo directo a un archivo | Un proceso de servidor aparte, al que se accede por una conexión |
| Escrituras concurrentes | Una a la vez, bloqueada por archivo | Muchas, con bloqueo a nivel de fila en InnoDB |
| Dónde se produce la espera | El hilo que lanzó la escritura, muchas veces el principal | La propia conexión del plugin, que un plugin bien hecho mantiene fuera del hilo principal |
| Bien para | Una herramienta de un jugador, un servidor personal de poco tráfico | Cualquier plugin que registre más que algún evento ocasional |
Muchos plugins que se comportan perfectamente con MySQL usan SQLite por defecto porque no necesita ninguna configuración, y el mismo plugin, con los mismos ajustes, en el mismo servidor, puede pasar de imperceptible a una caída de TPS visible en cuanto sube el volumen de escrituras, sin que haya cambiado nada en el propio código del plugin. El motor de base de datos es la variable, no la calidad del plugin.
Sacar un plugin de SQLite
- Mira si la configuración del plugin tiene una sección de almacenamiento o base de datos
Casi todos los plugins capaces de usar MySQL exponen campos de host, puerto, nombre de base, usuario y contraseña, normalmente comentados o puestos en SQLite por defecto.
- Apúntalo a la base de datos MySQL que incluye tu plan
Crea una desde la pestaña de Bases de datos si no tienes, y usa la dirección local que se muestra ahí en vez de una IP pública.
- Reinicia una vez, y confirma en el propio registro de arranque del plugin
Casi todos imprimen una línea confirmando a qué motor se conectaron. Esa línea es la prueba de que el cambio se aplicó, no solo que cambió el archivo de configuración.
El registro del plugin confirma una conexión MySQL, y el TPS se mantiene estable durante la actividad que antes causaba la caída: romper bloques en masa, una tienda con movimiento, una ola de entradas.