this post was submitted on 24 Jun 2023
-2 points (42.9% liked)

Lemmy Administration

64 readers
1 users here now

Anything about running your own Lemmy instance. Including how to install it, maintain and customise it.

Be sure to check out the docs: https://join-lemmy.org/docs/en/administration/administration.html

If you have any problems, describe them here and we will try to help you fixing them.

founded 4 years ago
MODERATORS
 

Lemmy.ml front page has been full of nginx errors, 500, 502, etc. And 404 errors coming from Lemmy.

Every new Lemmy install begins with no votes, comments, postings, users to test against. So the problems related to performance, scaling, error handling, stability under user load can not easily be matched given that we can not download the established content of communities.

Either the developers have an attitude that the logs are of low quality and not useful for identifying problems in the code and design, or the importance of getting these logs in front of the technical community and trying to identify the underlying patterns of faults is being given too low of a priority.

It's also important to make each log of failures identifiable to where in the code this specific timeout, crash, exception, resource limit is encountered. Users and operations personnel reporting generic messages that are non-unique only slow down server operators, programmers, database experts, etc.

There are also a number of problems testing federation given the nature of multiple servers involved and trying not to bring down servers in front of end-users. It's absolutely critical that failures for servers to federate data be taken seriously and attempts to enhance logging activities and triangulate causes of why peer instances have missing data be track down to protocol design issues, code failures, network failures, etc. Major Lemmy sites doing large amounts of data replication are an extremely valuable source of data about errors and performance. Please, for the love of god, share these logs and let us look for the underlying causes in hard to reproduce crashes and failures!

I really hope internal logging and details of the inner workings of the biggest Lemmy instances is shared more openly with more eyes on how to keep scaling the applications as the number of posts, messages, likes and votes continue to grow each and every day. Thank you.

Three recently created communities: [email protected] -- [email protected] -- [email protected]

you are viewing a single comment's thread
view the rest of the comments
[–] [email protected] -3 points 1 year ago* (last edited 1 year ago) (2 children)

I agree with you, but I think you sound a bit too harsh for developers.

The failure to inform users by official announcement or mention in the 0.18 release notes that Lemmy is failing to replicate data reliably I think is a failure of the project management. "your data doesn't matter here on the Lemmy network". Why are end users not being told that their messages are in fact not reliably being shared to other instances? Why are the server install and release notes not warning the community that each additional instance being brought online is increasing the replication workload of establishes sites - that are already faltering?

The problem is being covered up, brushed under the rug. The issues of creating tools to adequately load test federation and track problems wasn't raised during project development as an important ToDo item, call for assistance, nor has it really been noticed by most of the server operators. I've personally been going around to dozens of Lemmy instances and hand observing the failures to replicate data. No thought was put into even the most primitive tools to operate a server and have a sense of 'how would you know' if federation was failing?

Yet, the leaders of Lemmy have created directories of "recommended sites" to go sign up with and given the impression that you can access active communities from peer instances to help offload the server reliability problem. Federation itself is unreliable on Lemmy to Lemmy!

Either they are covering up the problem, hiding it out of pride, or not opening bugs on GitHub or not calling for help in the 0.18 Release Notes. Which is it?

[–] ericjmorey 6 points 1 year ago* (last edited 1 year ago) (1 children)

The problem is being covered up, brushed under the rug

Either they are covering up the problem, hiding it out of pride, or not opening bugs on GitHub or not calling for help in the 0.18 Release Notes.

You've raised many good points to come to a wildly accusatory conclusion.

Get off of this line of thinking if you want to raise support for fixing the valid issues you've raised.

Have you made any attempt to see if these issues have been raised on GitHub? Have you made any attempt to create issues on GitHub? Have you made any attempt to submit code enhancements via GitHub?

[–] [email protected] -2 points 1 year ago* (last edited 1 year ago) (1 children)

Have you made any attempt to see if these issues have been raised on GitHub? Have you made any attempt to create issues on GitHub? Have you made any attempt to submit code enhancements via GitHub?

Have the developers of Lemmy put a message to end-users that data is being lost? have the operators of servers opened issues on GitHub about 'pending subscribe' failures on federation? Have the developers of Lemmy put warnings in the Release Notes that scaling is an active concern and needs urgent attention? Have the operators of major Lemmy websites published their nginx server logs and application code logs so that the bugs and design problems of the code are logged?

Is the logging in the Rust code so worthless, so poor, that they don't share logs and find them of any use?

Most of all,e at your own dogfood, where are Lemmy developers using Lemmy to archive discussions about scalability and performance issues causing major crashes?

"I like Rust" but don't like using Lemmy to discuss the performance concerns of scaling and data integrity in a monolithic Rust application?

[–] ericjmorey 3 points 1 year ago (1 children)

It looks like you want to vent and issue demands of others rather than be productive. I hope that serves you well.

[–] [email protected] -2 points 1 year ago

It looks like you want to vent and issue demands of others rather than be productive. I hope that serves you well.

And how is this reply productive? **You are just trying to cover up the very real scaling problems of Lemmy code and project mismanagement by insulting me **personally for having autism that you misinterpret. It took me 3 weeks of courage to make this post about how mismanaged this project is, and here you are - DENIAL of the problems in the design and code.

It looks like you want to vent

If I want to vent: I'll go to Reddit and start making postings about how unreliable Lemmy is as an application and how it can't even share community comments on a daily basis - and the developers don't give a single shit to read their own Lemmy communities and make postings about needing help with Rust webapp 101 and PostgreSQL.

[–] [email protected] 1 points 1 year ago (1 children)

I like your posts and hunt for performance issues, I just think that developers decided (wether you and I agree or not) some other features are more important.

Until few weeks ago communication was clear since there were not many people here, so there was no need for some specific notes you are mentioning.

Now we do need them and reminding developers of it, or even better doing it would be much appreciated I expect.

I have seen developers on some threads here or on github issues commenting on repication problems and they are hard at work for those.

Even caching is discussed, as I understand, they first need to implement cache control headers so that admins can set up caching, as they see fit, outside lemmy.

There is a lo of good will around, please have understanding and be part of it. Give the time to grow up to this opportunity.