I have a problem with my instance. Sometimes the refresh of the timeline is very slow and even fails sometimes. Can one of you help me with the troubleshooting? I can’t find anything conspicuous in the logs.
I found something in the logs after all:
[httplog] GET https://mstdn.jp/users/miku_cdP#main-key completed with status code 410 in 137.4732386340038 seconds
Does that look familiar to anyone?
Is it just a request to ask for data of some user that is now deleted?
With a timeline, can you check what’s up with your node streaming process?
I believe this occurs with both existing and deleted users.
I’m sorry for the stupid question, but how can I check the node streaming process?
There are no stupid questions.
I have a process running process like this:
76513 5- IJ 0:00.87 /usr/local/bin/node ./streaming/index.js
You can start it my hand or together with your system, there is some info about it in the Mastodon Production Guide (search for “streaming”).
There should be 3 components running:
puma main Mastodon engine,
sidekiq workers (both in Ruby) and a node streaming service. Plus there is usually a webserver such as nginx on top of this.
I have the three components. I had set up the streaming endpoint incorrectly, but it works now.
I think I found the problem. When the search api (/api/v2/search?q=https://mastodonten.de/@username&resolve=true) is called, I get the error message “503 Remote data could not be fetched”.
Any idea why that might be happening?
So is the “slow timeline requests” problem solved now?
For the search, I’d check the Ruby puma service log.
The problem with the slow timeline is partially solved. All 5-10 requests are still slow.
Search: I can’t find anything suspicious in the logs. Is it enough if I set the