RAM, tamaño de mapa y jugadores en servidor Rust

Un servidor Rust puede arrancar con 7 GB de RAM y acabar en 14 GB tras dos días de wipe sin cambiar de versión. El tamaño del mapa fija la base, los jugadores llenan esa base con bases, cofres, sleepers y entidades. El ajuste correcto se elige antes del wipe, porque reducir un mapa después casi siempre equivale a borrar el terreno.

Relacionar RAM, tamaño de mapa y jugadores antes del wipe

Rust carga un mapa completo desde el arranque. Después, los jugadores añaden lo que queda en el mundo: construcciones, cofres, hornos, trampas, vehículos y sleepers. Un mapa 4000 no es un 33 % más pesado que uno de 3000. Pasa de 9 km² a 16 km², es decir, un 78 % más de superficie. Esa superficie aporta más monumentos, más carreteras, más spawns de recursos y más entidades persistentes.

Ajuste primero server.worldsize. 3000 conviene a una comunidad pequeña de 20 a 40 jugadores conectados. 3500 va bien para 50 a 80 jugadores. 4000 se convierte en el formato habitual alrededor de 100 jugadores. Por encima de 4500, la superficie se paga en RAM y en guardados más pesados. Ajuste luego server.maxplayers. Este número no llena la memoria por sí solo, pero permite más bases, más cofres y más sleepers a lo largo del wipe.

Guarde un 25 a 30 % de margen de memoria después del arranque. Un servidor que arranca con 10,5 GB en una máquina de 12 GB ya empieza demasiado alto. Con un 85 % de RAM usada, el sistema deja poco margen para los picos de guardado. Con un 92 %, el swap o el mata-procesos OOM de Linux acaba entrando en escena. El mensaje "Out of memory: Killed process" suele aparecer en el peor momento, nunca cuando Discord está tranquilo.

Elegir un tamaño de mapa de Rust según su población

El buen tamaño de mapa no es el que más monumentos alinea. Es el que mantiene a los jugadores lo bastante cerca para cruzarse, sin amontonar 200 bases en el mismo cuadrado de 1 km². Un mapa demasiado grande consume más y da la impresión de servidor vacío. Un mapa demasiado pequeño convierte cada noche en un raid permanente, y luego las bajas llegan al cabo de 48 horas.

Estas cifras apuntan a un servidor vanilla o cercano a vanilla, con decay activo y sin 80 plugins de uMod. Un servidor x10 con stacks gigantes, kits, reciclaje modificado y loot acelerado genera más objetos y empuja a los jugadores a construir más grande. A igualdad de población, suele consumir entre un 20 y un 40 % más de memoria que un servidor vanilla después de una semana de wipe.

No elija 6000 para 60 jugadores. El mapa mide 36 km², cuatro veces uno de 3000. Los jugadores viajan más de lo que se encuentran, y la máquina mantiene en memoria una superficie que nadie usa realmente.

Dimensionar la RAM para 20, 50, 100 y 200 jugadores

La RAM mínima sirve para arrancar el servidor. La RAM útil absorbe el wipe, los guardados, los picos del sábado por la noche y los plugins. En Rust, el número de jugadores conectados pesa menos que lo que dejan detrás. 50 jugadores activos durante dos días construyen menos que una comunidad de 50 jugadores que se turna hasta 180 cuentas únicas.

Un margen de 4 GB parece amplio en un servidor pequeño. Sin embargo, evita los reinicios sucios cuando Unity carga una gran copia de seguridad, cuando Linux mantiene cache de disco, o cuando un plugin tiene una fuga durante seis horas. A partir de 100 jugadores, razonad en techo, no en media. Si vuestro servidor va a 11 GB por la tarde sobre 12 GB disponibles, el pico de las 21 h puede cortar la noche.

Los slots vacíos apenas consumen nada. Los sleepers, en cambio, siguen en la copia de seguridad. Un límite de 150 jugadores con 40 conectados puede seguir ligero el primer día, y volverse pesado el tercero si 300 cuentas únicas han construido y dormido en el mapa.

Probar la carga de Rust antes de anunciar los slots

Anunciad vuestros slots después de una prueba, no antes. Un servidor que arranca rápido en un mapa nuevo no demuestra nada. Verificad el arranque, la generación del mapa, los puertos, la copia de seguridad y la memoria después de al menos 30 minutos con vuestros plugins cargados.

1. Fijad el mapa y los puertos en el comando de arranque. El puerto de juego por defecto es 28015 en UDP. El RCON suele usar 28016 en TCP. Abrir solo 28015 deja el servidor visible, pero la administración remota falla.
2. Lanzad un mapa limpio con un tamaño realista. Para 80 jugadores, empezad por 3500 o 4000, no 5000. Un mundo grande oculta los problemas durante las primeras horas, y luego los muestra cuando aparecen las bases.
3. Mantened la misma seed durante las pruebas. Cambiar server.seed cambia los monumentos y la distribución de recursos, y por tanto la carga inicial.
4. Controlad la copia de seguridad con server.saveinterval a 300 segundos. Cinco minutos limitan la pérdida en caso de caída sin escribir en bucle en disco.

.\/RustDedicated -batchmode +server.port 28015 +rcon.port 28016 +server.worldsize 3500 +server.maxplayers 80

En el panel Starmine, cambiáis el tamaño del mapa, la seed, los slots y los puertos sin reescribir el comando de arranque en cada wipe. Los valores siguen visibles en el mismo sitio. Esto evita el clásico 4000 anunciado en Discord y 4500 realmente lanzado. Ver el panel.

Detectar las prestaciones de Rust que se degradan en juego

Los jugadores no ven primero una RAM llena. Ven puertas que abren con retraso, una recolección que va hacia atrás, disparos que impactan mal. Del lado del servidor, mirad tres umbrales juntos, memoria, FPS del servidor y duración de save. Un servidor Rust sano se mantiene cerca de 30 FPS del servidor. Por debajo de 20 FPS en hora punta, las acciones empiezan a desfasarse. Por debajo de 10 FPS, el combate se vuelve malo, incluso con un ping de jugador de 35 ms.

La duración de la copia de seguridad describe el estado real del mapa. Una save por debajo de 500 ms no se nota. Entre 1 y 2 segundos, los jugadores atentos a veces ven un micro freeze. Por encima de 3 segundos cada 300 segundos, el mapa tiene demasiadas entidades para la máquina o el disco va mal. Una base industrial con cintas transportadoras, torretas, cofres e iluminación cuesta tiempo de servidor. Multiplicadlo por 80 clanes y veréis a dónde van los milisegundos.

La memoria se vuelve peligrosa antes del 100 %. Al 85 %, vigilad. Al 90 %, planificad un reinicio limpio o reducid la carga. Al 95 %, esperáis un crash. En Linux, el registro puede contener "Out of memory: Killed process". No es un crash misterioso de Rust. Es el sistema el que elimina el proceso para seguir vivo.

tail -n 200 output_log.txt

Los plugins agravan estos umbrales cuando almacenan demasiados datos en JSON, escanean los contenedores demasiado a menudo o disparan timers cada segundo. Un plugin de estadísticas mal escrito puede costar más que pasar de 3500 a 4000.

Reducir un mapa de Rust demasiado grande después de un mal wipe

Reducir el tamaño del mapa, cambiar la seed o borrar la carpeta del mundo fuerza un nuevo mapa. Perdéis el terreno, las bases, los cofres, los vehículos, los sleepers y los monumentos generados. Los blueprints solo desaparecen si borráis también la base de datos de los jugadores.

Cuando una mapa de 5000 cae por debajo de 15 FPS del servidor con 90 jugadores, añadir 4 GB de RAM puede salvar una noche. Eso no arregla la causa. Pasar de 5000 a 4000 recorta la superficie de 25 km² a 16 km², es decir, un 36 % de terreno menos. La bajada de RAM varía según la seed, pero 4 a 8 GB de diferencia en un servidor cargado no tiene nada de anormal.

1. Anunciad un wipe de mapa. No prometáis mover las bases. Rust no sabe reducir correctamente un mundo manteniendo las construcciones en las nuevas coordenadas.
2. Copiad la carpeta vinculada a server.identity antes de cualquier manipulación. Conservad como mínimo la carpeta completa hasta el siguiente wipe. Una copia de seguridad de 2 a 8 GB se transfiere rápido, una comunidad perdida no vuelve rápido.
3. Conservad los blueprints si vuestro ritmo de wipe los mantiene. Borrar solo el mapa evita castigar a los jugadores dos veces.
4. Reiniciad con un tamaño más bajo y una seed probada. Para 70 jugadores, 3500 basta. Para 120 jugadores, 4000 sigue siendo el mejor compromiso. Para 200 jugadores, 4500 va mejor que 5000 si vuestra prioridad son el combate y los tiempos de guardado.

La mala idea es bajar los slots sin tocar el mapa. Limitáis las entradas, pero mantenéis la misma superficie, las mismas entidades y los mismos guardados. Si el problema viene de un mundo demasiado grande, los slots apenas liberan nada antes del siguiente wipe.

Guías

¿Bastan 16 GB de RAM para 100 jugadores en Rust?

Sí, con un mapa 4000 y un servidor vanilla o poco modificado, 16 GB deja un margen correcto. Si la RAM supera 14 GB antes del pico de la tarde, el mapa o los plugins ya son demasiado pesados para aguantar el wipe correctamente.

¿Un mapa Rust 5000 es demasiado grande para 60 jugadores?

Sí, en la mayoría de los casos. Un mapa 5000 tiene 25 km², mientras que uno de 3500 tiene 12,25 km². Para 60 jugadores, pagáis casi el doble de superficie sin crear más actividad.

¿Cuánta RAM más piden los plugins Rust?

Un pequeño lote de plugins limpios suele añadir 500 MB a 2 GB. Un servidor muy modificado con kits, economía, estadísticas, stacks, loot modificado y logs detallados puede añadir 4 GB o más después de unos días.

¿Cambiar el número de slots reduce la RAM utilizada?

Muy poco si el mapa ya existe. Los slots vacíos casi no consumen nada. La RAM viene sobre todo del tamaño del mapa, de las entidades guardadas, de los sleepers y de los plugins cargados.