Skip to content

Instantly share code, notes, and snippets.

@Hadryan

Hadryan/gist:a782212e44eecb7c884be20620c47f8f

Forked from amichaelgrant/gist:90d99d7d5d48bf8fd209
Created August 31, 2023 08:15
Show Gist options
  • Save Hadryan/a782212e44eecb7c884be20620c47f8f to your computer and use it in GitHub Desktop.
Save Hadryan/a782212e44eecb7c884be20620c47f8f to your computer and use it in GitHub Desktop.
Download ZIP

Revisions

  1. @amichaelgrant amichaelgrant created this gist Nov 11, 2014.
    25 changes: 25 additions & 0 deletions gistfile1.txt
    View file
    Original file line number Diff line number Diff line change
    @@ -0,0 +1,25 @@
    failed (104: Connection reset by peer) while reading response header from upstream, client:
    If you are getting the above error in nginx logs running in from of upstream servers you may consider doing this as it worked for me:
    check the ulimit on the machines and ensure it is high enough to handle the load coming in. 'ulimit' on linux, I am told determines the maximum number of open files the kernel can handle.

    The way I did that?
    modifying limits: for open files:
    --------------------------------
    add or change this line in /etc/systcl.conf
    fs.file-max = <limit-number>

    set soft & hard limits in this file for various users: /etc/security/limits.conf
    <user-name or group-name or *> soft nofile <limit-number>
    <user-name or group-name or *> soft nofile <limit-number> hard nofile <limit-number>

    Then reload the system settings withou restarting:
    sysctl -p


    nginx settings :
    --------------------------------
    in nginx.conf add/set:
    worker_rlimit_nofile <limit-number>

    When setting up upstream servers or not, it is a good idea to keep some connections alive when running on HTTP 1.1. Consider adding this to the upstream block on :
    keepalive <some-number>;