Optimizar servidor Palworld: RAM, núcleos y pals base

Optimizar servidor Palworld implica ajustar la RAM, los núcleos de CPU y los parámetros de PalWorldSettings.ini al número real de jugadores y de pals activos en tus bases, en lugar de reservar recursos de más que después quedan sin usar. El resultado es un mundo persistente fluido, sin picos de carga cuando varias bases procesan IA de pals a la vez.

Optimizar servidor Palworld: RAM y núcleos según el número de jugadores

Palworld corre sobre Unreal Engine y depende mucho de la frecuencia por núcleo, no solo de la cantidad total de hilos. Un proceso de servidor con pocos jugadores conectados ya consume una base de RAM considerable porque carga el mundo completo, los pals salvajes y la lógica de las bases en memoria desde el arranque.

A partir de ahí, cada jugador adicional y cada pal asignado a una base suman consumo de forma progresiva. La tabla siguiente da un punto de partida realista, no un límite estricto, para calcular los recursos de un proceso Palworld.

Jugadores simultáneos	RAM recomendada	Núcleos dedicados
1 a 4	6 a 8 GB	4
8 a 16	12 a 16 GB	6
24 a 32	20 a 24 GB	8

Una CPU con buena frecuencia monohilo, como un Ryzen 9 7950X3D, reduce los tirones al procesar pathfinding de pals en varias bases a la vez, algo que un procesador compartido con muchas cargas simultáneas no siempre sostiene. Si tu comunidad ya ronda los 16 jugadores activos con bases grandes, conviene revisar la hosting Palworld que estás usando antes de seguir subiendo parámetros en el archivo de configuración.

Parámetros de PalWorldSettings.ini que más impactan el rendimiento

El archivo PalWorldSettings.ini controla casi todo lo que pesa en el proceso: número de jugadores, velocidad de trabajo de los pals, cantidad de objetos tirados en el suelo y frecuencia de guardado automático. Tocar estos valores sin medir el efecto suele ser la causa número uno de un servidor que se vuelve lento con el tiempo.

[/Script/Pal.PalGameWorldSettings]
ServerPlayerMaxNum=16
BaseCampWorkerMaxNum=15
BaseCampMaxNumInGuild=4
PalSpawnNumRate=1.000000
WorkSpeedRate=1.000000
DropItemMaxNum=3000
DropItemAliveMaxHours=1.000000
AutoSaveSpan=30.000000

DropItemMaxNum y DropItemAliveMaxHours

Estos dos parámetros definen cuántos objetos tirados puede haber en el mapa a la vez y cuánto tiempo permanecen antes de borrarse. Un valor alto de DropItemMaxNum combinado con un DropItemAliveMaxHours largo acumula miles de entidades físicas que el servidor sigue calculando aunque nadie las recoja.

AutoSaveSpan

El guardado automático bloquea brevemente el mundo mientras escribe el estado en disco. Reducir este valor a menos de 15 minutos en un mundo con muchas bases provoca microcortes frecuentes; subirlo demasiado aumenta el riesgo de perder progreso si el proceso se cae.

Cuántos pals por base soporta el servidor sin perder fluidez

El parámetro BaseCampWorkerMaxNum fija cuántos pals pueden trabajar en una misma base. Por defecto el juego permite 15, y la interfaz del juego permite subirlo hasta 20 desde las opciones de dificultad del mundo. Cada pal asignado ejecuta su propia lógica de trabajo, movimiento y pathfinding de forma constante.

Con 20 pals por base y varias bases activas en el mismo servidor, el cálculo de IA empieza a competir por ciclos de CPU con la simulación del resto del mapa. En la práctica, mantener el límite entre 15 y 18 pals por base suele dar el mejor equilibrio entre producción y fluidez para comunidades con varias bases grandes.

BaseCampMaxNumInGuild limita cuántas bases puede tener un mismo gremio. Multiplicar bases sin tocar este valor es otra forma habitual de sobrecargar el servidor: diez bases con 20 pals cada una representan 200 entidades activas de forma simultánea, incluso si los jugadores están desconectados.

Ajustar la configuración según el tamaño de la comunidad

No tiene sentido aplicar la misma configuración a un grupo de cuatro amigos que a una comunidad abierta de treinta jugadores. Separar los perfiles de configuración evita gastar recursos en parámetros pensados para una escala distinta.

Grupo pequeño (1 a 6 jugadores)

• ServerPlayerMaxNum entre 6 y 8
• BaseCampWorkerMaxNum en 15, el valor por defecto
• PalSpawnNumRate en 1.0, sin necesidad de reducirlo

Comunidad mediana (8 a 20 jugadores)

• ServerPlayerMaxNum entre 16 y 20
• DropItemMaxNum reducido a 1500 para limitar objetos acumulados
• AutoSaveSpan en 20 minutos como equilibrio razonable

Comunidad grande (24 jugadores o más)

• BaseCampWorkerMaxNum limitado a 15 para contener la carga de IA
• BaseCampMaxNumInGuild reducido si hay muchos gremios activos
• PalSpawnNumRate bajado ligeramente si el mapa está muy poblado de pals salvajes

Monitorizar el consumo de recursos para detectar cuellos de botella

Ajustar parámetros a ciegas sin medir el resultado lleva a repetir el mismo error varias veces. Si administras el proceso desde un VPS Linux, comandos simples ya dan una lectura clara del estado del sistema.

top -o %CPU
free -h
systemctl status palworld-server
journalctl -u palworld-server -n 100 --no-pager

Si el uso de CPU se mantiene alto incluso con pocos jugadores conectados, el problema suele estar en el número de pals activos en las bases, no en la cantidad de usuarios. Si la RAM crece de forma constante sin bajar tras un reinicio del mundo, revisa primero DropItemMaxNum y el número de bases abiertas.

Errores habituales que sobrecargan un servidor Palworld

La mayoría de problemas de rendimiento vienen de acumulación, no de un único parámetro mal puesto. Identificarlos antes de tocar el hardware ahorra tiempo y evita cambios innecesarios.

• Subir BaseCampWorkerMaxNum al máximo en todas las bases sin medir el impacto real en CPU
• Dejar DropItemAliveMaxHours en valores altos mientras los jugadores destruyen estructuras y dejan escombros
• Permitir demasiadas bases por gremio sin ajustar BaseCampMaxNumInGuild
• No reiniciar el proceso de forma periódica, acumulando memoria que el motor no libera del todo
• Instalar varios mods pesados de pals o estructuras sin probar el consumo por separado

Para una visión general de qué otros juegos exigen una configuración similar de CPU y RAM dedicadas, conviene revisar Todos nuestros servidores de juegos antes de decidir cómo repartir recursos entre varios mundos.

Conclusión

Empieza siempre por el BaseCampWorkerMaxNum y el número de bases activas antes de tocar RAM o núcleos: es ahí donde se concentra la mayor parte de la carga real. Sube los recursos asignados solo cuando las métricas de CPU y memoria lo justifiquen, no de forma preventiva.

FAQ

¿Por qué mi servidor Palworld va lento aunque hay pocos jugadores conectados?

Casi siempre se debe al número acumulado de pals trabajando en las bases y a objetos tirados que nadie recoge. El servidor sigue calculando esa actividad aunque los jugadores estén desconectados, así que revisar BaseCampWorkerMaxNum y DropItemMaxNum suele resolver el problema antes que subir hardware.

¿Cada cuánto conviene reiniciar el proceso del servidor?

Un reinicio programado cada 24 horas, fuera de las horas de mayor actividad, ayuda a liberar memoria que el motor no limpia de forma automática durante sesiones largas. Combinarlo con un guardado previo evita cualquier pérdida de progreso para los jugadores.

¿Los mods de Palworld afectan al consumo de recursos del servidor?

Sí, especialmente los que añaden nuevas estructuras, pals o mecánicas de base. Cada mod activo suma procesamiento adicional, así que conviene probarlos de uno en uno y comparar el uso de CPU y RAM antes de combinar varios en el mismo mundo.