ต้องการเพิ่มปริมาณงาน nginx ให้กับซ็อกเก็ตยูนิกซ์อัปสตรีม - การปรับแต่งเคอร์เนลลินุกซ์หรือไม่?


28

ฉันกำลังเรียกใช้เซิร์ฟเวอร์ nginx ที่ทำหน้าที่เป็นพร็อกซีไปยังซ็อกเก็ตอัพสตรีมยูนิกซ์เช่นนี้

upstream app_server {
        server unix:/tmp/app.sock fail_timeout=0;
}

server {
        listen ###.###.###.###;
        server_name whatever.server;
        root /web/root;

        try_files $uri @app;
        location @app {
                proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
                proxy_set_header X-Forwarded-Proto $scheme;
                proxy_set_header Host $http_host;
                proxy_redirect off;
                proxy_pass http://app_server;
        }
}

เซิร์ฟเวอร์แอปบางตัวจะดึงคำขอออก/tmp/app.sockเมื่อพร้อมใช้งาน เซิร์ฟเวอร์แอปที่ใช้งานเฉพาะที่นี่คือยูนิคอร์น แต่ฉันไม่คิดว่าเกี่ยวข้องกับคำถามนี้

ปัญหาคือดูเหมือนว่าผ่านการโหลดจำนวนหนึ่ง nginx ไม่สามารถรับการร้องขอผ่านซ็อกเก็ตในอัตราที่เร็วพอ ไม่ว่าฉันจะติดตั้งแอปเซิร์ฟเวอร์จำนวนเท่าใด

ฉันได้รับข้อความเหล่านี้จำนวนมากในบันทึกข้อผิดพลาด nginx:

connect() to unix:/tmp/app.sock failed (11: Resource temporarily unavailable) while connecting to upstream

คำขอจำนวนมากส่งผลให้เกิดรหัสสถานะ 502 และคำขอที่ไม่ต้องใช้เวลานานกว่าจะเสร็จสมบูรณ์ สถิติคิวการเขียน nginx วนเวียนอยู่รอบ ๆ 1,000

อย่างไรก็ตามฉันรู้สึกเหมือนขาดอะไรบางอย่างที่นี่เพราะการกำหนดค่าเฉพาะของ nginx และเซิร์ฟเวอร์แอพนี้ค่อนข้างธรรมดาโดยเฉพาะกับ Unicorn (เป็นวิธีที่แนะนำในความเป็นจริง) มีตัวเลือกเคอร์เนล linux ที่ต้องตั้งค่าหรืออะไรใน nginx? ความคิดใด ๆ เกี่ยวกับวิธีเพิ่มปริมาณงานให้กับซ็อกเก็ตอัปสตรีม? สิ่งที่ฉันทำผิดอย่างชัดเจน?

ข้อมูลเพิ่มเติมเกี่ยวกับสภาพแวดล้อม:

$ uname -a
Linux servername 2.6.35-32-server #67-Ubuntu SMP Mon Mar 5 21:13:25 UTC 2012 x86_64 GNU/Linux

$ ruby -v
ruby 1.9.3p194 (2012-04-20 revision 35410) [x86_64-linux]

$ unicorn -v
unicorn v4.3.1

$ nginx -V
nginx version: nginx/1.2.1
built by gcc 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5)
TLS SNI support enabled

การปรับแต่งเคอร์เนลปัจจุบัน:

net.core.rmem_default = 65536
net.core.wmem_default = 65536
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.tcp_mem = 16777216 16777216 16777216
net.ipv4.tcp_window_scaling = 1
net.ipv4.route.flush = 1
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.somaxconn = 8192
net.netfilter.nf_conntrack_max = 524288

การตั้งค่า Ulimit สำหรับผู้ใช้ nginx:

core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 20
file size               (blocks, -f) unlimited
pending signals                 (-i) 16382
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 65535
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) unlimited
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

คุณตรวจสอบผลลัพธ์ของulimitจำนวนไฟล์ที่เปิดเฉพาะหรือไม่
เลด

@Khaled, กล่าวว่าulimit -n 65535
Ben Lee

คำตอบ:


16

ดูเหมือนว่าคอขวดคือแอปที่เปิดช่องเสียบแทนที่จะเป็น Nginx เราเห็นสิ่งนี้มากกับ PHP เมื่อใช้กับซ็อกเก็ตกับการเชื่อมต่อ TCP / IP ในกรณีของเรา PHP เกิดปัญหาคอขวดเร็วกว่า Nginx มาก

คุณได้ตรวจสอบเกินขีด จำกัด การติดตามการเชื่อมต่อ sysctl.conf ซ็อกเก็ต backlog จำกัด

  • net.core.somaxconn
  • net.core.netdev_max_backlog

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

เตรียมพร้อมที่จะย้ายเซิร์ฟเวอร์ใหม่ไปยังสถานที่เพื่อให้ปริมาณงานเพียงพอสร้างระบบขึ้นใหม่อย่างสมบูรณ์และยังมีปัญหาเดิมอยู่ ดังนั้นมันกลับกลายเป็นว่าปัญหาของฉันไม่ได้รับการแก้ไขหลังจากทั้งหมด ... = (ฉันยังคงคิดว่ามันเป็นแอพเฉพาะ แต่ไม่สามารถคิดอะไรได้เลยเซิร์ฟเวอร์ใหม่นี้ได้รับการตั้งค่าเหมือนกับเซิร์ฟเวอร์อื่นที่ทำงานได้ดีใช่ somaxconn และ netdev_max_backlog อัพอย่างถูกต้อง
เบ็นลี

ปัญหาของคุณไม่ได้เป็น nginx มันเกินความสามารถ - แต่นั่นไม่ได้หมายความว่าคุณอาจไม่มีการตั้งค่าโกง ซ็อกเก็ตมีความไวสูงเป็นพิเศษภายใต้การโหลดสูงเมื่อขีด จำกัด ไม่ได้รับการกำหนดค่าอย่างถูกต้อง คุณลองแอปของคุณด้วย tcp / ip แทนได้หรือไม่?
Ben Lessani - Sonassi

ปัญหาเดียวกันกับขนาดที่แย่ลงโดยใช้ tcp / ip (คิวการเขียนเพิ่มขึ้นเร็วขึ้น) ฉันมี nginx / unicorn / kernel ทั้งหมดตั้งค่าเหมือนกัน (เท่าที่ฉันสามารถบอก) ในเครื่องที่แตกต่างกันและเครื่องอื่น ๆ ที่ไม่ได้แสดงปัญหานี้ (ฉันสามารถสลับ DNS ระหว่างเครื่องทั้งสองเพื่อรับการทดสอบโหลดสดและมี DNS ใน 60 วินาที ttl)
Ben Lee

ปริมาณงานระหว่างเครื่องแต่ละเครื่องและเครื่อง db จะเท่ากันตอนนี้และความหน่วงแฝงระหว่างเครื่องใหม่และเครื่อง db นั้นมากกว่าเครื่องเก่าและ db ประมาณ 30% แต่เพิ่มขึ้น 30% ว่าหนึ่งในสิบของมิลลิวินาทีไม่ใช่ปัญหา
Ben Lee

2

คุณอาจลองมองหาที่ unix_dgram_qlenดูเอกสาร proc แม้ว่าสิ่งนี้อาจรวมปัญหาโดยการชี้เพิ่มเติมในคิว คุณจะต้องดู (netstat -x ... )


มีความคืบหน้าเกี่ยวกับเรื่องนี้หรือไม่?
jmw

1
ขอบคุณสำหรับความคิด แต่สิ่งนี้ไม่ได้สร้างความแตกต่าง
Ben Lee

0

ฉันแก้ไขโดยการเพิ่มหมายเลขงานค้างใน config / unicorn.rb ... ฉันเคยมีงานค้าง 64

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 64

และฉันได้รับข้อผิดพลาดนี้:

 2014/11/11 15:24:09 [error] 12113#0: *400 connect() to unix:/path/tmp/sockets/manager_rails.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: 192.168.101.39, server: , request: "GET /welcome HTTP/1.0", upstream: "http://unix:/path/tmp/sockets/manager_rails.sock:/welcome", host: "192.168.101.93:3000"

ตอนนี้ฉันเพิ่มเป็น 1024 และฉันไม่ได้รับข้อผิดพลาด:

 listen "/path/tmp/sockets/manager_rails.sock", backlog: 1024

0

TL; DR

  1. ตรวจสอบให้แน่ใจว่า Unicorn backlog มีขนาดใหญ่ (ใช้ซ็อกเก็ตเร็วกว่า TCP) listen("/var/www/unicorn.sock", backlog: 1024)
  2. ปรับการตั้งค่าประสิทธิภาพของ NGINXให้เหมาะสมworker_connections 10000;

การสนทนา

เรามีปัญหาเดียวกัน - แอพ Rails ที่ให้บริการโดยยูนิคอร์นหลังพร็อกซีย้อนกลับของ NGINX

เราได้รับบรรทัดเช่นนี้ในบันทึกข้อผิดพลาด Nginx:

2019/01/29 15:54:37 [error] 3999#3999: *846 connect() to unix:/../unicorn.sock failed (11: Resource temporarily unavailable) while connecting to upstream, client: xx.xx.xx.xx, request: "GET / HTTP/1.1"

การอ่านคำตอบอื่น ๆ ที่เราคิดด้วยว่ายูนิคอร์นอาจจะเป็นความผิดดังนั้นเราจึงเพิ่มมันเป็นงานในมือ แต่สิ่งนี้ไม่ได้แก้ปัญหา การตรวจสอบกระบวนการเซิร์ฟเวอร์นั้นเห็นได้ชัดว่ายูนิคอร์นไม่ได้รับการร้องขอให้ทำงานดังนั้น NGINX จึงดูเหมือนจะเป็นคอขวด

ที่ไหนมีการตั้งค่า NGINX การปรับแต่งในnginx.confนี้บทความการปรับแต่งประสิทธิภาพชี้ให้เห็นการตั้งค่าหลายอย่างที่อาจส่งผลกระทบวิธีการหลายขนานคำขอ NGINX สามารถประมวลผลโดยเฉพาะอย่างยิ่ง:

user www-data;
worker_processes auto;
pid /run/nginx.pid;
worker_rlimit_nofile 400000; # important

events {    
  worker_connections 10000; # important
  use epoll; # important
  multi_accept on; # important
}

http {
  sendfile on;
  tcp_nopush on;
  tcp_nodelay on;
  keepalive_timeout 65;
  types_hash_max_size 2048;
  keepalive_requests 100000; # important
  server_names_hash_bucket_size 256;
  include /etc/nginx/mime.types;
  default_type application/octet-stream;
  ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
  ssl_prefer_server_ciphers on;
  access_log /var/log/nginx/access.log;
  error_log /var/log/nginx/error.log;
  gzip on;
  gzip_disable "msie6";
  include /etc/nginx/conf.d/*.conf;
  include /etc/nginx/sites-enabled/*;
}

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