Difference between revisions of "2018/06/22"
m (Woozle moved page Woozle/toot.cat/2018/06/22 to 2018/06/22 without leaving a redirect: indended location) |
|||
| Line 1: | Line 1: | ||
| + | {{page/date|nav=[[2018/05/30|prev]] .. [[2018/06/22|today]] .. [[2018/07/18|next]] }} | ||
This isn't the first time this has happened... outgoing toots are being delayed by something like 1.5-2 hours. Last time, we upped the number of threads from 15 to 25 (according to my memory; apparently we didn't document it), and that seemed to fix the blockage. | This isn't the first time this has happened... outgoing toots are being delayed by something like 1.5-2 hours. Last time, we upped the number of threads from 15 to 25 (according to my memory; apparently we didn't document it), and that seemed to fix the blockage. | ||
Latest revision as of 18:54, 20 November 2022
Friday, June 22, 2018 (#173)
This isn't the first time this has happened... outgoing toots are being delayed by something like 1.5-2 hours. Last time, we upped the number of threads from 15 to 25 (according to my memory; apparently we didn't document it), and that seemed to fix the blockage. So this time, I'm making notes. Editing
...and rebooted (which wasn't strictly necessary, but the system was asking for one because of a kernel upgrade some days ago). ...and then it turned out I had forgotten to save my changes before rebooting, so I had to do this: root@tootcat2:~# systemctl restart mastodon-sidekiq.service Warning: mastodon-sidekiq.service changed on disk. Run 'systemctl daemon-reload' to reload units. root@tootcat2:~# systemctl daemon-reload After finding this explanation, I understood two things:
I first tried 40, and that helped a bit -- but the "busy" queue was still getting stuck around 3500. So then I bumped it up to 100, and within a minute or two the queue was down under 100. Also, do things in this order:root@tootcat2:~# systemctl daemon-reload root@tootcat2:~# systemctl restart mastodon-sidekiq.service |