Rendimiento y lagTu plan puede mostrar tres núcleos y una gráfica del panel parada en el treinta por ciento, y el juego puede seguir dando tirones igual. No es una contradicción. Es lo que pasa cuando el trabajo que importa está confinado a exactamente uno de esos núcleos, y la gráfica solo te está contando el promedio.
Por qué el tick del mundo no se puede repartir sin más entre núcleos
Cada tick, el servidor tiene que responder cosas como: ¿le dio esta flecha a ese jugador?, ¿en qué orden dispararon estos dos pistones?, ¿esta actualización de redstone pasa antes o después de aquella otra? Esas respuestas dependen de una vista única y consistente del mundo en ese instante: dos hilos actualizando el mismo chunk a la vez darían resultados que dependerían del momento exacto en vez de las reglas del juego, que es la definición de un fallo que los jugadores acabarían notando como objetos duplicándose o cayendo a través de bloques que un momento antes estaban ahí.
Hacer multihilo seguro sobre un mundo compartido en constante cambio es uno de los problemas más difíciles del diseño de motores, y Mojang no lo ha resuelto para el bucle central del juego: entidades, física y redstone siguen haciendo tick en un solo hilo. Ese hilo es lo que mide un informe de /spark profiler cuando señala «el hilo principal», y es el recurso que cualquier otro ajuste de tu servidor intenta proteger, en el fondo.
Leer bien el número de CPU del panel
| El panel muestra | El plan tiene | Qué significa de verdad |
|---|---|---|
| 33% | 3 vCores | Un núcleo está completamente saturado. Los otros dos están casi parados. |
| 100% | 3 vCores | O todos los núcleos están ocupados —generación de chunks, hilos de plugins— o se está reportando la lectura de un solo núcleo como si fuera la asignación entera. |
| 12% | 8 vCores | Un núcleo saturado de ocho. El servidor puede estar en su límite absoluto mientras este número parece tranquilo. |
Un plan con más vCores le da al trabajo asíncrono —generación de chunks, algunos guardados del mundo, tareas de plugins en segundo plano— más margen para correr sin competir con el hilo principal. No le da al propio hilo principal más velocidad, porque solo hay uno y no se puede dividir. Si el cuello de botella es el tiempo de tick, el número que importa es la velocidad de reloj de un solo núcleo y lo poco que le pidas a ese único hilo, no el número de núcleos.
Qué sí sube el techo de verdad
- Saca un informe de
/spark profilerdurante el lag, no despuésMuestra exactamente qué plugin, qué tipo de entidad o qué zona del mundo se está comiendo el tiempo del hilo principal. Adivinarlo solo con la gráfica del panel no puede hacer esto.
- Recorta lo que nombre el perfilador
Menos entidades en la zona caliente, un plugin sustituido, una distancia de visión o de simulación más pequeña: lo que señale el informe específicamente.
- Pásate a software de la familia Paper si aún no lo has hecho
Saca trabajo real —carga de chunks, algo de iluminación y pathfinding— del hilo principal dentro de lo que permite el comportamiento vanilla, que es la palanca más grande disponible antes de tocar cualquier otra cosa.
Diez milisegundos de código de plugin mal escrito corriendo cada tick son una quinta parte de todo el presupuesto de 50 milisegundos que tiene el servidor para terminar un tick, da igual cuántos núcleos o cuánta memoria estén sin usar. Un cuello de botella de un solo hilo no tiene ninguna forma de pedir prestado de ningún otro sitio.