Hi Ryne,
Thanks a lot a lot for the tip.
David
On Thursday, July 21, 2016 at 6:10:58 PM UTC+2, Ryne Everett wrote:
>
> A couple causes of gunicorn timeouts I've seen is larger files that don't
> transfer within the default --timeout (30 seconds). This isn't necessarily
> your problem but if it
A couple causes of gunicorn timeouts I've seen is larger files that don't
transfer within the default --timeout (30 seconds). This isn't necessarily
your problem but if it is you can increase the timeout. I've also seen it
when streaming files, in which case the solution is to make the workers
asyn
Hi Ken,
Thanks.
Yes I can but I'm not sure where do you want to get because the issuet
happens on different sites and on different actions (sometimes just loading
the home page and other time isnide the admin).
I have been looking on the web and it looks like some people solved it by
increasi
Are you able to use the django runserver? It is very hard for me to tell
where the problem might be, so I would step through each piece until I find
the root cause, starting with the django runserver.
hth,
ken
On Thu, Jul 21, 2016 at 6:06 AM, loevdav
wrote:
> Hi Ken,
>
> Thanks a lot for the r
Hi Ken,
Thanks a lot for the reply:
Here are the logs:
*Error log*
[2016-07-01 10:30:43 +] [3496] [CRITICAL] WORKER TIMEOUT (pid:1105)
[2016-07-01 10:30:49 +] [3496] [CRITICAL] WORKER TIMEOUT (pid:6783)
[2016-07-01 10:35:53 +] [3496] [CRITICAL] WORKER TIMEOUT (pid:7129)
[2016-07-01
Hi David,
I've gotten away with Mezzanine from the deploy scripts on some very
low-power hardware, including raspberry pi and virtualboxen with 500MB RAM,
My guess is this is not an issue of resources.
Can you share the relevant Django logs that coincide with your bad gateway?
They may provide i
