#sidekiq

Es ist Vollbracht, die #SideKiq Queues von #Mastodon sind alle leer. Wir ( #Anoxinon ) sind damit wieder UpToDate und jetzt wo der Server aufgeholt hat, ist die IO auch deutlich gesunken. Die Nachwirkungen des Recovers sind damit durch. Natürlich gibt es aber noch so einige weitere Dinge wie Dokumentation Optimieren, Auf räum Arbeiten usw.

So damit sind alle Queues bis auf default leer; Diese hat noch 245.750, wird aber jetzt gut abgebaut. Die Doppelten Einträge in preview_cards scheinen aber auch noch mal sehr relevant zu sein, dessen löschen scheint die DB ausgesprochen zu entlasten.

#Anoxinon #Mastodon #Postgres #SideKiq

Ich habe dann mal wieder ein #SideKiq Queue splitt umgesetzt wie wir es schon mal bei #Mstodon eingesetzt haben. Siehe hier: https://codeberg.org/Anoxinon_e.V./mastodon_sidekiq Der Server ist dadurch auf jeden Fall ein Wenig mehr beschäftigt als ohne den Splitt.

Liebes #Fediverse und vor allem liebe #mastoadmin Gruppe. Wie ist euer aktueller Stand zu #SideKiq und deren Worker und Queues. Früher hatte man die ja auf ggf. mehrere laufende #SystemD Units aufgeteilt, ich meine aber das dies nicht mehr aktuell ist und keinen Vorteil bringen sollte. Aktuell sieht es bei uns halt wie folgt aus und ich frage, mich warum ich ihn nicht dazu bekomme mehr zu machen. DB_POOL:140 worker: 128 queues: default, 20 push, 9 ingress, 30 mailers, 3 #anoxinon Tipps?

Dear #MastoAdmin for anyone using #S3 storage I would highly recommend disabling S3 multipart uploads for a day (or forever) to see if you notice any improvements.

Pre-existing issues with Mastodon and S3, plus some recent regressions in the #AWS S3 library can cause a variety of issues, notably in the ingress #sidekiq worker, such as:

• infinite disk usage in /tmp
• higher outbound bandwidth use (2-4x)
• higher cpu and memory use by sidekiq
• higher costs on providers like Wasabi that have minimum duration charges for incomplete multipart uploads

You can do this by setting S3_MULTIPART_THRESHOLD=1073741824 (any sufficiently high value that all processed media will fit below).

Note that setting S3_FORCE_SINGLE_REQUEST=true is not sufficient, as this only impacts reading files from S3 to disk, and not uploading to S3. Increasing S3 timeouts and retries may help, but doesn't solve the issues entirely.

The results will depend on your environment and specific S3 provider, but are significant and worth testing to see if they affect you.

https://github.com/mastodon/mastodon/issues/39863

https://github.com/aws/aws-sdk-ruby/issues/3408

https://github.com/mastodon/mastodon/pull/30610