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.