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 I also expect it’ll work again better when the team will have gotten around to implementing database cleanup; keeping this many tombstones around is crazy (and lanodan (IIRC) said it doesn’t even need to keep any around), data from old/unreachable/blocked instances can go including accounts, and even old refetchable stati could very well go, perhaps even old own ones optionally like in some instances…
@m0xee I’ve also posted and boosted much more than you, have a slightly larger followership and followee count, and my instance also hosts a few RSS to Fediverse bots (with probably smallish followership but still) amounting up to quite some load.
@mirabilos
Oh, on that instance I have even less posts and followers and…When it's under load — and it's also my seedbox, printserver, it hosts SimplyTranslate and Git and few more things, I sometimes do not receive all the replies in a timely manner, I can't see all the comments in some threads — at times, I'm surprised that it works at all — still, not bad for an experiment with rare architecture: https://breloma.m0xee.net/users/m0xEE
Right now it's building LLVM for PPC natively so it might not even open😂
@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 😁
@m0xee hmmhmmhmm, seems I severely underestimated the impact of the other stuff running on the original VM.
The new one currently basically runs only GtS, with raised-back-to-default cache memory target and all, and…
top - 19:20:25 up 2 days, 14:44, 1 user, load average: 0.00, 0.00, 0.00 Tasks: 143 total, 1 running, 142 sleeping, 0 stopped, 0 zombie %Cpu(s): 0.5 us, 0.2 sy, 0.0 ni, 99.2 id, 0.2 wa, 0.0 hi, 0.0 si, 0.0 st KiB Mem : 4013528 total, 243552 free, 291284 used, 3478692 buff/cache KiB Swap: 1571772 total, 1483028 free, 88744 used. 3246756 avail Mem
… it’s bored, and lots of RAM are even free.
So, okay, yes, GtS probably is currently suitable on a 1 vCPU, 1 GiB RAM machine with PostgreSQL.
(The much faster storage on the new VM might also help, but there’s a lot in cache, the DB is over 3 GiB now but that would just fit into cache here.)
@mirabilos
That's interesting. Thanks for the info!
@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.