Open adamkendall1 opened 2 years ago
Related, but not the same as https://github.com/LandSandBoat/server/issues/2077
RE: ARM: the raspberry pi build (exists, but not fully supported) should still be working, so ARM builds are probably OK. There's a section for it in the quick start guide
Anecdotally, I used to run my own test server on whatever small GCP machine fit in their $300 welcome credits promotion for around a year. I think that was the e2-small, with the only caveat being I would provision a bigger machine for 5-10 mins to do my build, store the binaries in a storage bucket, then transfer and replace the ones on my actual server.
Ah, you're right. I did not make the connection between rpi being ARM based. I'll have to test that out on t4g instance types next.
Anecdotally, I used to run my own test server on whatever small GCP machine fit in their $300 welcome credits promotion for around a year. I think that was the e2-small, with the only caveat being I would provision a bigger machine for 5-10 mins to do my build, store the binaries in a storage bucket, then transfer and replace the ones on my actual server.
Interesting! I'll try swapping down to a t3a.small after the build then. Thanks.
Will be interested in your findings, we don't have any of this codified anywhere
The build succeeded with 2 vCPU, 4GB RAM on x86 ubuntu 22.04
Server also seems to run on this configuration (haven't connected / created character yet)
I think it's safe to say at this point though that those are the minimum requirements for building the server on x86 Linux.
xiweb is build/run on a 1core 2GB on Ubuntu server without issues, but we don't have 100 users login in at once. Only max 10 daily average. Also all zones are sleeping except the ones that hold chars.
when I build LSB on Linux it's an ARM server running aarch64. this is the same as rpi4. OS is Ubuntu 22.04 like the CI. I've tested it on a rpi4 compute module 4 with 8gb ram and had no issues
Currently I'm testing this in AWS using a t3a.small (2 vCPU, 2GB RAM, 8GB SSD) which has proven to be too small. It gets stuck during the make at 44% where the whole server locks up and must be rebooted. I'm suspecting this is a memory issue as the CPU load was right around 1.8 before locking up and free storage is at about 2GB when I restart the server. But memory is hovering at around 300MB free.
I've done it on a weaker system than this. Build is slower than sanity could tolerate but technically possible. Running it on the other hand, was fine.
What I was doing for awhile was building on my laptop then transferring the built executables to my "server" which was really a pretty beaten up netbook. Like seriously the screen was busted, the keyboard was busted, the trackpad was busted...I hooked up an external monitor and a usb keyboard long enough to set up remote access, and after that it lived on a shelf in my basement. 1ghz single core cpu and 2gb ram, and it still rand the mapserver just fine for up to a max of 20 simultaneous players (and then we ran into disk write speed trying to update database as our 1st bottleneck, and were coming close on ram - cpu still wasn't an issue except when I was on remote - the remote session used more cpu than the game!)
I think we should have 2 sets of recommendations: one for reasonable build time specs, one for reasonable runtime specs.
For running the game, 6gb ram is enough for even 100 players. I've legit measured this. The headroom is there. But for the build process I'd want at least 2 fast cpu cores and 16gb of ram to not scream obscenities at my maker :smile:
p.s. I would not try to build on an aws instance if they paid me to do it.
RE: ARM: the raspberry pi build (exists, but not fully supported) should still be working, so ARM builds are probably OK. There's a section for it in the quick start guide
A long time ago, I was able to get topaz compiled and running on a Raspi 3B (not the +; this is quad core 1.2 GHz with 1GB of RAM that is split between normal RAM and VRAM depending on the "bios" with the minimum VRAM being 16MB) the only problem I had was actually running the server in its default configuration. Because of the high initial RAM requirement, it will lock up a lower end pi due to running out of RAM, even with the minimal set up for graphics. I have NOT tested it after setting up the swapfile to an appropriate size, but that might not help, as 2GB of swap doesn't keep VSCode from occasionally freezing the pi into a state where it has to be rebooted (this could also be due to the resolution I had it set to display at, I could try lower resolutions if I decide to mess with it again). I do not have a 4 model to test on, but I imagine it'd be fine on the 4GB and 8GB models, possibly even the 2GB model if its the only thing running (and after manually adjusting the swapfile to an appropriate size).
Also, my test setup was all 3 servers (with all the zones enabled), and the database. My end goal was to set up a "cluster" and have the zones spread out across multiple pis, but I never got around to testing it with the 2 I have as I'd put it off until I could get a 4, but it should be doable.
So a remote server with higher specs should be more than capable of it. The only other hurdle I had was figuring out what dependencies I needed to install since I was the one that wrote that guide, and the linux guide was not entirely good enough as some of the dependencies were different. Since Oracle is giving away free VMs with quad core ARM processors with much more RAM, including a database setup, it could be tested on those to see what specifically is needed to both compile and run.
On my Desktop, LSB takes around 1.6-1.8GB for the full server when the map server is first started, and drops down to using around 200-500 MB (haven't paid attention recently, but I know it drops A LOT), but that is with just me connecting to it. I imagine this goes up with more people in more zones doing more things at once. The database itself seems to barely use anything at all, but I haven't actually looked for it in the task manager, because when I sort by memory usage, its not even in the top 20.
Describe the feature
I think it may be helpful for new users to describe what the minimum system requirements are for building and running this on a server.
Currently I'm testing this in AWS using a t3a.small (2 vCPU, 2GB RAM, 8GB SSD) which has proven to be too small. It gets stuck during the make at 44% where the whole server locks up and must be rebooted. I'm suspecting this is a memory issue as the CPU load was right around 1.8 before locking up and free storage is at about 2GB when I restart the server. But memory is hovering at around 300MB free.
Will try t3a.medium next (2 vCPU, 4GB RAM).
Also, it's not clear in the readme which CPU architectures are supported (x86 vs. ARM). It would be awesome if we can support ARM to save even more money on server costs. In AWS, ARM can be up to 30% cheaper to run.
Will report back soon with the results of t3a.medium.