Skip to content

Use all 4 vCPUs and add Chunky for worldgen pre-generation - #12

Open
OpenSource-For-Freedom wants to merge 1 commit into
mainfrom
feat/pregen-chunky
Open

Use all 4 vCPUs and add Chunky for worldgen pre-generation#12
OpenSource-For-Freedom wants to merge 1 commit into
mainfrom
feat/pregen-chunky

Conversation

@OpenSource-For-Freedom

Copy link
Copy Markdown
Owner

Speeds up world generation after the droplet resize.

Two changes

1. Raise the container CPU cap from 2.0 to 3.5.
The droplet went from 2 to 4 vCPUs, but docker-compose.yml pinned the container at cpus: 2.0. Without this the resize buys nothing at all: the container was measured pegged at ~197% of 2 cores with load average 3.95 during worldgen, which is the real reason exploring felt slow once Terralith started generating new terrain.

3.5 rather than 4.0 deliberately. The host still needs cycles for sshd/tailscaled, auditd, Docker and the deploy timer. Handing the entire box to the JVM makes the admin plane unresponsive exactly when the server is busiest, which is when you most need to get into it.

2. Add Chunky 1.3.146 - https://cdn.modrinth.com/data/fALzjamp/versions/4FTDk9wv/Chunky-1.3.146.jar

Verified against the Modrinth API before pinning: release channel, loaders: [forge], lists 1.20.1, 333 KB, no dependencies.

Chunky pre-builds chunks instead of generating them while a player is flying through them. This is the fix that actually matters long-term: pre-generated terrain costs nothing to explore later.

Player impact: none

Chunky is client_side: optional / server_side: optional and is an admin tool, not gameplay. It does nothing until an op runs a command. It is not in the player pack, so nobody re-imports anything and no client changes.

How it gets used after merge

Run when nobody is playing:

docker exec minecraft-java rcon-cli chunky radius 3000
docker exec minecraft-java rcon-cli chunky start
docker exec minecraft-java rcon-cli chunky pause      # before players join
docker exec minecraft-java rcon-cli chunky continue   # resume later

It checkpoints to disk, so a restart resumes rather than starting over.

Security / supply chain

  • Pinned to an immutable Modrinth version URL, same as the other 26 mods. No name resolution, so a restart cannot silently pull a different build.
  • REMOVE_OLD_MODS=TRUE still holds; no floating refs introduced.
  • No new ports, no new egress, no capability or rootfs change. Container hardening is untouched.
  • Raising the CPU cap does not widen any trust boundary; the 0.5-core reserve protects admin access under load.

Sizing note

Pre-generation permanently grows the world save, roughly 1 GB per 1500-block radius in the overworld. The disk auto-grew to 154 GB on resize with 148 GB free, so radius 3000 is comfortable. Do not set 20000 casually.

Verified before pushing

  • docker compose config renders; effective cpus: 3.5
  • All 27 mod URLs version-pinned; new jar returns HTTP 200
  • Droplet confirmed s-4vcpu-8gb-amd, nproc = 4, root fs 154 GB

The droplet was resized from 2 to 4 vCPUs, but the container carried a
hard `cpus: 2.0` cap, so the two new cores would have gone entirely
unused. Worldgen had been sitting at ~197% of 2 cores with load 3.95,
which is the actual reason exploring felt slow after Terralith landed.
Raise the cap to 3.5 and leave 0.5 for the host, so sshd/tailscaled,
auditd and the deploy timer stay responsive while the server is busy.

Add Chunky 1.3.146 (Forge, 1.20.1, pinned, no dependencies) so chunks
can be built ahead of time instead of on the critical path while a
player is flying. It is server-only and inert until an op runs a
command, so the player pack is unchanged and nobody has to re-import
anything.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant