Sync Gateway not responding

Hi,

I am having issue with Sync Gateway which had been running for last few months, but suddenly stopped responding. It was giving Gateway timeout (504) error to clients. I was not able to access it from browser or couchbase lite, but sync gateway was running fine on server and I could access base sync gateway url (without db). It started working fine after restarting sync gateway.
When I checked sycn gateway logs, I found a huge number of following logs, which look suspicious to me:

10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: Channel feed processing seq:784 in channel * (to *******)
10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: Channel feed processing seq:785 in channel * (to *******)
10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: Channel feed processing seq:786 in channel * (to *******)
10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: MultiChangesFeed sending {Seq:784, ID:13C08103-804D-46C7-9D33-50B973E67255, Changes:[map[rev:2-918e0e86995f09a7e21b0f47abca2aec]]} (to *******)
10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: MultiChangesFeed sending {Seq:785, ID:89EDE5B0-3566-42F9-987F-2B3BD4549D83, Changes:[map[rev:1-371aed190eba85943eba95b965006bf6]]} (to *******)
10:19:03.435605 2017-09-18T10:19:03.435Z Changes+: MultiChangesFeed sending {Seq:786, ID:bece42b7-4922-4e36-83d1-8f2d911cc94c, Changes:[map[rev:1-ad3ee64e5df8252b4005f36d07d20f72]]} (to *******)

note: I have replaced my username with ******* in logs.

The same logs had got repeated for all sequences (1-1500).
I think this might be the reason for sync gateway stopped responding to its clients.
Could you please explain the purpose of above logs?

@vineet.kumar

Those log entries look normal, you have enabled the “Changes+” log key for the _changes feed so your logs will be very verbose.

If you access Sync Gateway via a reverse proxy it’s possible that it returned the 504 if it could not connect to Sync Gateway because of a newtwork issue.

Can you scan the SG logs for error messages and post here if you find any.

If this happens again, you can also validate that SG is running corectly by making calling the REST API using a command line tool such as “curl” e.g.

curl -X GET http://locahost:4985/mydb/_changes