Nginx worker_connections"thiết lập số lượng kết nối đồng thời tối đa có thể được mở bởi quy trình worker. Số này bao gồm tất cả các kết nối (ví dụ: kết nối với máy chủ proxy, trong số các kết nối khác), không chỉ kết nối với khách hàng. không thể vượt quá giới hạn hiện tại về số lượng tệp mở tối đa ". Tôi có một vài truy vấn xung quanh đây:

1. Giá trị tối ưu hoặc khuyến nghị cho việc này là gì?
2. Nhược điểm của việc sử dụng số lượng lớn kết nối công nhân là gì?

Hãy thực hiện cách tiếp cận thực dụng.

Tất cả những giới hạn này là những thứ được mã hóa cứng và được thiết kế trong thế kỷ qua khi phần cứng chậm và đắt tiền. Bây giờ chúng ta đang ở trong năm 2016, một máy nướng bánh mì trung bình có thể xử lý nhiều yêu cầu hơn các giá trị mặc định.

Các thiết lập mặc định thực sự nguy hiểm. Có hàng trăm người dùng trên một trang web là không có gì ấn tượng.

worker_ process

Một cài đặt liên quan, hãy giải thích nó trong khi chúng ta đang ở trong chủ đề.

nginx là bộ cân bằng tải:

• 1 công nhân để cân bằng tải HTTP.
• 1 công nhân trên mỗi lõi để cân bằng tải HTTPS.

nginx là máy chủ web:

Điều này là khó khăn.

Một số ứng dụng / khung / phần mềm trung gian (ví dụ: php-fpm) được chạy bên ngoài nginx. Trong trường hợp đó, 1 nginx worker là đủ vì thường là ứng dụng bên ngoài đang xử lý nặng và ăn tài nguyên.

Ngoài ra, một số ứng dụng / khung / phần mềm trung gian chỉ có thể xử lý một yêu cầu tại một thời điểm và nó đang phản tác dụng để quá tải chúng.

Nói chung, 1 công nhân luôn là một đặt cược an toàn.

Mặt khác, bạn có thể đặt một nhân viên cho mỗi lõi nếu bạn biết bạn đang làm gì. Tôi coi tuyến đường đó là một tối ưu hóa và tư vấn kiểm tra và đo điểm chuẩn phù hợp.

worker_connections

Tổng số lượng kết nối là worker_process * worker_connections. Một nửa trong chế độ cân bằng tải.

Bây giờ chúng ta đang đến phần máy nướng bánh mì. Có nhiều giới hạn hệ thống bị đánh giá thấp nghiêm trọng:

• ulimits là 1k tệp mở tối đa cho mỗi quá trình trên linux (mềm 1k, cứng 4k trên một số bản phân phối)
• giới hạn systemd là tương tự như ulimits.
• nginx mặc định là 512 kết nối cho mỗi công nhân.
• Có thể có nhiều hơn: SELinux, sysctl, giám sát (mỗi phiên bản + phiên bản hơi khác nhau)

1k worker_connections

Mặc định an toàn là đặt 1k ở mọi nơi.

Nó đủ cao để có nhiều hơn hầu hết các trang web nội bộ và chưa biết sẽ gặp phải. Nó đủ thấp để không đạt bất kỳ giới hạn hệ thống nào khác.

10k worker_connections

Rất phổ biến khi có hàng ngàn khách hàng, đặc biệt là đối với một trang web công cộng. Tôi đã ngừng đếm số lượng trang web tôi thấy đã ngừng hoạt động vì giá trị mặc định thấp.

Mức tối thiểu chấp nhận được cho sản xuất là 10k. Giới hạn hệ thống liên quan phải được tăng lên để cho phép nó.

Không có thứ gọi là giới hạn quá cao (giới hạn đơn giản là không có hiệu lực nếu không có người dùng). Tuy nhiên, giới hạn quá thấp là một điều rất thực tế dẫn đến việc người dùng bị từ chối và một trang web chết.

Hơn 10k

10k là tốt và dễ dàng.

Chúng tôi có thể đặt giới hạn 1000kk tùy ý (rốt cuộc chỉ là giới hạn) nhưng điều đó không có ý nghĩa thực tế nhiều, chúng tôi không bao giờ có lưu lượng truy cập đó và dù sao cũng không thể thực hiện được.

Hãy giữ 10k như một thiết lập hợp lý. Các dịch vụ sẽ (và thực sự có thể làm) nhiều hơn sẽ yêu cầu điều chỉnh và điểm chuẩn đặc biệt.

Kịch bản đặc biệt: Sử dụng nâng cao

Đôi khi, chúng tôi biết rằng máy chủ không có nhiều tài nguyên và chúng tôi mong đợi các đột biến mà chúng tôi không thể làm được gì nhiều. Chúng tôi thà từ chối người dùng hơn là thử. Trong trường hợp đó, đặt giới hạn kết nối hợp lý và định cấu hình các thông báo lỗi và xử lý.

Đôi khi, các máy chủ phụ trợ đang hoạt động tốt và tốt nhưng chỉ lên đến một số tải , bất cứ điều gì nhiều hơn và mọi thứ đi về phía nam một cách nhanh chóng. Chúng tôi thà làm chậm hơn là máy chủ gặp sự cố. Trong trường hợp đó, hãy định cấu hình xếp hàng với các giới hạn nghiêm ngặt, hãy để nginx đệm tất cả nhiệt trong khi các yêu cầu đang được rút hết ở tốc độ giới hạn.

ulimit -a sẽ cho bạn biết có bao nhiêu tệp đang mở mà hệ thống của bạn cho phép một quá trình sử dụng.

Ngoài ra, net.ipv4.ip_local_port_rangeđặt tổng phạm vi ổ cắm để bật cho mỗi IP.

Vì vậy, bạn worker_connectionskhông thể nhiều hơn bất kỳ ai trong số đó, hoặc các kết nối máy khách của bạn sẽ xếp hàng cho đến khi net.core.netdev_max_backlog- tổng kích thước của hàng đợi TCP.

Hãy nhớ rằng nếu bạn đang sử dụng nginx làm proxy ngược, thì sử dụng hai ổ cắm cho mỗi kết nối. Bạn có thể muốn chơi một chút với net.ipv4.tcp_fin_timeoutvà thời gian chờ liên quan đến tcp kernel khác để cố gắng chuyển trạng thái của socket một cách nhanh chóng. Một lưu ý khác là mỗi ổ cắm phân bổ bộ nhớ của ngăn xếp bộ nhớ TCP, bạn cũng có thể đặt một số giới hạn của ngăn xếp bộ nhớ TCP bằng cách sử dụng sysctl, bạn có thể đặt thêm áp lực vào RAM miễn là bạn có CPU và đủ trình xử lý tệp.

FYI có thể cung cấp đủ tài nguyên máy tính, để có một máy chủ với khoảng 32GB ram và một số giao diện mạng ảo để xử lý các kết nối đồng thời 1MM với một số điều chỉnh kernel bằng sysctl. Trong các thử nghiệm của tôi khi xử lý hơn 1MM và gửi tải trọng khoảng 700Bytes, máy chủ đã mất khoảng 10 giây để cập nhật khoảng 1,2MM máy khách đồng thời. Tiếp theo là tăng băng thông mạng bằng cách liên kết thêm một số NIC và bỏ qua các ảnh ảo. Có thể đạt được giả gần giao tiếp thời gian thực với hơn 1,2MM khách hàng, với trọng tải, băng thông và thời gian hợp lý để cập nhật tất cả các máy khách.

Chúc mừng điều chỉnh!

Kích thước phù hợp có thể được phát hiện thông qua thử nghiệm, vì nó có thể thay đổi dựa trên loại lưu lượng mà Nginx đang xử lý.

Về mặt lý thuyết, nginx có thể xử lý: max client = worker_ Processes * worker_connections (* = Multiply) và worker_ Processes = số lượng bộ xử lý

Để tìm hiểu bộ xử lý, sử dụng: bộ xử lý grep / Proc / cpuinfo | wc -l

Đặt giới hạn thấp hơn có thể hữu ích khi bạn có thể bị hạn chế tài nguyên. Ví dụ, một số kết nối, kết nối duy trì (không chỉ với máy khách, mà cả máy chủ ngược dòng ), đang lãng phí hiệu quả tài nguyên của bạn (ngay cả khi nginx rất hiệu quả), và không bắt buộc hoạt động chính xác của máy chủ đa năng, nghĩa là chúng có thể được loại bỏ một cách an toàn để cung cấp thêm tài nguyên cho phần còn lại của hoạt động.

Do đó, có giới hạn tài nguyên thấp hơn sẽ chỉ ra cho nginx rằng bạn có thể thiếu tài nguyên vật lý và những tài nguyên có sẵn nên được phân bổ cho các kết nối mới, thay vì phục vụ các kết nối không hoạt động với chi phí kết nối mới gặp sự cố khi thiết lập Phục vụ những nhu cầu cấp thiết hơn.

Giá trị đề nghị là gì? Đó là mặc định.

Mặc định tất cả đều được ghi lại trong tài liệu:

Mặc định: worker_connections 512;

Và có thể được khẳng định ở cấp mã nguồn tạievent/ngx_event.c , quá

13 # xác định DEFAULT_CONNECT 512

Câu trả lời của Marcel thực sự cần được nâng cao! Nếu ulimits được đặt thành giá trị mặc định khoảng 1k, max_connections nên được đặt xung quanh cùng một giá trị nếu không sẽ không có lợi khi đặt max_connections thành 10k.

Bạn sẽ nhận được yêu cầu xếp hàng và ổ cắm được đóng trên nginx nếu "worker_connections của bạn không thể nhiều hơn bất kỳ ai trong số đó, hoặc các kết nối máy khách của bạn sẽ xếp hàng cho đến khi net.core.netdev_max_backlog - tổng kích thước của hàng đợi TCP."

Một quá trình duy nhất có thể mở như có thể kết nối khi các lỗ hổng cho phép. num_workers * max_connections là công thức nhưng bên ngoài các kết nối tối đa của loadbalancer / proxy và các lỗ hổng cần phải được tính đến cho các giá trị hợp lý. Đặt max_connection thành một giá trị thực sự cao có thể gây tác dụng ngược vì các lỗ hổng sẽ là một yếu tố hạn chế.