escapingnetwork / core-keeper-dedicated

Dockerfile for automated build of a Core Keeper Dedicated Server
https://hub.docker.com/r/escaping/core-keeper-dedicated
MIT License
121 stars 36 forks source link

Lag/Rubberbanding #59

Open S1ckWithIt opened 1 month ago

S1ckWithIt commented 1 month ago

Hello!

I am hosting this server for 3 players, all on the same LAN, on dedicated hardware I have in my server rack. 90% of the time we don't have issues but there are times when there is lag or rubberbanding going on. I've restarted the docker container and even restarted the host but it comes and goes. I haven't found a good way to reproduce nor resolve it. In my CoreKeeperServerLogs, these lines tell me when it happens:

Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak
To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 15)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 15)
Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak
To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.
S1ckWithIt commented 1 month ago

I did more testing. If a player is in the base where the core is (0,0) while a person makes it beyond the first wall (sunket sea, desert, etc). The error start rolling in and there is rubberbanding. If the players are all together, there is no lag.

arguser commented 1 month ago

Do you think it's related to the server being on a container or to the server itself?

S1ckWithIt commented 1 month ago

I've tried changing various settings within the server itself. I've allocated more RAM and vCPUs but it doesn't help. The server itself is only using 2gb RAM (allocated 8gb) and 2x vCPU (down from 4x) sits around 35% to 55% usage. Can I allocate more resources to the container itself? Below are more logs, it seems to be more of the same.

Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Allocating a new file write buffer of size 8.000MB for WorldSave. Total buffer size for this file including pool is 8.000MB
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak
To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 7)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 7)
Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak
To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 6)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 6)
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 5)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 6)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 6)
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 8)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 8)
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
Internal: JobTempAlloc has allocations that are more than the maximum lifespan of 4 frames old - this is not allowed and likely a leak
To Debug, run app with -diag-job-temp-memory-leak-validation cmd line argument. This will output the callstacks of the leaked allocations.
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 7)
Internal: deleting an allocation that is older than its permitted lifetime of 4 frames (age = 7)
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
PugMath.YAxisLerp: directionToTarget has no length in the XZ-plane - defaulting to forward.
PugMath.YAxisLerp: currentDirection has no length in the XZ-plane - defaulting to forward.
borsTiHD commented 1 week ago

I have the same experience. The trigger for me is presumably also when one player is in the base at the core and another is porting outside the first wall. Apart from that, everything runs smoothly.