# Status update July 4th Just wanted to let you know where we are with
Lemmy.world. ## Issues As you might have noticed, things still won’t work as
desired… we see several issues: ### Performance - Loading is mostly OK, but
sometimes things take forever - We (and you) see many 502 errors, resulting in
empty pages etc. - System load: The server is roughly at 60% cpu usage and
around 25GB RAM usage. (That is, if we restart Lemmy every 30 minutes. Else
memory will go to 100%) ### Bugs - Replying to a DM doesn’t seem to work. When
hitting reply, you get a box with the original message which you can edit and
save (which does nothing) - 2FA seems to be a problem for many people. It
doesn’t always work as expected. ## Troubleshooting We have many people helping
us, with (site) moderation, sysadmin, troubleshooting, advise etc. There
currently are 25 people in our Discord, including admins of other servers. In
the Sysadmin channel we are with 8 people. We do troubleshooting sessions with
these, and sometimes others. One of the Lemmy devs, @nutomic@lemmy.ml
[https://lemmy.ml/u/nutomic] is also helping with current issues. So, all is not
yet running smoothly as we hoped, but with all this help we’ll surely get there!
Also thank you all for the donations, this helps giving the possibility to use
the hardware and tools needed to keep Lemmy.world running!
Assez intéressant de voir l’usage de la RAM, il y a clairement un souci de ce côté là, après c’est cool de voir qu’ils bossent avec des devs de Lemmy pour corriger le problème
J’imagine que la priorité est de combler ces fuites mémoire. Que tous les grosses instances redémarrent chaque 30 minutes, c’est loin d’être idéal.
De même, il était question de perte de messages entre instances. Et il n’y a aucun système de rattrapage. Lorsqu’un contenu n’est pas transmis d’une instance à l’autre suite à une erreur, il ne sera jamais transmis. Ce n’est pas absolument catastrophique comme fonctionnement, mais ça donne une idée du protocole : simple, mais avec des pertes.
Idéalement le protocole voudrait une myriade de petites instances au lieu de monolithes.
Ils sont confrontés à ça aussi sur mastodon avec mastodon.social qui est désormais l’instance par défaut pour les inscriptions et qui centralise aussi beaucoup de problèmes
Rust ça rend difficile l’accès à la mémoire “illégale” genre segfault, ça n’empêche pas d’attribuer de la mémoire et de la gérer n’importe comment malheureusement.
Je ne connais pas Rust mais il suffit de créer des structures (ex. objets) sans les libérer.
Un exemple connu en protocole réseau, c’est par exemple de dire “Boujour ça va ?” (SYN), recevoir “Bonjour ça va, et toi ?” (ACK), mais ne jamais répondre "Ça va. (SYN-ACK).
https://fr.m.wikipedia.org/wiki/Three-way_handshake
Et recommencer plein de fois. Le serveur va garder en mémoire une petite structure pour attendre la réponse et au bout d’un moment, être saturé.
https://fr.m.wikipedia.org/wiki/SYN_flood
J’imagine que la priorité est de combler ces fuites mémoire. Que tous les grosses instances redémarrent chaque 30 minutes, c’est loin d’être idéal.
De même, il était question de perte de messages entre instances. Et il n’y a aucun système de rattrapage. Lorsqu’un contenu n’est pas transmis d’une instance à l’autre suite à une erreur, il ne sera jamais transmis. Ce n’est pas absolument catastrophique comme fonctionnement, mais ça donne une idée du protocole : simple, mais avec des pertes.
Idéalement le protocole voudrait une myriade de petites instances au lieu de monolithes. Ils sont confrontés à ça aussi sur mastodon avec mastodon.social qui est désormais l’instance par défaut pour les inscriptions et qui centralise aussi beaucoup de problèmes
C’est vraiment des fuites mémoires ? En Rust ça semble difficile d’en faire, non ? Peut-être plus une politique de caching. (Pure spéculation.)
Rust ça rend difficile l’accès à la mémoire “illégale” genre segfault, ça n’empêche pas d’attribuer de la mémoire et de la gérer n’importe comment malheureusement.
Je ne connais pas Rust mais il suffit de créer des structures (ex. objets) sans les libérer.
Un exemple connu en protocole réseau, c’est par exemple de dire “Boujour ça va ?” (SYN), recevoir “Bonjour ça va, et toi ?” (ACK), mais ne jamais répondre "Ça va. (SYN-ACK). https://fr.m.wikipedia.org/wiki/Three-way_handshake
Et recommencer plein de fois. Le serveur va garder en mémoire une petite structure pour attendre la réponse et au bout d’un moment, être saturé. https://fr.m.wikipedia.org/wiki/SYN_flood
Tout à fait