การหมดเวลาของ NGINX หลังจากการเชื่อมต่อพร้อมกัน +200


12

นี่คือของฉันnginx.conf(ฉันได้อัปเดตการกำหนดค่าเพื่อให้แน่ใจว่าไม่มี PHP ที่เกี่ยวข้องหรือคอขวดอื่น ๆ ):

user                nginx;
worker_processes    4;
worker_rlimit_nofile 10240;

pid                 /var/run/nginx.pid;

events
{
    worker_connections  1024;
}

http
{
    include             /etc/nginx/mime.types;

    error_log           /var/www/log/nginx_errors.log warn;

    port_in_redirect    off;
    server_tokens       off;
    sendfile            on;
    gzip                on;

    client_max_body_size 200M;

    map $scheme $php_https { default off; https on; }

    index index.php;

    client_body_timeout   60;
    client_header_timeout 60;
    keepalive_timeout     60 60;
    send_timeout          60;

    server
    {
        server_name dev.anuary.com;

        root        "/var/www/virtualhosts/dev.anuary.com";
    }
}

ฉันใช้http://blitz.io/playเพื่อทดสอบเซิร์ฟเวอร์ของฉัน (ฉันซื้อแผนการเชื่อมต่อพร้อมกัน 10 000 รายการ) ใน 30 วินาทีเรียกฉันได้รับความนิยมและ964 5,587 timeoutsการหมดเวลาครั้งแรกเกิดขึ้นที่ 40.77 วินาทีในการทดสอบเมื่อจำนวนผู้ใช้พร้อมกันอยู่ที่ 200

ในระหว่างการทดสอบโหลดเซิร์ฟเวอร์คือ ( topเอาต์พุต):

 PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND                                                               20225 nginx     20   0 48140 6248 1672 S 16.0  0.0   0:21.68 nginx                                                                  
    1 root      20   0 19112 1444 1180 S  0.0  0.0   0:02.37 init                                                                   
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd                                                               
    3 root      RT   0     0    0    0 S  0.0  0.0   0:00.03 migration/0      

ดังนั้นจึงไม่ใช่ปัญหาทรัพยากรเซิร์ฟเวอร์ ถ้าเช่นนั้นจะเป็นอะไร

อัพเดท 2011 12 09 GMT 17:36

จนถึงตอนนี้ฉันได้ทำการเปลี่ยนแปลงต่อไปนี้เพื่อให้แน่ใจว่าคอขวดไม่ใช่ TCP / IP เพิ่มไปที่/etc/sysctl.conf:

# These ensure that TIME_WAIT ports either get reused or closed fast.
net.ipv4.tcp_fin_timeout = 1
net.ipv4.tcp_tw_recycle = 1
# TCP memory
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

ข้อมูลการแก้ปัญหาเพิ่มเติมบางส่วน:

[root@server node]# ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 126767
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 10240
cpu time               (seconds, -t) unlimited
max user processes              (-u) 1024
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

NB ที่worker_rlimit_nofileตั้งค่าเป็น10240nginx config

อัพเดท 2011 12 09 GMT 19:02

ดูเหมือนว่าฉันจะทำการเปลี่ยนแปลงมากกว่านี้ยิ่งแย่ลงเท่าไหร่ แต่ที่นี่ไฟล์ปรับแต่งใหม่

user                nginx;
worker_processes    4;
worker_rlimit_nofile 10240;

pid                 /var/run/nginx.pid;

events
{
    worker_connections  2048;
    #1,353 hits, 2,751 timeouts, 72 errors - Bummer. Try again?
    #1,408 hits, 2,727 timeouts - Maybe you should increase the timeout?
}

http
{
    include             /etc/nginx/mime.types;

    error_log           /var/www/log/nginx_errors.log warn; 

    # http://blog.martinfjordvald.com/2011/04/optimizing-nginx-for-high-traffic-loads/
    access_log              off;

    open_file_cache         max=1000;
    open_file_cache_valid   30s;

    client_body_buffer_size 10M;
    client_max_body_size    200M;

    proxy_buffers           256 4k;
    fastcgi_buffers         256 4k;

    keepalive_timeout       15 15;

    client_body_timeout     60;
    client_header_timeout   60;

    send_timeout            60;

    port_in_redirect        off;
    server_tokens           off;
    sendfile                on;

    gzip                    on;
    gzip_buffers            256 4k;
    gzip_comp_level         5;
    gzip_disable            "msie6";



    map $scheme $php_https { default off; https on; }

    index index.php;



    server
    {
        server_name ~^www\.(?P<domain>.+);
        rewrite     ^ $scheme://$domain$request_uri? permanent;
    }

    include /etc/nginx/conf.d/virtual.conf;
}

อัพเดท 2011 12 11 GMT 20:11

นี่คือผลลัพธ์ของnetstat -ntlaในระหว่างการทดสอบ

https://gist.github.com/d74750cceba4d08668ea

อัพเดท 2011 12 12 GMT 10:54

เพียงเพื่อชี้แจงiptables(ไฟร์วอลล์) ปิดในขณะทดสอบ

อัพเดท 2011 12 12 GMT 22:47

นี่คือการsysctl -p | grep memถ่ายโอนข้อมูล

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0
kernel.sysrq = 0
kernel.core_uses_pid = 1
net.ipv4.tcp_syncookies = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 65536 8388608
net.ipv4.route.flush = 1
net.ipv4.ip_local_port_range = 1024 65000
net.core.rmem_max = 16777216
net.core.rmem_default = 16777216
net.core.wmem_max = 8388608
net.core.wmem_default = 65536
net.core.netdev_max_backlog = 262144
net.core.somaxconn = 4096
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_orphans = 262144
net.ipv4.tcp_max_syn_backlog = 262144
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

อัพเดท 2011 12 12 GMT 22:49

ฉันใช้blitz.ioเพื่อเรียกใช้การทดสอบทั้งหมด URL ที่ฉันกำลังทดสอบคือhttp://dev.anuary.com/test.txtโดยใช้คำสั่งต่อไปนี้:--region ireland --pattern 200-250:30 -T 1000 http://dev.anuary.com/test.txt

อัพเดท 2011 12 13 GMT 13:33

nginxขีด จำกัด ของผู้ใช้ (ตั้งค่า/etc/security/limits.conf)

nginx       hard nofile 40000
nginx       soft nofile 40000

คุณเป็นโฮสต์นี้ด้วยตัวเอง? ไม่มีโหลดบาลานเซอร์หรืออะไรอย่างนั้นต่อหน้าเซิร์ฟเวอร์? มีบางสิ่งจาก ISP ที่อาจตรวจพบว่าเป็นการโจมตีแบบ DDoS และลดระดับลง
Bart Silverstrim

ใช่นี่คือเซิร์ฟเวอร์ของฉัน ovh.co.uk/dedicated_servers/eg_ssd.xmlไม่มีสิ่งใดที่จะช่วยลดการโจมตี DDoS ได้ ฉันได้เพิ่มขึ้นด้วยการworker_processes 4
Gajus

เพียงติดต่อ OVH เพื่อตรวจสอบอีกครั้งว่าไม่มีหลักทรัพย์ระดับเครือข่ายใด ๆ ที่ติดตั้งบนเซิร์ฟเวอร์ของฉัน ไม่มีเลย
Gajus

คุณให้บริการข้อมูลประเภทใด html, images, etc?
pablo

1
ฉันคิดว่ามันจะช่วยในการเรียกใช้เกณฑ์มาตรฐานในท้องถิ่นเพื่อตัดการกำหนดค่า nginx ไม่ใช่เหรอ
3molo

คำตอบ:


2

คุณจะต้องถ่ายโอนข้อมูลการเชื่อมต่อเครือข่ายของคุณในระหว่างการทดสอบ ในขณะที่เซิร์ฟเวอร์อาจมีค่าเกือบเป็นศูนย์โหลดสแต็ก TCP / IP ของคุณอาจเรียกเก็บเงิน ค้นหาการเชื่อมต่อ TIME_WAIT ในเอาต์พุต netstat

หากเป็นกรณีนี้คุณจะต้องตรวจสอบการปรับพารามิเตอร์เคอร์เนล tcp / ip ที่เกี่ยวข้องกับสถานะ TCP Wait, recyling TCP และตัวชี้วัดที่คล้ายกัน

นอกจากนี้คุณยังไม่ได้อธิบายสิ่งที่กำลังทดสอบ

ฉันมักจะทดสอบ:

  • เนื้อหาคงที่ (รูปภาพหรือไฟล์ข้อความ)
  • simple php page (เช่น phpinfo)
  • หน้าแอปพลิเคชัน

สิ่งนี้อาจใช้ไม่ได้ในกรณีของคุณ แต่เป็นสิ่งที่ฉันทำเมื่อทำการทดสอบประสิทธิภาพ การทดสอบไฟล์ประเภทต่าง ๆ สามารถช่วยคุณระบุตำแหน่งคอขวดได้

แม้ว่าจะมีเนื้อหาแบบคงที่การทดสอบขนาดไฟล์ที่แตกต่างก็มีความสำคัญเช่นกันเพื่อให้ได้เวลาหมดและตัวชี้วัดอื่น ๆ

เรามีกล่อง Nginx เนื้อหาแบบสแตติกที่จัดการการเชื่อมต่อที่ใช้งานมากกว่า 3000 รายการ ดังนั้น Nginx จึงสามารถทำได้อย่างแน่นอน

ปรับปรุง: netstat ของคุณแสดงการเชื่อมต่อเปิดมากมาย อาจต้องการลองปรับแต่งสแต็ก TCP / IP ของคุณ นอกจากนี้คุณต้องการไฟล์อะไร Nginx ควรปิดพอร์ตอย่างรวดเร็ว

นี่คือคำแนะนำสำหรับ sysctl.conf:

net.ipv4.ip_local_port_range = 1024 65000
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 30
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_tw_reuse = 1

ค่าเหล่านี้ต่ำมาก แต่ฉันประสบความสำเร็จกับกล่อง Nginx ที่เกิดขึ้นพร้อมกันสูง


ดูUPDATE 2011 12 09 GMT 17:36.
Gajus

เพิ่มการปรับปรุงเพื่อตอบกลับหลักเนื่องจากรหัส
jeffatrackaid

โปรดเพิ่มเอาต์พุตที่สมบูรณ์ในระหว่างการทดสอบคุณไม่ควรตรวจสอบว่า CPU nginx ใช้งานไปเท่าไหร่
Giovanni Toraldo

1
ระมัดระวังเมื่อใช้ net.ipv4.tcp_tw_recycle = 1 โดยทั่วไปแล้วพูดว่า: ไม่ใช่ความคิดที่ดี ใช้ซ้ำได้
ไม่ระบุตัวตนหนึ่ง

ทำไมไม่ใช้ซ็อกเก็ต Linux แทน localhost
BigSack

1

อีกสมมติฐานหนึ่ง คุณเพิ่มขึ้นworker_rlimit_nofileแต่จำนวนลูกค้าสูงสุดถูกกำหนดไว้ในเอกสารประกอบดังนี้

max_clients = worker_processes * worker_connections

ถ้าคุณพยายามที่จะยกระดับworker_connectionsเช่น 8192 หรือถ้ามีแกน CPU เพียงพอให้เพิ่มworker_processesหรือไม่


1

ฉันมีปัญหาคล้ายกันมากกับกล่อง nginx ซึ่งทำหน้าที่เป็น load balancer พร้อมกับเซิร์ฟเวอร์ apache ต้นน้ำ

ในกรณีของฉันฉันสามารถแยกปัญหาให้เกี่ยวข้องกับระบบเครือข่ายเนื่องจากเซิร์ฟเวอร์ apache อัพสตรีมเริ่มทำงานมากเกินไป ฉันสามารถสร้างมันใหม่ด้วยสคริปต์ทุบตีง่าย ๆ ในขณะที่ระบบโดยรวมอยู่ในระหว่างการโหลด ตาม strace ของหนึ่งในกระบวนการที่หยุดทำงานการเรียกใช้การเชื่อมต่อได้รับ ETIMEDOUT

การตั้งค่าเหล่านี้ (บนเซิร์ฟเวอร์ nginx และ upstream) กำจัดปัญหาให้ฉัน ฉันได้รับ 1 หรือ 2 ครั้งต่อนาทีก่อนที่จะทำการเปลี่ยนแปลงเหล่านี้ (กล่องจัดการ ~ 100 reqs / s) และตอนนี้ได้รับ 0

net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_fin_timeout = 20
net.ipv4.tcp_max_syn_backlog = 20480
net.core.netdev_max_backlog = 4096
net.ipv4.tcp_max_tw_buckets = 400000
net.core.somaxconn = 4096

ฉันจะไม่แนะนำให้ใช้ net.ipv4.tcp_tw_recycle หรือ net.ipv4.tcp_tw_reuse แต่ถ้าคุณต้องการที่จะใช้หนึ่งไปกับหลัง พวกเขาสามารถทำให้เกิดปัญหาที่แปลกประหลาดหากมีความล่าช้าใด ๆ และอย่างน้อยก็ปลอดภัยกว่าของทั้งสอง

ฉันคิดว่าการตั้งค่า tcp_fin_timeout เป็น 1 ด้านบนอาจทำให้เกิดปัญหาเช่นกัน ลองวางที่ 20/30 - ยังต่ำกว่าค่าเริ่มต้น


0

อาจไม่ใช่ปัญหา nginx ในขณะที่คุณทดสอบ blitz.io ให้ทำ:

tail -f /var/log/php5-fpm.log

(นั่นคือสิ่งที่ฉันใช้ในการจัดการ php)

สิ่งนี้ทำให้เกิดข้อผิดพลาดและหมดเวลาเริ่มที่จะยกระดับ:

WARNING: [pool www] server reached pm.max_children setting (5), consider raising it

ดังนั้นใส่ max_children มากขึ้นใน fmp conf และทำมัน! ; D


ปัญหาจะเหมือนกันถ้าฉันมีreturn 200 "test"ใน NGINX ซึ่งหมายความว่า NGINX ไม่ได้ไปไกลถึงการเรียกใช้ PHP-FPM
Gajus

0

คุณมีน้อยเกินไปmax open files(1024) ลองเปลี่ยนและรีสตาร์ท nginx ( cat /proc/<nginx>/limitsเพื่อยืนยัน)

ulimit -n 10240

และเพิ่มworker_connectionsเป็น 10240 หรือสูงกว่า


ฉันไม่แน่ใจว่าทำไมเรื่องนี้ลงคะแนนเสียง ดูเหมือนคำตอบที่ถูกต้องสำหรับฉัน
Ryan Angilly
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.