jingrow/gunicorn
1
0
Fork 0
mirror of https://github.com/frappe/gunicorn.git synced 2026-01-14 11:09:11 +08:00
Code Issues Packages Projects Releases Wiki Activity

Cleanup trailing whitespaces

Browse Source
This commit is contained in:
Berker Peksag 2016-12-22 22:00:46 +03:00
parent 8fe132b39c
commit 712a502d62
1 changed files with 9 additions and 9 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

18
docs/source/faq.rst
View File

@ -166,17 +166,17 @@ With asynchronous workers, creating URLs with the ``reverse`` function of
How do I avoid Gunicorn excessively blocking in ``os.fchmod``? How do I avoid Gunicorn excessively blocking in ``os.fchmod``?
-------------------------------------------------------------- --------------------------------------------------------------
The current heartbeat system involves calling ``os.fchmod`` on temporary file The current heartbeat system involves calling ``os.fchmod`` on temporary file
handlers and may block a worker for arbitrary time if the directory is on a handlers and may block a worker for arbitrary time if the directory is on a
disk-backed filesystem. For example, by default ``/tmp`` is not mounted as disk-backed filesystem. For example, by default ``/tmp`` is not mounted as
``tmpfs`` in Ubuntu; in AWS an EBS root instance volume may sometimes hang for ``tmpfs`` in Ubuntu; in AWS an EBS root instance volume may sometimes hang for
half a minute and during this time Gunicorn workers may completely block in half a minute and during this time Gunicorn workers may completely block in
``os.fchmod``. ``os.fchmod`` may introduce extra delays if the disk gets full. ``os.fchmod``. ``os.fchmod`` may introduce extra delays if the disk gets full.
Also Gunicon may refuse to start if it can't create the files when the disk is Also Gunicon may refuse to start if it can't create the files when the disk is
full. full.
Currently to avoid these problems you can create a ``tmpfs`` mount (for a new Currently to avoid these problems you can create a ``tmpfs`` mount (for a new
directory or for ``/tmp``) and pass its path to ``--worker-tmp-dir``. First, directory or for ``/tmp``) and pass its path to ``--worker-tmp-dir``. First,
check whether your ``/tmp`` is disk-backed or RAM-backed:: check whether your ``/tmp`` is disk-backed or RAM-backed::
$ df /tmp $ df /tmp