Servidor FiveM de 128 slots : configuración y optimización para grandes comunidades

El límite de FiveM 128 slots no es un simple número que se escribe al azar en un archivo de configuración: depende directamente de sv_maxclients, de la arquitectura OneSync y de la capacidad real de cómputo disponible. Antes de abrir las puertas de tu comunidad a cien o más jugadores simultáneos conviene entender cómo interactúan estos tres elementos, porque un mal ajuste provoca caídas de tickrate, desincronización de entidades y quejas constantes en el chat.

Cómo funciona el límite de FiveM 128 slots

FiveM, el framework multijugador basado en GTA V, no soporta de forma nativa cantidades elevadas de jugadores sin una capa adicional de sincronización. El motor original de Rockstar fue pensado para sesiones pequeñas, por lo que llegar a FiveM 128 slots exige activar OneSync, un sistema que reescribe la forma en que el servidor gestiona entidades, vehículos y peds entre todos los clientes conectados.

Sin OneSync, el máximo recomendable ronda los 32 jugadores. Con OneSync activado en su modalidad estándar se pueden alcanzar cómodamente los 64 slots, y con OneSync Infinity (la versión completa) es posible escalar hasta 128, 200 o incluso más, siempre que el hardware acompañe. Para dimensionar correctamente la máquina donde corre tu instancia, puedes revisar las opciones de alojamiento servidor FiveM adaptadas a este tipo de carga.

Qué controla exactamente sv_maxclients

La variable sv_maxclients define el número máximo de conexiones aceptadas, pero no garantiza rendimiento por sí sola. Es un techo administrativo, no una promesa de estabilidad. Si se fija en 128 sin los requisitos de OneSync cumplidos, el servidor rechazará conexiones extra o sufrirá timeouts masivos en cuanto se acerque a esa cifra.

Configurar sv_maxclients y OneSync paso a paso

La configuración se realiza en el archivo server.cfg, accesible desde el panel Pterodactyl en la gestión de archivos del servidor FiveM. Los parámetros clave son los siguientes:

# server.cfg
sv_maxclients 128

set onesync on
set onesync_population true
set sv_enforceGameBuild 2802

# Recomendado para reducir desconexiones en alta ocupación
set sv_endpointprivacy true
set sv_scriptHookAllowed 0

Tras editar el archivo, reinicia el servidor desde la consola del panel para aplicar los cambios:

systemctl restart fivem
# o desde el panel Pterodactyl: botón "Reiniciar" en la pestaña de consola

Diferencias entre OneSync Legacy e Infinity

• OneSync Legacy: soporta hasta 64 jugadores, menor coste de CPU, recomendado para comunidades medianas.
• OneSync Infinity: necesario para superar los 64 slots, requiere más potencia de CPU por tick y una conexión estable entre todos los recursos del servidor.
• Population scripting: con onesync_population activado, el tráfico y los peds se distribuyen dinámicamente, evitando que un solo núcleo quede saturado.

Requisitos mínimos recomendados según el número de slots

Slots objetivo	OneSync	CPU recomendada	RAM orientativa
32	Opcional	4 núcleos alta frecuencia	4-6 GB
64	Legacy	6 núcleos alta frecuencia	8 GB
128	Infinity	8 núcleos o más, Ryzen alta frecuencia	12-16 GB

Para cargas cercanas a 128 slots, un procesador con reloj elevado por núcleo marca más diferencia que una cantidad bruta de hilos, porque FiveM depende en gran parte del rendimiento single-thread para el tick principal.

Optimización de recursos para servidores con muchos jugadores

Alcanzar FiveM 128 slots en el papel es sencillo; mantener un tickrate estable con esa cifra de jugadores conectados es otro desafío. La mayoría de las caídas de rendimiento no vienen del límite en sí, sino de los recursos (scripts, frameworks, mapas personalizados) mal optimizados.

Buenas prácticas en los recursos del servidor

• Revisa la consola con resmon en el cliente para identificar scripts que consumen más de 0.1 ms por frame.
• Evita bucles Citizen.Wait(0) innecesarios; sustitúyelos por intervalos más largos cuando no se requiere ejecución inmediata.
• Limita los eventos de red (TriggerServerEvent) en bucle; agrúpalos o reduce su frecuencia con muchos jugadores activos.
• Desactiva recursos de streaming de mapas que no se usan en todas las zonas para no saturar la memoria del cliente ni el ancho de banda del servidor.

Monitorización del tickrate

El comando de consola svstats o los paneles de rendimiento internos del framework (ESX, QBCore) permiten observar el tickrate en tiempo real. Un servidor saludable con 128 slots debería mantenerse por encima de 40-50 ticks por segundo bajo carga completa; por debajo de eso, los jugadores notarán rubber-banding y retrasos en las interacciones.

# Ejemplo de comprobación desde la consola del servidor
svstats
# Salida esperada aproximada:
# Server tickrate: 48 (target 50)
# Connected clients: 118/128

Red y anti-DDoS

Con 128 jugadores simultáneos, el volumen de tráfico UDP aumenta considerablemente y un servidor se convierte en un objetivo más visible. Disponer de protección anti-DDoS activa a nivel de infraestructura, combinada con un panel que permita revisar la consola en vivo y reiniciar rápidamente el proceso, reduce el tiempo de inactividad en caso de incidente. Compara también otras opciones en Todos nuestros servidores de juegos si gestionas varias comunidades a la vez con necesidades distintas de capacidad.

Administración, sauvegardas y mantenimiento con alta ocupación

Cuantos más jugadores soporta un servidor, más crítico es tener una rutina de mantenimiento sólida. Con 128 slots activos, cualquier corrupción de base de datos o fallo de script afecta a muchas más personas a la vez que en un servidor pequeño.

Rutina de copias de seguridad

Programa copias automáticas de la base de datos (MySQL/MariaDB si usas ESX o QBCore) y de la carpeta de recursos antes de cada actualización mayor. En el panel Pterodactyl, esto se gestiona desde la pestaña de copias programadas:

# Ejemplo de backup manual de base de datos vía SSH
mysqldump -u usuario -p nombre_basededatos > backup_$(date +%F).sql

Control de acceso y whitelist

Con una comunidad grande conviene reforzar el control de acceso: contraseñas RCON robustas, whitelist activa para roles sensibles y revisión periódica de sub-usuarios con permisos sobre la consola. Esto limita el riesgo de que un error humano afecte a los 128 slots a la vez.

• Cambia la contraseña RCON por defecto y evita reutilizarla en otros proyectos.
• Mantén actualizado el build de FiveM y los recursos de terceros, especialmente tras parches de seguridad.
• Audita los logs del servidor regularmente para detectar comportamientos anómalos antes de que escalen.

Si gestionas el framework desde tu propia instancia en lugar de un panel administrado, revisa las opciones de VPS Pterodactyl para tener control total sobre la configuración de red y los recursos asignados. Y si tu comunidad combina roleplay a caballo con escenarios modernos, el mismo razonamiento de slots y OneSync aplica también a Servidor RedM.

Errores comunes al escalar hasta 128 slots

La mayoría de los problemas reportados por administradores que intentan llegar a FiveM 128 slots se repiten de proyecto en proyecto. Conocerlos de antemano ahorra horas de depuración.

Lista de errores frecuentes

1. OneSync mal configurado: activar sv_maxclients 128 sin onesync on provoca desconexiones aleatorias por encima de 32-48 jugadores.
2. Scripts no pensados para alta concurrencia: variables globales compartidas entre jugadores sin control de colisión generan datos corruptos en la base de datos.
3. Falta de límite de recursos por jugador: inventarios, vehículos o propiedades sin paginación sobrecargan la consulta a la base de datos cuando hay cientos de registros simultáneos.
4. Ausencia de pruebas de carga: lanzar 128 slots en producción sin simular antes 60-80 conexiones reales es la causa más común de caídas el día del lanzamiento.

Antes de anunciar la apertura con el límite completo, organiza una sesión de pruebas con staff y jugadores de confianza para validar el tickrate real bajo carga.

Configurar correctamente FiveM 128 slots es cuestión de equilibrar sv_maxclients, OneSync Infinity y recursos bien optimizados, no solo de subir un número. Con una base de hardware adecuada, monitorización constante y buenas prácticas de mantenimiento, un servidor grande puede mantenerse estable incluso en horas punta.

FAQ

¿Puedo activar 128 slots sin OneSync Infinity?

No de forma estable. Sin OneSync Infinity el servidor empieza a rechazar conexiones o a desincronizar entidades mucho antes de llegar a 128 jugadores. Es un requisito técnico, no una opción.

¿Por qué mi servidor se vuelve lento al acercarse a 100 jugadores?

Suele deberse a scripts mal optimizados, bucles sin intervalos adecuados o consultas a base de datos sin límites. Usa resmon en el cliente y revisa el tickrate con svstats para localizar el recurso responsable antes de tocar la configuración de slots.

¿Qué diferencia hay entre sv_maxclients y el límite real de jugadores conectados?

sv_maxclients es el techo administrativo fijado en el archivo de configuración. El límite real depende de que OneSync esté correctamente activado y de que el hardware soporte el tickrate necesario bajo esa carga, por lo que ambos valores deben revisarse juntos.