this post was submitted on 30 Dec 2023
28 points (100.0% liked)
/kbin meta
639 readers
1 users here now
Magazine dedicated to discussions about the kbin itself. Provide feedback, ask questions, suggest improvements, and engage in conversations related to the platform organization, policies, features, and community dynamics. ---- * Roadmap 2023 * m/kbinDevlog * m/kbinDesign
founded 1 year ago
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
It's the new lemmy update that is the issue. It broke a lot. Lots of people are abandoning lemmy anyhow, which is why the servers are so empty now. I don't expect many lemmy servers to continue in the next six months.
Kbin is not lemmy
the lemmy changes are causing excessive resource use on my 'bin instance. so yeah, not using lemmy, but being directly affected by the lemmy snafu.
my failed messaging queue is filling, which has its own retry logic.. that queue buildup also takes disk space.... extra processing, extra disk space.. this leads to 'worker' slowdown and then system failures and timeouts.
When I looked at Kbin the "caddy" was wrapped around RabbitMQ. You can get RabbitMQ to solve a lot of those issues.
Firstly with Rabbit you can set a Time To Live header in messages.
By default RabbitMQ queues have no limit in size, you can set a limit.
Lastly RabbitMQ allows message prioritisation. So you can drop the priority of things the older/more retries they contain.
Most of this is either RabbitMQ policy or Queue rules based on Headers in the AMQP message. Depending on how KBin is generating messages you might be able to do this as a system admin
oh yep, am familiar with the underlying tech. the mbin devs had this resolved relatively quickly.
What does any of this have to do with kbin? Kbin is not Lemmy. Completely different codebase.
the lemmy changes are causing excessive resource use on my 'bin instance. so yeah, not using lemmy, but being directly affected by the lemmy snafu.
my failed messaging queue is filling, which has its own retry logic.. that queue buildup also takes disk space.... extra processing, extra disk space.. this leads to 'worker' slowdown and then system failures and timeouts.
Oh, interesting. My bad then, it's common for people to be unaware that kbin is a different thing from Lemmy and so I made an incorrect assumption.
I suppose this reveals some room for improvement in kbin, then. Other servers' problems shouldn't be impacting kbin as badly as this, likely indicating that kbin needs to add some robustness when it comes to dealing with stuff like this.
your thought process isnt completely off. if my server product was detecting the failures correctly, these resources wouldnt pile up.
i dont think people really understand just how brand new all this stuff is. 'the fediverse' is under active development. they call it the 'bleed edge' of technology because its painful. most fediverse servers are experiencing growing pains of some sort.
the Lemmy/kbin sides are still wet behind the ears. i just hope people dont give up!
The beginning of reddit was much the same. Things stopped working all the time. Weird bugs popped up. And there were people posting posts like this a lot trying to figure out what was going on.
Just curious, why do you say that lots of people are abandoning Lemmy? I'm still seeing lots of users and posts from Lemmy instances every day.
LOL. I am expecting Lemmy to continue far into the future.