2018/06/22 - Revision history

Woozle at 18:54, 20 November 2022

2022-11-20T18:54:01Z

← Older revision		Revision as of 18:54, 20 November 2022
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.

Woozle: Woozle moved page Woozle/toot.cat/2018/06/22 to 2018/06/22 without leaving a redirect: indended location

2022-11-20T18:00:20Z

Woozle moved page Woozle/toot.cat/2018/06/22 to 2018/06/22 without leaving a redirect: indended location

← Older revision	Revision as of 18:00, 20 November 2022
(No difference)

Woozle: 4 revisions imported: moved from HTYP

2022-11-20T17:56:43Z

4 revisions imported: moved from HTYP

← Older revision	Revision as of 17:56, 20 November 2022
(No difference)

Woozle at 00:48, 23 June 2018

2018-06-23T00:48:57Z

← Older revision		Revision as of 00:48, 23 June 2018
Line 13:		Line 13:
	root@tootcat2:~# systemctl restart mastodon-sidekiq.service		root@tootcat2:~# systemctl restart mastodon-sidekiq.service
	Warning: mastodon-sidekiq.service changed on disk. Run 'systemctl daemon-reload' to reload units.		Warning: mastodon-sidekiq.service changed on disk. Run 'systemctl daemon-reload' to reload units.
	~~sroot~~@tootcat2:~# systemctl daemon-reload		root@tootcat2:~# systemctl daemon-reload
	</pre>		</pre>

Line 23:		Line 23:

	So then I bumped it up to 100, and within a minute or two the queue was down under 100.		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:<pre>
			root@tootcat2:~# systemctl daemon-reload
			root@tootcat2:~# systemctl restart mastodon-sidekiq.service
			</pre>

Woozle at 00:37, 23 June 2018

2018-06-23T00:37:44Z

← Older revision		Revision as of 00:37, 23 June 2018
Line 8:		Line 8:

	...and rebooted (which wasn't strictly necessary, but the system was asking for one because of a kernel upgrade some days ago).		...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:
			<pre>
			root@tootcat2:~# systemctl restart mastodon-sidekiq.service
			Warning: mastodon-sidekiq.service changed on disk. Run 'systemctl daemon-reload' to reload units.
			sroot@tootcat2:~# systemctl daemon-reload
			</pre>

			After finding [https://discourse.joinmastodon.org/t/lots-of-activerecord-connectiontimeouterror/994/3 this explanation], I understood two things:
			* <code>DB_POOL</code> should be the same as the <code>sidekiq -c</code> value
			* I actually have plenty of CPU headroom, and can boost this quite a bit more.

			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.

Woozle at 00:11, 23 June 2018

2018-06-23T00:11:35Z

← Older revision		Revision as of 00:11, 23 June 2018
Line 7:		Line 7:
	* changing <code>sidekiq -c 25</code> to <code>sidekiq -c 40</code>		* changing <code>sidekiq -c 25</code> to <code>sidekiq -c 40</code>

	...and ~~rebooting~~.		...and rebooted (which wasn't strictly necessary, but the system was asking for one because of a kernel upgrade some days ago).

Woozle: Created page with "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 (accordi..."

2018-06-22T23:54:12Z

Created page with "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 (accordi..."

New page

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 <code>/etc/systemd/system/mastodon-sidekiq.service</code>:
* changing <code>DB_POOL=5</code> to <code>DB_POOL=20</code>
* changing <code>sidekiq -c 25</code> to <code>sidekiq -c 40</code>

...and rebooting.