Quick Start: Cấu hình thực chiến cho Server chịu tải
Server phản hồi chậm hoặc rớt kết nối khi traffic tăng đột ngột? Dưới đây là bộ thông số sysctl.conf mình thường dùng để xử lý triệt để vấn đề này. Cấu hình này đã giúp hệ thống API của mình duy trì ổn định khi lượng CCU (Concurrent Users) tăng từ 1.000 lên 15.000 trong các đợt flash sale.
Đầu tiên, hãy mở file cấu hình hệ thống:
sudo nano /etc/sysctl.confDán đoạn cấu hình tối ưu sau vào cuối file:
# Mở rộng dải port để tránh cạn kiệt port tạm thời
net.ipv4.ip_local_port_range = 10000 65535
# Tái sử dụng socket TIME_WAIT nhanh hơn
net.ipv4.tcp_tw_reuse = 1
# Tăng hàng đợi cho các kết nối đang bắt tay (SYN)
net.ipv4.tcp_max_syn_backlog = 8192
# Tăng giới hạn hàng đợi cho các kết nối đã thiết lập
net.core.somaxconn = 8192
# Mở rộng buffer size lên 16MB cho đường truyền tốc độ cao
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# Kích hoạt thuật toán BBR để giảm nghẽn và tăng throughput
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbrĐể các thay đổi có hiệu lực ngay mà không cần khởi động lại máy chủ, hãy chạy lệnh:
sudo sysctl -pVì sao cấu hình mặc định là “kẻ thù” của High-Traffic?
Các bản phân phối như Ubuntu hay CentOS được thiết kế để chạy tốt trên đa số phần cứng. Tuy nhiên, thông số mặc định thường quá dè dặt. Khi bạn chạy Nginx, Redis hoặc Node.js ở cường độ cao, các giới hạn này sẽ biến thành nút thắt cổ chai.
Thực tế cho thấy, trạng thái TIME_WAIT là nguyên nhân phổ biến nhất gây treo server. Khi một kết nối đóng lại, Linux giữ socket đó trong 60 giây để đảm bảo các gói tin đi lạc được xử lý hết. Với 1.000 request/giây, bạn sẽ sớm cạn sạch port khả dụng, khiến server từ chối mọi kết nối mới dù CPU vẫn đang “rảnh rỗi”.
Hàng đợi Backlog và hiện tượng Drop gói tin
Mỗi khi client gửi gói tin SYN, nó sẽ xếp hàng chờ tại tcp_max_syn_backlog. Nếu hàng đợi này chỉ có 128 (mặc định), nó sẽ đầy trong vài mili giây khi bị tấn công hoặc traffic tăng vọt. Kết quả là người dùng sẽ thấy lỗi “Connection Refused” hoặc trang web quay vòng vô tận.
Phân tích các thông số then chốt
1. Ephemeral Ports: Nới rộng không gian kết nối
Mặc định Linux chỉ dành khoảng 28.000 port cho các kết nối ra. Nếu server của bạn là Reverse Proxy kết nối tới nhiều dịch vụ backend, con số này là quá ít. Việc mở rộng dải port từ 10.000 đến 65.535 giúp hệ thống xử lý được nhiều luồng dữ liệu song song hơn.
2. Tận dụng tcp_tw_reuse
Thay vì để socket “ngủ đông” trong 60 giây, tcp_tw_reuse cho phép kernel sử dụng lại các socket ở trạng thái TIME_WAIT cho kết nối mới. Đây là giải pháp an toàn hơn nhiều so với tcp_tw_recycle (vốn đã bị loại bỏ ở các kernel mới vì gây lỗi với NAT).
3. Tối ưu Buffer để khai thác 1Gbps+
Các giá trị rmem và wmem mặc định thường quá nhỏ, không đủ để lấp đầy băng thông của các card mạng hiện đại. Khi tăng buffer lên 16MB, TCP Window Scaling có đủ không gian để tự động điều chỉnh, giúp tốc độ truyền tải dữ liệu lớn nhanh hơn rõ rệt.
BBR: “Vũ khí hạng nặng” từ Google
BBR (Bottleneck Bandwidth and Round-trip propagation time) thay đổi hoàn toàn cách quản lý tắc nghẽn. Thay vì đợi mất gói tin mới giảm tốc độ, BBR chủ động ước tính băng thông để duy trì tốc độ cao nhất có thể.
Trong các thử nghiệm thực tế trên đường truyền quốc tế có độ trễ cao, BBR giúp tăng throughput lên tới 40% và giảm đáng kể hiện tượng giật lag. Bạn có thể kiểm tra thuật toán đang dùng bằng lệnh:
sysctl net.ipv4.tcp_congestion_controlNếu thấy bbr, hệ thống của bạn đã sẵn sàng cho những đợt traffic lớn nhất.
Lưu ý quan trọng khi vận hành
- Cân đối RAM: Mỗi socket chiếm một lượng bộ nhớ đệm nhất định. Nếu server chỉ có 1GB RAM, đừng set buffer lên 64MB vì bạn sẽ gặp lỗi Out of Memory (OOM) rất nhanh.
- Giám sát hàng đợi: Sử dụng lệnh
ss -plntthường xuyên. Nếu cộtSend-Qvượt quá giá trịsomaxconn, đó là lúc bạn cần nâng cấp cấu hình hoặc mở rộng cụm server. - Kiểm tra TIME_WAIT: Theo dõi số lượng kết nối đang treo bằng lệnh:
ss -ant | awk '{print $1}' | sort | uniq -c - Firewall: Đảm bảo
net.netfilter.nf_conntrack_maxđủ lớn (ví dụ 262144) để Firewall không drop nhầm các kết nối hợp lệ do đầy bảng theo dõi.
Tối ưu hóa TCP Stack là một quá trình tinh chỉnh liên tục. Không có một bộ thông số nào là hoàn hảo cho mọi ứng dụng. Hãy bắt đầu với các giá trị mình gợi ý, sau đó theo dõi dashboard giám sát để tìm ra điểm cân bằng tối ưu cho hệ thống của bạn.
