边缘节点时序写入的吞吐瓶颈，多数情况不在CPU或网络带宽，而是磁盘IO；解决顺序是先改写入策略，再谈换硬件，顺序反了容易白花钱。
边缘节点磁盘IO限制时序写入吞吐怎么办先看三点定位瓶颈
时序数据写入有个特点：高频、小包、持续不断，边缘节点的设备每几秒上报一次数据，单次可能只有几十字节，但对磁盘来说每次都是一次真实的写操作，很多运维同事习惯先看CPU、再看网络，绕了一圈回来，才发现iostat里那块盘已经忙得抬不起头。
定位瓶颈,按下面三步往下走，基本能锁定问题。
第一步：用iostat看磁盘是否“忙到死”
在边缘节点上执行：
iostat -x 1
重点看两列：%util和await，如果%util长期在80%以上，await超过30毫秒，磁盘队列已经堆积，多数情况下，这代表IO调度已经跟不上写入请求。
但注意,%util高不等于磁盘差，SSD在多队列环境下%util可能显示很高，实际延迟依然低，所以要结合第二步。
第二步：用pidstat确认是谁在写
pidstat -d 1
能看到具体进程的读写速率和IO等待时间,时序数据库进程、WAL写进程、日志采集器，这三类通常是消耗IO的大户，如果一个采集器在疯狂刷盘，那问题不在盘本身，在业务写入频率。
第三步：检查fsync频率
时序数据库为了提数据可靠性,默认会频繁调用fsync，每一次fsync都是一次“把所有脏数据强制落地”的动作，机械盘和普通SSD在这一步性能会急剧下降，可以用strace -c抓一下系统调用占比，如果fsync占比异常高，说明写入策略需要调整，这和磁盘本身好坏无关。
行业共识认为,衡量时序写入性能不能只看顺序吞吐，随机写入IOPS和fsync延迟才是真正的硬指标。
本地磁盘与云盘边缘节点对比：瓶颈不在“盘”而在策略
边缘节点部署方式五花八门,有的人用物理机本地盘，有的人跑在云上挂云盘，同样是磁盘IO受限，两边的成因和处理逻辑完全不同。
本地磁盘边缘节点对比：SATA SSD掉速问题
本地盘部署最常见的是SATA SSD，这类盘在持续小文件写入下，容易出现“写放大”效应，一块标称500MB/s顺序写入的SATA SSD，跑时序数据持续写入时，速度跌到50MB/s以下并不意外，业内专家指出，SSD的垃圾回收和写入放大系数，往往比主控芯片的标称性能更能决定实际吞吐。
本地盘的优势是延迟低、路径短，劣势是容量有限，性能波动受盘体健康状态影响明显。
云盘边缘节点对比：网络IO不稳定更隐蔽
云盘的物理存储介质远程挂载,每一次写入都要走网络，在峰值时段，云盘的延迟抖动比较大，用户侧看到的表象是写入偶尔卡顿，如果你的边缘节点是云服务器，写入吞吐忽高忽低，首先怀疑云盘的突发性能配额，而不是远端存储本身。
| 对比维度 | 本地NVMe盘 | 本地SATA SSD | 云盘 |
|---|---|---|---|
| 典型随机写延迟 | 微秒级 | 毫秒级 | 受网络影响大 |
| 吞吐稳定性 | 稳定 | 长时间写入会掉速 | 高峰有明显波动 |
| 故障恢复 | 依赖硬件冗余 | 依赖硬件冗余 | 依赖云平台底层复制 |
| 部署成本 | 一次性硬件成本 | 一次性硬件成本 | 按容量和IOPS付费 |
云盘的计费模式按IOPS或吞吐量累加,长期跑高吞吐时序数据，成本不低，很多边缘节点项目在规划阶段没算这笔账，上线后才发现月租费用涨得厉害。
边缘节点存储选型方案：按数据温度分三层配置
绕过“一块大盘装所有”的思路，把存储按数据温度拆开，是解决IO瓶颈最实在的办法。
热数据区：内存或持久化内存
刚采集进来的时序数据,写入频率最高，这个层级不适合磁盘直接承载，应该放内存或持久化内存，开源时序数据库普遍提供内存缓存机制，先把高频写入放进内存，批量落盘，配置项一般叫cache或buffer，按内存余量调大一些。
温数据区：NVMe SSD扛写入
内存下刷的数据落到这一层,选盘时不要只看顺序读速度，要关注4K随机写性能和持续写入不掉速，边缘节点规模不大时，一块中等容量的NVMe盘足够扛住单节点的时序写入峰值。
挂载参数建议：
mount -o noatime,nodiratime /dev/nvme0n1 /data
noatime减少文件访问时间戳的更新，能省掉不少零碎写入。
冷数据区：机械盘或云存储归档
超过一定时间窗口的时序数据,写入频率大幅下降，这部分数据往机械盘或低成本云存储迁移，不需要高性能磁盘再扛着，常用做法是用存储分级策略，根据数据时间戳自动迁移，冷数据盘只承担顺序写的压力，负担很小。
边缘节点数据写入性能优化：四步把吞吐拉回来
硬件调整完了,写入策略不改，照样还会堵，边缘节点数据写入性能优化要动手改的，主要是以下四个方向。
第一步：批量写入替代单条写入
时序数据按单点写入,对磁盘是最不友好的模式，把多条记录攒成一个批次再落盘，磁盘每秒要处理的IO次数能降一个数量级，开源时序数据库基本都有写入批量参数，比如每次攒够1000点或间隔1秒刷一次，效果立竿见影。
第二步：WAL独立盘
预写日志（WAL）是时序数据库写入路径上的必经环节，WAL的写入非常频繁，且必须保证提交顺序，如果WAL和数据文件共用一块盘，两个高压力写入互相争抢，吞吐自然上不去，有条件就把WAL放到单独的SSD上，或者给WAL划分独立分区。
第三步：磁盘IO调度器切换
Linux默认的IO调度器在多类混合负载下表现中庸,边缘节点专用的数据盘，建议改成deadline或none，减少写请求的重排延迟。
echo deadline > /sys/block/sda/queue/scheduler
持久化写入/etc/udev/rules.d/规则文件，重启后不失效。
第四步：写入限流削峰
边缘节点采集端经常有突发上报,比如设备整点集中传数据，突发流量反映到磁盘就是瞬间请求堆积，用读写速率上限控制工具或者中间队列削平峰值流量，让磁盘持续处于中高负载但不过载，整体吞吐反而更高。
磁盘IO是边缘节点时序写入绕不过去的物理底线,先把写入方式调顺，再按数据热度配盘，这条路上没有玄学。
边缘节点磁盘IO写入延迟高什么原因？常见问题解答
换了NVMe盘之后写入还是慢，问题出在哪？
如果更换硬件后现象没有明显改善,优先排查写入链路，最常见的两个原因：一是WAL仍然频繁fsync，每次组提交的积累时间太短，IO合并效果有限；二是文件系统挂载参数未调整，atime更新产生了额外的写事务，从数据库的刷盘频率下手，比换更贵的盘更有效。
磁盘%util达到100%就一定是硬件瓶颈吗？
不一定。%util反映的是磁盘处于忙状态的时间比例，调度器频繁切换、坏道重映射、单队列设备都会让%util虚高，结合await和svctm一起看，如果延迟不高，说明盘能扛住当前请求，问题更可能出在上层写入频率太高，先用日志查写入端点，再下硬件结论。
边缘节点可以用机械盘做时序数据存储吗？
可以做冷数据归档,不适合做热数据主存储，时序数据采集写入以小文件随机写为主，机械盘的随机IOPS性能有限，持续高频写入时延迟会快速上升，容量大、单价低是机械盘的优势，放在数据分级架构末段，承接低频的离线数据，是比较合理的用法。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/723732.html
