Müsste es nicht sogar die fünftgrößte sein? "Other" ist doch die Zusammenfassung der ganzen anderen sehr viel kleineren Instanzen und nicht eine einzige große Instanz.
this post was submitted on 02 Jul 2023
188 points (100.0% liked)
Haupteingang
38 readers
1 users here now
Die Standard-Community von feddit.de
In dieser Community geht es ausschließlich um alles rund um die Instanz!
Hast du Fragen? !fragfeddit@feddit.de
matrix chat: !feddit:tilde.fun
founded 3 years ago
MODERATORS
Ausgehend von der Anzahl aktiver User im Monat ja
Den deutschen Konservatismus sieht man daran, dass wir die einzige große Instanz mit 1.7.x sind ;)
Langsam aber effizient 😃 Das sorgt wohl die letzten Tage vermehrt für Unmut, bin froh, dass ich mit Jerboa noch auf 17 bin und auf feddit warten kann
load more comments
(1 replies)
*feddit.de
gibt ja noch viele andere "Feddit"s
Soweit ich weiß gibt es nur feddit.de. Die anderen sind "Lemmys".
Es gibt doch z.B. auch feddit.dk und feddit.nl
Feddit.ch
Ich glaub u/red bezieht sich auch Feddit.dk und Feddit.uk und so
Krass, wie groß lemmy.world in so kurzer Zeit geworden ist.
Ich hab' nen Account auf lemmy.world und die mussten ganz schön zaubern, um die Instanz bei so vielen Benutzern noch halbwegs funktional zu halten. Gerade wurde auf die aktuellen Release Candidates von 0.18.1 migriert und da laufen jetzt mehrere Docker-Container für die UI und das Backend und ein dedizierter Container nur für den Scheduler mit nginx als Load Balancer dazwischen ...
Gibt es irgendwo eine Erläuterung zu deren Infrastruktur? Wäre interessant, falls es bei uns irgendwann mal (deutlich) mehr wird.
📓 Das ist die Info, die ich gefunden habe:
Vermutlich macht es Sinn, sich direkt mit @ruud@lemmy.world in Verbindung zu setzen. Mein Eindruck ist, dass er ziemlich kooperativ ist.
The solutions
What I had noticed previously, is that the lemmy container could reach around 1500% CPU usage, above that the site got slow. Which is weird, because the server has 64 threads, so 6400% should be the max. So we tried what @sunaurus@lemm.ee had suggested before: we created extra lemmy containers to spread the load. (And extra lemmy-ui containers). And used nginx to load balance between them.
Et voilà. That seems to work.
Also, as suggested by him, we start the lemmy containers with the scheduler disabled, and have 1 extra lemmy running with the scheduler enabled, unused for other stuff.
There will be room for improvement, and probably new bugs, but we're very happy lemmy.world is now at 0.18.1-rc. This fixes a lot of bugs.
🖥 Letzte mir bekannte Info zur Hardware:
Update The server was migrated. It took around 4 minutes downtime. For those who asked, it now uses a dedicated server with a AMD EPYC 7502P 32 Cores “Rome” CPU and 128GB RAM. Should be enough for now.
Das klingt eher normal für ein Serversystem mit viel Traffic. Ich arbeite für ein SaaS-Unternehmen, und unser Devops-Mensch hat uns angehalten, die Server-Software auf genau so eine Architektur vorzubereiten, auch wenn wir momentan nur eine Instanz brauchen.
Mag sein, aber der Ruud macht das als "Hobby" und es gibt bislang wenig bzw. keine Erfahrung, wie lemmy skaliert. Daher sind seine Erfahrungen m. E. ja so wertvoll für die Community.
Mit Rust sollte das wesentlich einfacher sein als bei Mastodon mit Ruby on Rails.
Naja, die Implementierunsgsprache ist zwar auch wichtig, aber das Design von Protokollen, Datenstrukturen, Code/Concurrency und Infrastruktur ist gar nicht so sehr abhängig davon. Das ist mir schon oft in der OOP-Welt aufgefallen. Nur weil etwas in einer objektorientierten Sprache implementiert ist, hat es nicht automatisch ein gutes bzw. gut skalierbares Design. Ähnliches gilt auch für Rust oder Golang, obwohl beide natürlich spezielle Stärken haben wie memory safety und concurrency.
Ja klar, was man bei Clustering vermeiden muss ist, state im RAM zu halten, weil wenn man das tut und der Client das nächste Mal eine andere Node bekommt, diese nichts davon weiß. Alternativ kann man auch schauen, dass der gleiche Client immer die gleiche Node bekommt, aber das passiert auch nicht von alleine. Das macht restarts dann aber auch schwieriger.
Deswegen hat bei uns auch der devops-Mensch schon in der Entwicklung drauf bestanden, dass ich da dran denke.
Gibt doch nur eine relative Größe an. Könnte also auch bedeuten, dass alle anderen geschrumpft sind.
Die Abstufungen in der Nutzerzahl finde ich besorgniserregend. Ein föderiertes Netzwerk wird schwächer wenn die Nutzer sich auf einige weniger System konzentrieren.
Warum sollte das Netzwerk dadurch schwächer werden? Solange die großen instanzen nicht anfangen grundsätzlich kleine Instanzen zu blockieren ist doch alles im grünen bereich.
Eine gleichmäßige verteilung gibts bei sowas doch nie. Bei email sind auch fast alle auf google oder microsoft, und trozdem ist das in der praxis recht unproblematisch.
Naja, Email mit den großen Providern ist hier wohl eher ein schlechtes Beispiel. Weil man gerade da die Probleme sieht. Google und Microsoft kontrollieren praktisch, wer in der Email-Welt teilnehmen darf und wer nicht. Sich heute dazu zu entscheiden, einen eigenen Email-Server einzurichten, ist schon sehr ambitioniert. Zwar noch möglich, aber mit sehr viel Aufwand verbunden, und möglicherweise klappt es am Ende wegen willkürlichem Blackholing und anderen Strategien der Monopolisten gar nicht.
Bei email sind auch fast alle auf google oder microsoft, und trozdem ist das in der praxis recht unproblematisch
Frag mal Domainbetreiber und Hoster. Weil Gmail zu groß ist, sperrt man dort Domains in Massen, ohne dass die faktisch etwas dagegen tun können. Weil ein Anbieter nach Gutsherrenart den Daumen hebt und senkt, nutzen heute alle Sendgrid, um überhaupt noch an Gmail-Nutzer schreiben zu können.
Gmail ist wirklich das absolute Paradebeispiel, wie ein dezentraler Dienst kaputtgeht, wenn alle einen Dienstleister nutzen.
Unproblematisch? https://archive.ph/dM1LH
Ja unproblematisch.
Das Google zum Teil Mails nicht annimmt, ist ja in erster Linie für die Nutzer von GMail scheiße, weil sie die leidtragenden sind die keine Mails bekommen. Wenns die Nutzer stört können sie ja zu nem anderen Mailprovider gehen der korrekt funktioniert.
Bei föderierten systemen hat man immer einzelne instanzen die total schlecht sind. Das schöne ist ja, das man wechseln kann man man zu unzufrieden ist.
Bei Emails ist sozial immer der Versender schuld, wenn es nicht funktioniert.
Ich persönlich sehe Emails als best-effort delivery, aber in der Allgemeinbevölkerung hat sich die Idee eingeschlichen, dass Emails zuverlässig sind.
Bei Emails ist sozial immer der Versender schuld, wenn es nicht funktioniert.
Da hat man als Betreiber aber viel einfluss wie das wahrgenommen wird.
Wenn man demjenigen der versucht zu versenden explizit Rückmeldung gibt, das die gegenstelle ein problem hat dann sehen die Leute die schuld auch nicht bei sich. Wenn da halt irgendeine unnötig technische Meldung kommt mit der abgesehen von ITlern sonst niemand was anfangen kann, aber von woanders gehts, dann wird natürlich die Schuld beim eigenen Mailprovider gesehen.
load more comments
(1 replies)
Eine gleichmäßige verteilung gibts bei sowas doch nie
Ich würde mich sogar wundern, wenn es nicht die Normalverteilung werden würde.
Ich glaube "lemmy.world" klingt von sich aus einfach größer und globaler. Auf Feddit.de bin ich erst durch explizite Recherche gekommen. Wie sich das alles entwickelt wird sich vermutlich erst Ende des Monats besser abschätzen können, wenn die Aktion mit den APIs bei allen angekommen ist
Was meinst Du mit Schwäche?
Was meinst Du mit Schwäche?
Drei Instanzen haben die Hälfte der ... User? Leider unklar, was genau die Grafik zeigt.
Jedenfalls konzentriert das Macht in den Händen weniger Admins. Meist kein Problem, unter bestimmten Umständen schon. Ein verteilteres Netzwerk ist weniger anfällig für solche Umstände, quasi unspezzable.
unter bestimmten Umständen schon
ja eigentlich nur, wenn sich alles auf einer einzelnen instanz konzentriert, die dann entscheided die förderations abzuschalten.
ob das netz mega verteilt ist oder nur ein paar wenige relevante instanzen spielt ja erstmal keine rolle, solange es möglich bleibt im worst case eine neue instanz hochzuziehen die teilnehmen kann.
Da sehe ich erst mal kein Problem, da es ja, wie Du schon sagtest, verteilt ist. Ich glaube es ist unwahrscheinlich, dass feddit.de im englischsprachigen Raum besonders attraktiv ist. Ich würde mich jedenfalls wegen der Sprachbarrieren nicht den Spaniern zB anschließen.
Viel spannender wäre die Frage, wie einfach man Opensource auflösen und somit eine Monopolstellung einnehmen kann?
Was meinst Du mit Schwäche?
Frag mal die Leute, die sich bei der Twitter-Übernahme durch Musk auf home.social registriert haben und sich gestern einloggen wollten.
Schwieriges Argument finde ich. Auf der einen Seite sollen die Instanzen ähnlich groß sein und auf der Anderen zeigst Du uns einen Artikel, der bestärkt, dass man auf die attraktivste Instanz setzen sollte
auf der Anderen zeigst Du uns einen Artikel, der bestärkt, dass man auf die attraktivste Instanz setzen sollte
home.social hatte 40.000 User. Es ist ein sehr gutes Beispiel dafür, warum sich nicht alle auf die großen Instanzen stürzen sollen.
Da ist dann halt die Frage, wie eine Instanz definiert ist. Wenn ich in Deutschland wohne, bin ich Teil der EU. Wenn ich nach Italien mag, kann ich da hin reisen oder werde Teil davon indem ich mich in Deutschland ab- und in Italien anmelde. In beiden Fällen bin ich Teil der EU. In Deinem Fall hat sich home.social aufgelöst und die User mussten umziehen und ihre Daten zurück lassen.
Um zur Frage der Definition zurück zu kommen: bin ich Teil eines Fediversums und damit überall gespiegelt registriert oder habe ich einen Account bei einer "Home base" und bin damit befugt im Fediversum zu reisen? Aktuell scheint mit dem Beispiel Letzteres implementiert zu sein, das Spiegeln wäre im Endeffekt nur ein immens großes Load-Balancing.
Edit: vermutlich habe ich das Problem nicht verstanden. Ich lebe hier mit dem Risiko, dass sich feddit.de auflöst. Aber das bringt eine Föderation m.E. einfach mit sich
Aber das bringt eine Föderation m.E. einfach mit sich
Das ist ja das zentrale Problem zentralisierter Dienste wie Reddit, Twitter, StudiVZ: Geht eins kaputt, gehen alle vor die Hunde. Dass schiere Massen und 90% der deutschsprachigen Communities auf feddit.de sind, bringt das Risiko mit sich, dass mit dem Ausfall einer Instanz Lemmy für deutschsprachige Nutzer Lemmy über Nacht tot ist.
Verteilen sich die User und Communities, verteilt sich auch das Problem und das Risiko wird erheblich reduziert, da es dann keinen single point of failure wie bei den kommerziellen, geschlossenen Diensten gibt.
load more comments
(3 replies)
No wonder I get so many German posts on my front page
Dieses Fediverse wird langsam Eigentum der Bundesrepublik Deutschland? Oder so?
Interessant finde ich auch, dass feddit.de die einzige Instanz in den oberen 10 ist, deren "Hauptsprache" nicht (auch) englisch ist (sh.itjust.works ist offiziell englisch/französisch, da aus Kanada, allerdings scheint die Mehrheit der Threads auf englisch zu sein).
Sieht leider nicht mehr besonders dezentral aus die Verteilung (was die Nachteile sind, habe ja schon einige hier schon geschrieben). Welche deutschsprachigen Instanzen könnten denn als Alternative empfohlen werden? Zum einen discuss.tchncs.de (deutsch & englisch). Als deutschsprachige kbin-Instanz gibt es noch gehirneimer.de .
Viel schöner, ist der sehr große Anteil an kleinen anderen Instanzen. Wenn alle nur in einer Instanz sitzen, ist das auch nicht sehr resilent.
Gibt es deutschsprachige Kbin-Instanzen?
Nicht, dass ich wuesste
Ist das irgendwie wichtig? Wäre doch nur relevant, wenn diese sich komplett von allen anderen, nicht deutschen Instanzen, abkapseln würden. Aber im großen ganzen macht es in den meisten Fällen kaum bis keinen Unterschied wo man sich registriert.
load more comments
(2 replies)
Was ist das für eine seltsame Sortierung der Kuchendiagrammstücke?
1 nach rechts, dann nach links?
Wohl weil "Andere" eine Aufsummierung ist. Finde das Resultat aber total verwirrend. Das hätte man mindestens besser visuell abtrennen können.
Das ist so nicht unüblich, aber natürlich sind Kuchendiagramme allgemein nicht der informativste Diagrammtyp.
view more: next ›