步骤1:使用 ping 和 mtr 测试到目标中国节点的延迟与丢包(示例命令:ping -c 50 目标IP;mtr -r -c 100 目标IP)。步骤2:在服务器上运行 top/htop、vmstat 采样 1 分钟,记录 CPU、内存、负载平均值。步骤3:用 iostat -x 1 10 和 sar -n DEV 1 10 检查磁盘与网卡 IO。步骤4:用 ss -s 和 netstat -an 查看 TCP 连接状态。把这些结果存为 baseline.txt,便于对比。
步骤1:在服务器安装 node_exporter(下载并运行:./node_exporter &)。步骤2:在 Prometheus 配置文件 prometheus.yml 中添加 targets: - "your_server:9100"。步骤3:运行 Grafana,导入 node_exporter 仪表盘以监控 CPU、磁盘、网络、TCP metrics。步骤4:设置 Alertmanager 告警阈值(如 95% CPU 持续 5 分钟、丢包 > 1%)。
步骤1:使用 tcptraceroute 或 tracepath 确认路径跃点延迟。步骤2:通过 MTR 长时间跟踪定位丢包发生的跃点。步骤3:联系带宽提供商(CN2 运营商)提供 BGP 看 glass,核对是否使用 CN2 GIA 路由并请求修复特定跃点。步骤4:在必要时申请更优的路由或更换到延迟更低的机房/出口。
创建文件 /etc/sysctl.d/99-cn2.conf,加入并执行 sysctl -p /etc/sysctl.d/99-cn2.conf。推荐参数示例:net.core.somaxconn=65535; net.core.netdev_max_backlog=5000; net.ipv4.tcp_fin_timeout=30; net.ipv4.tcp_tw_reuse=1; net.ipv4.tcp_max_syn_backlog=4096; net.ipv4.tcp_rmem=4096 87380 6291456; net.ipv4.tcp_wmem=4096 65536 6291456; net.ipv4.tcp_congestion_control=bbr(或 hybla 视场景)。保存并生效后用 sysctl -a | grep tcp_ 验证。
步骤1:用 ethtool -k eth0 查看 offload 设置,必要时开启/关闭 GRO/GSO/TX/TCP segmentation 以减少 CPU 或延迟问题(例如 ethtool -K eth0 gso off gso is risky, test first)。步骤2:调整 txqueuelen(ip link set dev eth0 txqueuelen 10000)。步骤3:设置 IRQ 亲和性:用 irqbalance 或手动 echo 给 /proc/irq/
步骤1:安装 iproute2。步骤2:使用 tc qdisc add dev eth0 root fq_codel 或 cake 来减少排队延迟。示例:tc qdisc replace dev eth0 root cake bandwidth 100mbit。步骤3:监控后调整 bandwidth、target 参数以匹配出口带宽。
Nginx 示例:worker_processes auto;worker_connections 4096;worker_rlimit_nofile 65536;keepalive_timeout 15;开启 gzip、HTTP/2、TLS 会话复用。操作步骤:编辑 /etc/nginx/nginx.conf,重载 nginx -s reload。对 PHP/应用层启用缓存(Redis/OPcache),减少请求响应时间。
步骤1:用 fio 基准测试磁盘:fio --name=seqrw --rw=read --bs=1M --size=1G --numjobs=1。步骤2:根据结果选择合适 IO 调度器(echo noop > /sys/block/sda/queue/scheduler 或 mq-deadline)。步骤3:对 MySQL 调整 innodb_buffer_pool_size(约 60-70% 内存)、慢查询日志开启,执行 EXPLAIN 优化慢查询。
步骤1:配置 Prometheus Alertmanager 邮件/钉钉/Slack 告警,并写 playbook(Ansible)自动重启服务或扩容实例。步骤2:设置健康检查与自动切换策略(使用 LVS/Keepalived 或云厂商的负载均衡)。步骤3:定期(每周/月)回归测试并更新 baseline 数据。
答:先从外部进行 mtr 到目标 IP(从多个测试点),若跃点中间出现丢包高且延迟爬升则为链路问题;若链路稳定但服务器内部延迟高,查看 top/htop、iostat、ss,若 CPU 或 IO 饱和即为服务器瓶颈。结合 Prometheus 历史数据可以快速定位。
答:BBR 能提高吞吐和降低队列延迟,但在某些网络路径上与对端设备不兼容可能出现奇怪表现。建议在测试环境先启用(sysctl net.ipv4.tcp_congestion_control=bbr),通过真实流量监测丢包与 RTT 变化,再逐步在生产放开。
答:建议参考:CPU 利用率持续 >85%(5 分钟)告警;磁盘 iowait >20%;网络丢包 >1%;平均负载 >CPU 核数的 2 倍;响应时间(95 分位)相比 baseline 上升 30%。这些阈值可根据业务特性微调。