Tối ưu hóa Network cho Replication Database

Trong quá trình vận hành các hệ thống database PostgreSQL kích thước lớn, đặc biệt những hệ thống sinh WAL với tốc độ cao, tôi cũng gặp qua các tình huống replication lag tăng bất thường dù vấn đề chưa phải do server, không bị bottleneck I/O và không có checkpoint burst. Lúc đó, phần lớn mọi người thường soi vào disk hoặc config database, nhưng thực tế có một tầng ít được chú ý hơn là Network.

Replication trong PostgreSQL về bản chất là một luồng WAL liên tục. Chỉ cần đường truyền gặp bottleneck, bị limit hoặc có điểm nghẽn trong pipeline, toàn bộ quá trình sẽ chậm lại. Vì vậy việc nhận biết network có phải là nguyên nhân và tối ưu đúng chỗ sẽ giúp giảm lag đáng kể.

Dưới đây là vài điểm quan trọng tôi đúc kết từ các case thực tế liên quan đến replication lag do network và cách tối ưu để pipeline WAL vận hành ổn định hơn.

Khi nào Network là nguyên nhân gây Replication Lag

Khi hệ thống tạo ra hàng chục đến hàng trăm MB WAL mỗi giây, việc truyền WAL qua network trở thành một phần quan trọng. Trước khi tối ưu, cần kiểm tra network có thực sự là bottleneck hay không.

Kiểm tra trạng thái replication:

SELECT application_name,
       state,
       sent_lsn,
       write_lsn,
       flush_lsn,
       replay_lsn,
       sent_lsn - write_lsn AS send_delay,
       write_lsn - flush_lsn AS write_delay,
       flush_lsn - replay_lsn AS replay_delay
FROM pg_stat_replication;

Nếu send_delay tăng còn write_delay và replay_delay nhỏ thì bottleneck nằm ở quá trình gửi WAL sang replica.

Kiểm tra NIC:

ip -s link show eth0
ethtool -S eth0

Nếu xuất hiện dropped packets, rx_no_buffer hoặc tx_queue_full thì network đang nghẽn.

Nhiều bạn mặc định nghĩ replication lag là do I/O hoặc checkpoint. Nhưng nếu sent_lsn gửi không kịp thì đó là vấn đề network chứ không phải lỗi WAL writer.

Tối ưu TCP Buffer Size

TCP buffer là nơi kernel giữ dữ liệu WAL trước khi gửi ra network. Với hệ thống WAL heavy, buffer mặc định có thể không đủ để chịu các đợt burst.

Linux có auto tuning, nhưng max limit nếu đặt thấp sẽ giới hạn throughput thực tế khi WAL lên cao.

Đây là khuyến nghị thực tế mọi người có thể tham khảo:

NIC	tcp rmem wmem max
1Gbps	8MB đến 16MB
10Gbps	32MB đến 64MB
25Gbps trở lên	64MB đến 128MB

Ghi chú: một số tài liệu mọi người có thấy đưa đến 256MB. Điều này hợp với WAN latency lớn nhưng trong LAN hoặc datacenter dễ gây tăng latency vì buffer quá sâu.

Cấu hình:

net.core.rmem_max = 67108864
net.core.wmem_max = 67108864

net.ipv4.tcp_rmem = 4096 87380 67108864
net.ipv4.tcp_wmem = 4096 65536 67108864

Áp dụng:

sysctl -p

TCP Congestion Control

Cubic phù hợp cho LAN hoặc datacenter có latency thấp. BBR phù hợp với replication chạy qua WAN hoặc cross datacenter.

Kiểm tra:

sysctl net.ipv4.tcp_congestion_control

Đổi sang BBR khi cần:

net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr

BBRv1 trên một số distro cloud chưa tối ưu bằng BBRv2. Trong cùng datacenter latency thấp thì nên giữ Cubic.

Tối ưu NIC: RSS, IRQ Affinity, GRO GSO TSO

RSS

Kiểm tra RSS:

ethtool -l eth0
ethtool -x eth0

RSS giúp phân phối packet vào nhiều RX queue gắn vào nhiều core, tránh nghẽn tại một core.

Nhiều hệ thống dùng NIC 10Gbps nhưng do IRQ dồn vào CPU0 nên throughput thực tế thấp hơn rất nhiều.

IRQ Affinity

Kiểm tra:

cat /proc/interrupts | grep eth0

Nếu toàn bộ interrupt của NIC chạy trên một core thì throughput sẽ giảm mạnh. Cần trải IRQ đều hơn.

GRO, GSO và TSO

ethtool -K eth0 gro on
ethtool -K eth0 gso on
ethtool -K eth0 tso on

Những tính năng này giảm chi phí xử lý packet và giúp streaming WAL ổn định hơn.

Một vài môi trường low latency đặc thù có thể tắt TSO GSO, nhưng trong đa số workload replication WAL thì bật lên vẫn tối ưu.

LRO

Không bật mặc định:

ethtool -K eth0 lro off

LRO có thể gây reorder packet khi đi qua firewall hoặc overlay.

Tối ưu MTU

MTU 1500 tạo ra nhiều packet nhỏ. Nếu path hỗ trợ, nên dùng Jumbo Frame.

Kiểm tra path MTU:

ping -M do -s 8972 replica-host

Nếu thành công, cấu hình:

ip link set dev eth0 mtu 9000

Hầu hết cloud dùng overlay như VXLAN hoặc Geneve nên MTU hiệu dụng thấp hơn MTU danh nghĩa. Test path là bắt buộc.

Các tham số PostgreSQL liên quan WAL

Một vài tham số ảnh hưởng trực tiếp đến pipeline WAL nên được tối ưu cùng với network.

Cấu hình gợi ý:

wal_compression = on
max_wal_senders = 16
wal_keep_size = 4GB
wal_sender_timeout = 0
wal_receiver_timeout = 0
wal_buffers = 64MB
max_replication_slots = 16

wal_buffers lớn hơn giúp Postgres xử lý WAL burst tốt hơn và đẩy WAL ra network đều hơn.

Kiểm tra và benchmark

Đo throughput network:

iperf3 -c replica-host -t 30 -P 4

Đo lượng WAL:

SELECT pg_current_wal_lsn();

Benchmark tổng quan:

pgbench -c 64 -j 64 -T 120

So sánh trước và sau để xác định tuning có hiệu quả hay không.

Kết luận

Network stack là một layer rất dễ bị bỏ qua khi phân tích replication lag. Khi hệ thống sinh WAL liên tục với tốc độ cao, bottleneck nhiều khi không nằm ở disk hoặc CPU mà nằm ở TCP buffer, congestion control, IRQ, hoặc MTU.

Các nhóm tối ưu quan trọng: