I migrated to TrueNAS Scale this year from a DIY Debian+ZFS+Xen that I built back around 2017. My son’s Minecraft server worked well on this old setup on an unoptimized spinning rust raidz1. On TrueNAS I’ve been testing just the vanilla Minecraft Java Edition server found in the Discover Apps. Basically you can fly/run in a direction and go beyond the edge – then you have to wait for the world to load under you.
Earlier this year I spent quite a bit of time trying to figure out what the problem was, I gave up at the time and just have an old server turned on for him exclusively. A few weeks I got newer hardware for TrueNAS. It works great – except still Minecraft has issues loading world chunks fast enough.
So I experimented: I created a Custom YAML from the App. I moved the container from /mnt/.ix-apps to /data/fast. I fixed up the YAML to find the container there. The /data is on boot-pool which is a single small SSD. It works great.
The issue seems to be coming from TrueNAS’s ZFS or my new spinning disks. I’ve read a lot of hate for the drives I have. My main pool is 3 disks of Seagate BarraCuda 8TB SATA 6Gb/s 256MB Cache (ST8000DM004-2U9188). But, I have a hard time believing these spinning disks are noticeably slower than the 4TB SATA spinning disks that I had before.
I was going to say i’ll ignore the SMR disks and you haven’t mentioned anything about the workload that the pool is under, but if they’re busy rewriting shingles in the background when you want to read a bunch of new stuff, you’ll get quite poor performance. Assuming this tstuff isn’t captured by the ARC, you could increase your RAM or throw a cache drive at it if it’s static world data. I think I can gaze into my crystal ball and see what the rest of the community will say though….
Is the block size of the zvol aligned with the use case btw? or are you hunting for 4k data blocks on a large source file and running out of IOPS? I have no idea how minecraft works, but the zfs tuning stuff seems quite particular about performance issues of large record/volblocksize and reading small chunks within large files on these big block sizes.
Thank you for your reply. I’m not sure how Minecraft server works either! It uses a seed to generate the world. So initially there really isn’t any data to read, it’s just writing what it’s computing as you move around the map. So the activity should be writing the chunks that are computed. For reference, a large world after considerable play is still only .5 GB.
The load on the pool is a trickle – a Frigate NVR App writing ~200Kbits/sec. I can turn this Docker/App off with no change in behavior. No volumes are mounted.
ARC is over 20GB. On the 6-core CPU, it has a load of up to 1 if Frigate is running, and if it’s turned off a load of .1 or so.
Maybe I’ll get lucky and someone will know more about how Minecraft writes/reads.
Update: The (generated) world is probably written with a bunch of small chunks. I’ve read more about SMR drives. I’m going to say it’s these SMR drives unless someone wants ot change my mind!
Probably. We don’t know the performance requirements of Minecraft and we don’t know the performance of your pool. If you have empty SATA ports, get two cheap consumer 500GB SSDs that are not QLC and not from the same vendor, put them into a mirror and your apps will fly
