RoundSparrow

We have an urgent performance problem to get finished. The SQL changes are fine, but it seems the Lemmy test code in Rust is defective. This test is failing after we fixed a faulty stored procedure function in PostgreSQL: https://github.com/LemmyNet/lemmy/blob/13a866aeb0c24f20ed18ab40c0ea5616ef910676/crates/db_schema/src/aggregates/site_aggregates.rs#L157

The underlying Rust code needs to be enhanced to query the SQL table with SELECT site_aggregates WHERE site_id = 1, hard-coded 1 is fine, that is always the local site in Lemmy.

Can you please detail all the code changes so that the read method takes an integer parameter for site_id field?

https://github.com/LemmyNet/lemmy/blob/13a866aeb0c24f20ed18ab40c0ea5616ef910676/crates/db_schema/src/aggregates/site_aggregates.rs#L10C7-L10C7

Right now the query has no WHERE clause, pulling the first row it gets. Thank you.

Over a short period of time, this is my incoming federation activity for new comments. pg_stat_statements output being show. It is interesting to note these two INSERT statements on comments differ only in the DEFAULT value of language column. Also note the average execution times is way higher (4.3 vs. 1.28) when the language value is set, I assume due to INDEX updates on the column? Or possibly a TRIGGER?

About half of the comments coming in from other servers have default value.

WRITES are heavy, even if it is an INDEX that has to be revised. So INSERT and UPDATE statements are important to scrutinize.

Given how frequent these records are created, every vote by a user, I think it is important to study and review how it works.

The current design of lemmy_server 0.18.3 is to issue a SQL DELETE before (almost?) every INSERT of a new vote. The INSERT already has an UPDATE clause on it.

This is one of the few places in Lemmy that a SQL DELETE statement actually takes place. We have to be careful triggers are not firing multiple times, such as decreasing the vote to then immediately have it increase with the INSERT statement that comes later.

For insert of a comment, Lemmy doesn't seem to routinely run a DELETE before the INSERT. So why was this design chosen for votes? Likely the reason is because a user can "undo" a vote and have the record of them ever voting in the database removed. Is that the actual behavior in testing?

pg_stat_statements from an instance doing almost entirely incoming federation activity of post/comments from other instances:

• DELETE FROM "comment_like" WHERE (("comment_like"."comment_id" = $1) AND ("comment_like"."person_id" = $2)) executed 14736 times, with 607 matching records.

• INSERT INTO "comment_like" ("person_id", "comment_id", "post_id", "score") VALUES ($1, $2, $3, $4) ON CONFLICT ("comment_id", "person_id") DO UPDATE SET "person_id" = $5, "comment_id" = $6, "post_id" = $7, "score" = $8 RETURNING "comment_like"."id", "comment_like"."person_id", "comment_like"."comment_id", "comment_like"."post_id", "comment_like"."score", "comment_like"."published" executed 15883 times - each time transacting.

• update comment_aggregates ca set score = score + NEW.score, upvotes = case when NEW.score = 1 then upvotes + 1 else upvotes end, downvotes = case when NEW.score = -1 then downvotes + 1 else downvotes end where ca.comment_id = NEW.comment_id TRIGGER FUNCTION update executing 15692 times.

• update person_aggregates ua set comment_score = comment_score + NEW.score from comment c where ua.person_id = c.creator_id and c.id = NEW.comment_id TRIGGER FUNCTION update, same executions as previous.

There is some understanding to gain by the count of executions not being equal.

a lemmysever .social / LemmyFanatic / post / xxxxx

Same with comments

Details here: https://github.com/LemmyNet/lemmy/issues/3165

This will VASTLY decrease the server load of I/O for PostgreSQL, as this mistaken code is doing writes of ~1700 rows (each known Lemmy instance in the database) on every single comment & post creation. This creates record-locking issues given it is writes, which are harsh on the system. Once this is fixed, some site operators will be able to downgrade their hardware! ;)

Cite: 1,3xx Lemmy servers federating https://join-lemmy.org/instances

The code in Lemmy does not seem to federate to all the subscribed servers when a end-user on a remote server deletes their own comment. So far, I can't determine if it has always been this way and nobody noticed, or if something broke at some point in Lemmy code changes. Has it been gong on for weeks, or did it always fail?

Please be kind to users, they may have intended to delete their own comment and Lemmy isn't properly removing it on over 1000 servers and only removes it on 2 servers.

This happens when a community is homed on a server different from the server the end-user is commenting (and deleting that comment) on.

Growing pains.

GitHub issue: https://github.com/LemmyNet/lemmy/issues/3625

I need some help here trying to add a second logging subscriber for a specific target to the Lemmy server Rust code.

Here is the default logging in the app: https://github.com/LemmyNet/lemmy/blob/main/src/lib.rs

Step 1 ==============
I know I have to add another library to log to a file.
cargo add tracing-appender

Step 2 ===============
I know I have to specify how I want the files to work, I found this pile of code:

  let env_filter = EnvFilter::try_from_default_env().unwrap_or_else(|_| EnvFilter::new("info"));
  let formatting_layer = fmt::layer().pretty().with_writer(std::io::stderr);
  let log_file_name = Local::now().format("%Y-%m-%d").to_string() + "-apub.log";
  let file_appender = rolling::daily("/home/lemmy/logs", log_file_name);
  let (non_blocking_appender, _guard) = non_blocking(file_appender);
  let file_layer = fmt::layer()
      .with_ansi(false)
      .with_writer(non_blocking_appender);

  Registry::default()
      .with(env_filter)
      .with(ErrorLayer::default())
      .with(formatting_layer)
      .with(file_layer)
      .init();

Now this isn't right, because it registers itself as "default", and I want it to be a Target - and I still want the normal Lemmy logging behavior to exist.

I want the macros to work like:

warn!("this is how normal Lemmy server log entries are created in the current code");  
warn!(target: "apubfile", "this logging entry only goes to the apub file logging using tracing-appender);

Can someone work this out? How to have two subscribers, not just the single default, and how to specify the target: string on the subscriber?

Thank you.

EDIT: ok, I found an example of how to have two logs at the same time, one to file and one to console: https://stackoverflow.com/questions/76042603/how-to-unify-the-time-in-the-console-and-the-file-when-using-tracing-appender -- I still need to figure out how to get this into Lemmy's structure and attach to a "target".

I don't know Rust, but trying to hack on Lemmy 0.18.1 enough to get a better error message out.

error: data did not match any variant of untagged enum AnnouncableActivities

where: crates/apub/src/activities/community/announce.rs, line: 46

https://github.com/LemmyNet/lemmy/blob/0c82f4e66065b5772fede010a879d327135dbb1e/crates/apub/src/activities/community/announce.rs#L46

That seems to be the function parameters themselves?

Is the error caused by RawAnnouncableActivities not matching the enum AnnouncableActivities and the try_into?

  warn!("zebratrace receive {:?}", self);

Works for adding logging, but I'd like the code to log self only when the enum does not match (errors). Thank you.

I've been spot-checking consistency of replication between servers by looking at the same community on two Lemmy instances, sorting posts by new.

!asklemmy@lemmy.ml is one of the most active communities and people frequently use it incorrectly, asking technical questions about Lemmy instead of "asking the Lemmy community" for their feedback on a topic.

In spot-checking Lemmy servers, it seems that the moderator removal of the posting is only working on the "home" server, Lemmy.ml - and other servers still show the posting in the New sort list (and I assume other sort choices? unverified).

I opened a GitHub issue about the problem: https://github.com/LemmyNet/lemmy/issues/3535

I also thought this would be a good place to raise the topic. Did anyone recall ever testing and spot-checking that moderation removal of a posting worked on multiple servers before?

Thank you.