Cài đặt kernel cho một số lượng lớn kết nối mở

Đo lường trước

ss -s
cat /proc/sys/fs/file-nr
nstat -az TcpExtListenOverflows TcpExtListenDrops

ListenOverflows tăng nghĩa là hàng đợi chấp nhận đã đầy và kernel đang loại bỏ các handshake đã hoàn thành. Đó là một vấn đề cụ thể với một giải pháp cụ thể. Hầu hết các triệu chứng khác không thể giải quyết được bằng sysctl, và việc tinh chỉnh một máy không bị áp lực chỉ đẩy sự cố cuối cùng đến một nơi khó tìm hơn.

Các thiết lập đáng giá

# /etc/sysctl.d/90-connections.conf
fs.file-max = 2097152
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 32768
net.ipv4.tcp_max_syn_backlog = 65535
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_mtu_probing = 1
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

sysctl --system
sysctl net.ipv4.tcp_congestion_control

Công dụng của từng thiết lập:

• somaxconn giới hạn backlog nghe, và ứng dụng của bạn vẫn phải yêu cầu nó. Trong nginx, đó là listen ... backlog=65535; trong hầu hết các ngôn ngữ, nó là đối số thứ hai của listen().
• ip_local_port_range quan trọng ở phía máy khách. Một proxy mở các kết nối đi đến một đích sẽ cạn kiệt cổng tạm thời ở khoảng hai mươi tám nghìn với dải mặc định.
• tcp_tw_reuse cho phép kernel tái sử dụng các socket TIMEWAIT cho các kết nối đi mới. An toàn. Người anh em của nó là `tcptw_recycle` đã bị xóa khỏi Linux từ phiên bản 4.12, và bất kỳ hướng dẫn nào vẫn khuyến nghị nó được viết trước năm 2017.
• fq với bbr là một cải thiện thực sự trên các đường truyền dài hoặc có tổn thất, và không thay đổi gì trên các đường ngắn và sạch. Cả hai đều có trong kernel tiêu chuẩn.

Theo dõi kết nối

Tường lửa có trạng thái cấp cho mỗi kết nối một mục conntrack, và bảng có một trần. Chạm trần sẽ làm rơi gói và ghi nf_conntrack: table full vào nhật ký kernel.

sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_count

Nâng trần nếu bạn có bộ nhớ — mỗi mục tốn vài trăm byte:

net.netfilter.nf_conntrack_max = 1048576

Nơi khối lượng công việc là một dịch vụ công cộng không trạng thái, câu trả lời tốt hơn là không theo dõi nó:

table inet raw {
  chain prerouting {
    type filter hook prerouting priority raw;
    tcp dport 443 notrack
  }
}

Các giới hạn mà systemd bỏ qua

/etc/security/limits.conf áp dụng cho các lần đăng nhập qua PAM. Nó không có ảnh hưởng gì đến một dịch vụ khởi động bởi systemd, đó là lý do tại sao việc tăng nofile ở đó và khởi động lại nginx không thay đổi gì. Đặt nó trên unit:

mkdir -p /etc/systemd/system/nginx.service.d
cat > /etc/systemd/system/nginx.service.d/limits.conf <<EOF
[Service]
LimitNOFILE=1048576
EOF
systemctl daemon-reload
systemctl restart nginx

Xác minh với dịch vụ đang chạy thay vì tệp bạn vừa viết:

systemctl show nginx -p LimitNOFILE

Ba điều không nên làm

• Đừng dán một tệp sysctl năm mươi dòng từ một diễn đàn. Một nửa trong số đó nhắm vào một kernel đã không được phát hành trong một thập kỷ, và một dòng sẽ âm thầm phá vỡ khám phá MTU đường đi.
• Đừng tăng tcp_rmem và tcp_wmem mà không có một đường dài và dày để biện minh. Trên một đường một mili giây, bộ đệm lớn hơn mua độ trễ và áp lực bộ nhớ.
• Đừng vô hiệu hóa tcp_timestamps. Bạn mất ước lượng khứ hồi và PAWS, và có được một tin đồn về hiệu suất.

Đo lại sau mỗi thay đổi, mỗi lần một thay đổi, và giữ tệp trong kiểm soát phiên bản để người tiếp theo có thể thấy bạn đã làm gì và tại sao.