मेरे पास एक रेल (3.2) ऐप है जो क्लाउड प्लेटफ़ॉर्म पर nginx और यूनिकॉर्न पर चलता है। उबंटू 12.04 पर "बॉक्स" चल रहा है।nginx + यूनिकॉर्न (रेल 3 एप) पर लोड पर खराब गेटवे त्रुटियां
जब प्रणाली लोड के बारे में 70% या इसके बाद के संस्करण, पर है nginx अचानक (और उचित रूप में बेतरतीब ढंग से) शुरू होता है 502 खराब गेटवे त्रुटियों फेंक; जब भार कम होता है तो ऐसा कुछ नहीं होता है। मैंने विभिन्न संख्याओं के कोर (4, 6, 10 - मैं क्लाउड प्लेटफॉर्म पर "हार्डवेयर बदल सकता हूं" के साथ प्रयोग किया है), और स्थिति हमेशा एक जैसी होती है। (सीपीयू लोड सिस्टम लोड के समान है, यूजरलैंड 55% कहता है, शेष सिस्टम बहुत चुराया जाता है और चोरी हो जाता है, बहुत सारी मुफ्त मेमोरी, कोई स्वैपिंग नहीं।)
502 आमतौर पर बैचों में आते हैं लेकिन हमेशा नहीं।
(मैं कोर प्रति एक गेंडा कार्यकर्ता, और एक या दो nginx कार्यकर्ताओं चलाते हैं। जब 10 कोर पर चल नीचे कॉन्फ़िगरेशन के प्रासंगिक भागों देखें।)
मैं वास्तव में कारण ट्रैक करने के लिए पता नहीं कैसे इन त्रुटियों में से। मुझे संदेह है कि यूनिकॉर्न श्रमिकों के साथ ऐसा करने में कुछ भी नहीं हो सकता है (समय में?) लेकिन यह अजीब लगता है क्योंकि वे सीपीयू को संतृप्त नहीं लगते हैं और मुझे कोई कारण नहीं दिखता कि वे आईओ की प्रतीक्षा क्यों करेंगे (लेकिन मैं नहीं करता यह नहीं पता कि इसके बारे में कैसे सुनिश्चित किया जाए)।
क्या आप कृपया कारण ढूंढने के बारे में मेरी मदद कर सकते हैं?
यूनिकॉर्न config (unicorn.rb):
worker_processes 10
working_directory "/var/www/app/current"
listen "/var/www/app/current/tmp/sockets/unicorn.sock", :backlog => 64
listen 2007, :tcp_nopush => true
timeout 90
pid "/var/www/app/current/tmp/pids/unicorn.pid"
stderr_path "/var/www/app/shared/log/unicorn.stderr.log"
stdout_path "/var/www/app/shared/log/unicorn.stdout.log"
preload_app true
GC.respond_to?(:copy_on_write_friendly=) and
GC.copy_on_write_friendly = true
check_client_connection false
before_fork do |server, worker|
... I believe the stuff here is irrelevant ...
end
after_fork do |server, worker|
... I believe the stuff here is irrelevant ...
end
और ngnix config:
/etc/nginx/nginx.conf:
worker_processes 2;
worker_rlimit_nofile 2048;
user www-data www-admin;
pid /var/run/nginx.pid;
error_log /var/log/nginx/nginx.error.log info;
events {
worker_connections 2048;
accept_mutex on; # "on" if nginx worker_processes > 1
use epoll;
}
http {
include /etc/nginx/mime.types;
default_type application/octet-stream;
log_format main '$remote_addr - $remote_user [$time_local] "$request" '
'$status $body_bytes_sent "$http_referer" '
'"$http_user_agent" "$http_x_forwarded_for"';
access_log /var/log/nginx/access.log main;
# optimialization efforts
client_max_body_size 2m;
client_body_buffer_size 128k;
client_header_buffer_size 4k;
large_client_header_buffers 10 4k; # one for each core or one for each unicorn worker?
client_body_temp_path /tmp/nginx/client_body_temp;
include /etc/nginx/conf.d/*.conf;
}
/etc/nginx/conf.d/app.conf:
sendfile on;
tcp_nopush on;
tcp_nodelay off;
gzip on;
gzip_http_version 1.0;
gzip_proxied any;
gzip_min_length 500;
gzip_disable "MSIE [1-6]\.";
gzip_types text/plain text/css text/javascript application/x-javascript;
upstream app_server {
# fail_timeout=0 means we always retry an upstream even if it failed
# to return a good HTTP response (in case the Unicorn master nukes a
# single worker for timing out).
server unix:/var/www/app/current/tmp/sockets/unicorn.sock fail_timeout=0;
}
server {
listen 80 default deferred;
server_name _;
client_max_body_size 1G;
keepalive_timeout 5;
root /var/www/app/current/public;
location ~ "^/assets/.*" {
...
}
# Prefer to serve static files directly from nginx to avoid unnecessary
# data copies from the application server.
try_files $uri/index.html $uri.html $uri @app;
location @app {
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header Host $http_host;
proxy_redirect off;
proxy_pass http://app_server;
proxy_connect_timeout 90;
proxy_send_timeout 90;
proxy_read_timeout 90;
proxy_buffer_size 128k;
proxy_buffers 10 256k; # one per core or one per unicorn worker?
proxy_busy_buffers_size 256k;
proxy_temp_file_write_size 256k;
proxy_max_temp_file_size 512k;
proxy_temp_path /mnt/data/tmp/nginx/proxy_temp;
open_file_cache max=1000 inactive=20s;
open_file_cache_valid 30s;
open_file_cache_min_uses 2;
open_file_cache_errors on;
}
}
उत्कृष्ट! धन्यवाद। –
धन्यवाद फास्ट कैच! इस फिक्स को लागू किया .. अभी तक सत्यापित नहीं किया है कि क्या यह क्षणिक खराब गेटवे त्रुटियों में सुधार हुआ है या नहीं। – amolk