Gunicorn worker timeouts
I have a django service that is ran with gunicorn works. For some reason, my more expensive DB requests are timing out and crashing. The log shows up as:
I also attached the resource useage. It shouldn't be memory nor vcpu since there is much more left. Unless for some reason gunicorn doesn't recognize that it can tap into more memory for a given worker? Is that possible? I am not 100% sure what might be going on. Then again, it might just be a timeout and not memory related. I still find it strange though that the memory consumption for django + workers is so steady with no change in levels. Idk.
project id: 1b326884-0c17-43ed-9b52-f443662e8f50
Solution:Jump to solution
Eh. Honestly changing it to be through the private proxy didn't really change things. But either way, the original problem was a skill issue and so this thread can be marked solved.
18 Replies
Project ID:
1b326884-0c17-43ed-9b52-f443662e8f50hmmmm actually, it might just be timing out and I need to up the timeout limit. That is fine. But I do still wonder about the memory being so steady. And also while the query is expensive, it shouldn't be that expensive. Strange for sure. :hmmmm:
Oh well. I shall figure it out
Yea, the default timeout is 30s. Idk why but I thought it was 60s. I will try to bump it up and see if that fixes my issue. Likely it will. But that is upsetting that this query is taking that long. Because I look at the logs of postgres, and it has 0 complaints. So it must really be a timeout and not to do with memory.
Lol this is such a sad day. Yea, the query is just too slow. :cry_gil: Ok. No issues. Thanks
Time to add a loader indicator on the page. smh. Clearly none of the users actually use this query since not a single complaint has come in .. but :shrug:
database on railway and you're connecting to it via the private network, right?
Yea
Wait ... maybe it isn't ???? Hold up I gotta go check something :scared:
Alright yea, it was calling
PGHOST and not PGPRIVATEHOST. Switiching it now and deploying. Lets see if that makes things better. I guess yea, I have not touched this project in quite a bit of time .... oopsthese things happen
:cry_gil: time to debug
(also the new old builder is much faster lol. Thanks)
Ah. I think it is because the private port is different than the public one. Any reason for this?
The reason for the private port being different from the public port?
No actually I can intuit the reason
But there is no var ref for it? Is this accurate. I can't seem to find one?
exposing 5432 for everyone's database isn't scalable haha
No
RAILWAY_PRIVATE_TCP_PROXY_PORTRAILWAY_TCP_APPLICATION_PORTAh yep, just found that
as long as you have a TCP proxy on the database, that is what you want to use for the internal port
Yea. And it does make sense as a name once I know about it. I was just looking for the miror of the other var name with
PRIVATE in it.that's fair
Solution
Eh. Honestly changing it to be through the private proxy didn't really change things. But either way, the original problem was a skill issue and so this thread can be marked solved.
sounds good to me