Yeah well, #GotoSocial has finally reached sufficient uptime / federated instances / stati / accounts / tombstones / whatever that it stops being operable without running into timeouts for everything on a 1 GiB RAM VM.
(If I press F5 after the timeout, things are served from cache and usually work after one F5, but now have started requiring two F5 cycles.)
It was nice while it lasted. I’ll have to work on continuing setup of the VM with more RAM when I find mental capacity for it…
@mirabilos
So it doesn't work too well on a machine with just 1 gig? Good to know!
I was thinking about using it instead of Pleroma on my old G4 MacMini. Pleroma lags and timeouts too under load of course and I was thinking GotoSocial might be bit easier on the hardware, but looks like there's no point in exchanging one for the other 😩
@m0xee oh it worked well for way over a year.
I suspect it might work longer (looking at RAM constraints) if it used SQLite instead of proper PostgreSQL, but the VM already had PostgreSQL set up for another website and SQLite is illegal anyway, and without Apache 2 httpd proxying in front of it taking up a small share of RAM as well, but that’d be not how I set up things.
If you only use it for GtS, let GtS directly do its own SSL, and use SQLite instead of a database, it will fit for longer, RAM-wise.
Not sure how mature issue9’s PowerPC support is, and Mac OSX is bound to use more RAM than a BSD or GNU/Linux cut down to run as single-purpose server.
@mirabilos Yes, Go is definitely a problem! gccgo (not the reference toolchain) works on big endian 64-bit PowerPC and I think I have even managed to build it for 32-bit PPC in the past, but I can't seem to be able to do it anymore — syscall definitions are missing, and while adding these should be possible, making all the external modules word would probably be a bigger challenge.
And it runs Void Linux already — so at least that won't be a problem 😁
