¿Cómo soluciono el lag de mi servidor FiveM y el aviso 'server thread hitch warning'?

¿Ves constantemente server thread hitch warning: timer interval of XXX milliseconds en la consola de tu servidor FiveM mientras los jugadores se quejan de lag o rubber banding? Significa que el hilo del servidor no da abasto. Aquí te explicamos qué significa el aviso, cómo localizar los recursos pesados con resmon y cómo solucionar los cuatro culpables más habituales.

¿Qué significa 'server thread hitch warning'?

FXServer ejecuta el núcleo de tu servidor — la sincronización de jugadores, los eventos y la mayor parte de la lógica de tus scripts — en un único hilo principal (svMain). Ese hilo trabaja en ticks cortos. Cuando un tick tarda mucho más de lo previsto, por ejemplo 250 milisegundos en lugar de unos pocos, el servidor registra una hitch warning con el tiempo medido. Durante uno de estos tirones todo se detiene a la vez: los jugadores vuelven de golpe a su posición anterior, los vehículos se congelan y los eventos llegan tarde.

Como todo este trabajo ocurre en un solo hilo, lo decisivo es la velocidad single-thread de la CPU — no el número de núcleos ni la cantidad de RAM. En la práctica, sin embargo, la causa no suele ser una máquina lenta, sino un recurso que acapara el hilo. Este artículo trata específicamente de FiveM; el lag en un servidor de Minecraft funciona de forma muy distinta y tiene su propio artículo de optimización.

Paso 1: localiza los recursos pesados con resmon

1. Conéctate a tu servidor, abre la consola del cliente con F8 y escribe resmon 1. Aparecerá la ventana del monitor de recursos.
2. Fíjate en la columna CPU msec: indica cuántos milisegundos cuesta un recurso por frame. Deja la ventana abierta un rato mientras juegas.
3. Interpreta los valores: un recurso bien hecho se mantiene por debajo de 0,10 ms. Un script que supera de forma constante 1,00 ms es pesado; picos de varios milisegundos señalan directamente al culpable.
4. Resmon mide tu cliente. Para perfilar el propio hilo del servidor, usa la pestaña Console del panel de MC-Node: escribe profiler record 500, espera a que termine la grabación y escribe profiler view. El enlace que aparece muestra, recurso por recurso, qué funciones retrasan el tick; en txAdmin las gráficas del dashboard también muestran los tiempos de tick.
5. ¿No hay ningún pico claro? Detén temporalmente los recursos sospechosos con stop nombredelrecurso en la consola y comprueba si desaparecen los warnings. Descartando la mitad cada vez encontrarás al culpable incluso sin profiler.

Paso 2: soluciona los cuatro culpables más habituales

1. Scripts con bucles demasiado ajustados — Un bucle como while true do ... Citizen.Wait(0) end se ejecuta en cada tick, incluso cuando no hay nada que hacer. Sube el tiempo de espera, por ejemplo a Citizen.Wait(1000), para comprobaciones que no necesitan ejecutarse continuamente, y haz que el código reaccione a eventos en lugar de hacer polling. Si un script cifrado (escrow) o abandonado sigue siendo pesado, sustituirlo por una alternativa mantenida es casi siempre la mejor opción.
2. Texturas de vehículos demasiado grandes (YTD) — Los coches addon con texturas 4K u 8K devoran la memoria de streaming: los jugadores sufren tirones, texture loss y descargas largas. Reduce las texturas a 2K como máximo, elimina variantes de livery sin usar y sé crítico con packs de cientos de megabytes. Cómo instalar vehículos de forma ligera y ordenada lo tienes en la guía de coches addon.
3. Consultas de base de datos bloqueantes — Una consulta síncrona paraliza el hilo del servidor hasta que la base de datos responde. Usa un wrapper asíncrono actualizado como oxmysql, sustituye los scripts antiguos de mysql-async y añade índices a las tablas más usadas, como users y owned_vehicles. Guarda los datos de los jugadores por lotes en lugar de con cada pequeño cambio. Encontrarás las credenciales de tu base de datos en la pestaña Databases.
4. Demasiadas entidades — Cada vehículo, prop y ped spawneado debe sincronizarse en cada tick; miles de vehículos abandonados lo encarecen notablemente. Ejecuta un script de limpieza que elimine los vehículos vacíos a los pocos minutos, limita los scripts de spawn y vigila los mapas que colocan muchísimos props — consulta también la guía de MLO y mapas custom.

¿Cuándo es el hardware realmente el cuello de botella?

La trampa clásica es echarle la culpa de todo al host mientras un solo script se come el 90% del tiempo de frame — el profiler lo deja en evidencia sin piedad. Pero también existe lo contrario. ¿Resmon está limpio, el profiler reparte el tiempo de tick de forma uniforme entre muchas tareas pequeñas sin picos claros y los warnings solo aparecen con muchos jugadores? Entonces estás tocando el límite single-thread de la CPU. Más RAM o más slots no lo solucionan; solo ayuda hardware con mayor frecuencia por núcleo.

Mensajes y situaciones frecuentes

• Hitch warnings durante el arranque — Al (re)iniciar, el servidor carga todos los recursos a la vez; unos cuantos warnings son normales. Solo son un problema los mensajes que siguen apareciendo durante la partida.
• sync thread hitch warning o network thread hitch warning — Estas variantes suelen apuntar a la capa de sincronización: demasiadas entidades o jugadores. Limpia entidades (paso 2, punto 4) y comprueba que OneSync Infinity está activado.
• Tirones a horas fijas — Si el tirón vuelve exactamente cada cinco o diez minutos, casi siempre es culpa de una tarea periódica: un bucle de guardado que escribe todos los jugadores a la vez o un backup en horas punta. Reparte el guardado en tus scripts y programa los backups por la noche desde las pestañas Schedules y Backups.
• Rubber banding sin hitch warnings en la consola — Entonces el problema está probablemente en el lado del cliente o en la red del jugador. Pide a los jugadores afectados que comprueben sus propios fps y resmon; unos YTD demasiado pesados suelen ser la causa.
• Los warnings persisten tras todos los pasos — Haz una grabación del profiler con profiler record 500 justo después de un tirón y guarda el resultado; así la causa se localiza mucho más rápido.

¿Necesitas ayuda?

Con resmon y el profiler encontrarás casi cualquier causa de lag del servidor en pocos minutos. Si no lo consigues, abre un ticket a través de nuestra página de soporte e incluye el mensaje exacto de la pestaña Console junto con tus datos de resmon o del profiler.