要在短时间内识别瓶颈,先从三层面同时入手:CPU、内存/缓存与存储IO。推荐先运行fio做基线IO测试,使用iostat -x 1和vmstat 1观察等待队列、%iowait与CPU利用率;再用blktrace或perf做深度分析。
1)运行随机读写和顺序读写的fio基准:设置合适的block size(4K、64K、1M)和并发数(iodepth/numjobs)。2)查看iostat的await、svctm、util。3)用iotop或系统级监控寻找高IO进程。4)若是虚拟化环境,检查宿主与存储网络链路(如iSCSI、NFS、Ceph)的延迟。
关注平均延迟、99百分位延迟、吞吐(MB/s)与IOPS。日本地区多使用云厂商(如AWS东京)或本地DC,网络延迟和跨可用区IO会明显影响表现,应把区域拓扑纳入诊断。
选择存储时,优先考虑NVMe SSD或NVMe over Fabrics以降低延迟。对于高并发随机读写,单盘IOPS更重要;对于大吞吐任务(备份、ETL),顺序吞吐更关键。企业级阵列可选RAID10以换取性能与可靠性平衡。
1)RAID10在随机IO场景下通常优于RAID5/6。2)如果使用RAID卡,关闭或谨慎配置写缓存(根据电池/非易失性缓存情况)。3)针对SSD启用TRIM/discard(在支持的场景下),并关注固件版本和厂商调优参数。
采用分层存储(热数据放NVMe,冷数据放HDD或对象存储)并配合本地或分布式缓存(Redis、memcached或本地SSD缓存)能显著提升响应。对于数据库负载,使用专用存储或本地直连NVMe能减少网络抖动影响。
在Linux上常见调优点包含I/O调度器选择、文件系统挂载选项、块设备队列深度与网络层面参数。根据具体工作负载选择合适配置可以显著降低延迟。
1)I/O调度器:对于NVMe或SSD建议使用none或mq-deadline,避免cfq在高并发下的上下文开销。2)队列深度(/sys/block/
运行:echo mq-deadline > /sys/block/sdX/queue/scheduler;或调整队列深度:echo 256 > /sys/block/nvme0n1/queue/nr_requests。使用fstab挂载时添加noatime, nodiratime等减少写操作。
操作系统层面需同步优化内核参数、网络栈与内存缓存。文件系统选择和分区对性能影响大,针对不同应用做专门调整可获得可观收益。
1)调整内核参数:vm.swappiness降低到10或更低以减少换页,vm.vfs_cache_pressure调低保留目录/inode缓存。2)网络参数:若为存储网络(iSCSI、Ceph),优化tcp_rmem/tcp_wmem、net.core.rmem_max等,启用多队列(RSS/XPS)以利用多核。3)HugePages对于某些数据库(Oracle、PostgreSQL)能降低TLBmiss并提高吞吐。
数据库数据分区建议单独挂载并设置适合的inode大小与预留空间。XFS适合大文件与高并发场景,ext4更通用。启用并行写入(如XFS的logbsize调整)并定期运行文件系统维护(fstrim、xfs_fsr)。
常用工具包括fio、iostat、iotop、blktrace、perf、sar、collectl、Prometheus + node_exporter + Grafana。使用这些工具能建立完整的性能回归测试与实时告警。
1)基线测试(fio)—记录不同block size和iodepth下的延迟/IOPS/吞吐。2)持续监控(Prometheus + Grafana)—设置延迟和IOPS的SLO告警。3)回归测试—每次固件/驱动/内核升级后重跑基准并比对。
在日本部署要注意数据中心的可用区划分、跨区复制带来的延迟,以及法规与运维窗口(例如定期停电或维护时间窗)。若使用云服务(如AWS Tokyo、Azure Japan),测试不同可用区与AZ内网络吞吐差异,避免跨可用区频繁同步导致高延迟。