Khi lưu lượng truy cập chạm trầnMọi thứ dường như vẫn ổn cho đến khi lưu lượng truy cập tăng đột biến. Đột nhiên, người dùng gặp lỗi 500 Internal Server Error, hoặc trang web của bạn ngừng phản hồi. Nếu kiểm tra log lỗi Nginx tại /var/log/nginx/error.log, bạn sẽ thấy cảnh báo sau:
2023/10/27 14:30:15 [alert] 1234#0: 1024 worker_connections are not enough, reopen logs
Máy chủ của bạn đã chạm giới hạn cứng. Theo mặc định, nhiều bản cài đặt Nginx giới hạn mỗi worker process ở mức 1024 kết nối. Dù con số này nghe có vẻ nhiều, nhưng thường là quá thấp đối với các ứng dụng hiện đại và API bận rộn.
Tại sao 1024 là không đủBạn có thể tính tổng dung lượng của máy chủ bằng công thức đơn giản: Max Connections = worker_processes * worker_connections. Tuy nhiên, có một lưu ý quan trọng nếu bạn sử dụng Nginx làm reverse proxy cho Node.js, PHP-FPM hoặc Python.
Trong thiết lập proxy, mỗi yêu cầu sử dụng tới hai kết nối. Một kết nối nối người dùng với Nginx, và kết nối thứ hai nối Nginx với dịch vụ backend của bạn. Điều này thực tế làm giảm một nửa khả năng xử lý 1024 kết nối, nghĩa là chỉ 512 người dùng có thể kết nối cùng lúc. Ngoài các cài đặt Nginx, nhân Linux cũng đặt giới hạn về "open files" (số tệp đang mở). Vì Linux coi mỗi network socket là một tệp, hệ điều hành của bạn có thể chặn Nginx mở thêm kết nối ngay cả khi bạn đã thay đổi tệp cấu hình.
Bước 1: Cập nhật cấu hình NginxBắt đầu bằng cách tăng giới hạn nội bộ. Mở tệp /etc/nginx/nginx.conf bằng trình chỉnh sửa văn bản bạn chọn:
sudo nano /etc/nginx/nginx.conf
Tìm khối events. Đối với một VPS tiêu chuẩn có RAM từ 2GB đến 4GB, 4096 hoặc 8192 là điểm khởi đầu an toàn và ổn định.
events {
worker_connections 4096;
# Cho phép mỗi worker chấp nhận tất cả các kết nối mới đang chờ cùng một lúc
multi_accept on;
}
Bước 2: Đồng bộ Worker với nhân CPUTrong cùng một tệp, hãy tìm chỉ thị worker_processes. Hãy đặt giá trị này thành auto. Điều này yêu cầu Nginx tạo ra một tiến trình cho mỗi nhân CPU có sẵn, giúp tối ưu hiệu quả hơn so với việc tự đoán một con số cụ thể.
worker_processes auto;
Bước 3: Tăng giới hạn File DescriptorĐây là nơi hầu hết mọi người gặp rắc rối. Nếu bạn đặt worker_connections thành 4096 nhưng hệ thống vẫn nghĩ 1024 là tối đa, Nginx sẽ tiếp tục bị lỗi. Bạn phải thông báo rõ ràng cho Nginx biết nó có thể xử lý bao nhiêu file descriptor. Thêm worker_rlimit_nofile ở ngay đầu tệp nginx.conf của bạn.
user www-data;
worker_processes auto;
pid /run/nginx.pid;
# Đặt giá trị này ít nhất gấp đôi worker_connections của bạn
worker_rlimit_nofile 16384;
events {
worker_connections 8192;
}
Bước 4: Điều chỉnh hệ thống LinuxĐôi khi chính hệ điều hành có giới hạn "nofile" nghiêm ngặt. Bạn có thể xem giới hạn hiện tại của shell bằng lệnh ulimit -n. Để thay đổi vĩnh viễn cho người dùng Nginx, hãy chỉnh sửa tệp giới hạn hệ thống:
sudo nano /etc/security/limits.conf
Thêm các dòng sau vào cuối tệp, thay thế www-data bằng nginx nếu đó là người dùng mà hệ thống của bạn sử dụng:
www-data soft nofile 16384
www-data hard nofile 16384
Bước 5: Áp dụng và xác minh bản sửa lỗiĐừng bao giờ khởi động lại Nginx mà không kiểm tra cú pháp trước. Một lỗi đánh máy nhỏ có thể làm toàn bộ trang web của bạn bị ngoại tuyến.
sudo nginx -t
Nếu quá trình kiểm tra thành công, hãy tải lại cấu hình. Điều này sẽ áp dụng các thay đổi mà không làm ngắt kết nối của những người dùng đang truy cập.
sudo systemctl reload nginx
Cách xác nhận thay đổi đã hoạt độngĐừng chỉ tin vào những gì hệ thống hiển thị. Hãy tìm ID tiến trình (PID) của một worker đang hoạt động:
ps aux | grep nginx
Sau đó, kiểm tra các giới hạn thực tế cho PID đó (thay thế 1234 bằng PID thực tế của bạn):
cat /proc/1234/limits | grep "Max open files"
Nếu kết quả hiển thị 16384, máy chủ của bạn đã sẵn sàng cho đợt lưu lượng truy cập tiếp theo.