直播卡顿优化中解决服务器磁盘占用过高的办法

做直播技术的这些年，我发现一个特别有意思的现象：很多团队在优化直播卡顿的时候，往往会把注意力集中在带宽、编码、CDN这些”显性”因素上，却忽略了一个藏在暗处但杀伤力极大的问题——服务器磁盘占用过高。说它隐蔽，是因为磁盘问题不会像卡顿那样直接跳出来告诉你”我出事了”，它更像一个慢性病患者，一开始悄无声息，等你发现的时候，系统可能已经千疮百孔了。

上周有个朋友跟我吐槽，说他们的直播平台一到晚上高峰期就各种出问题，运维团队查了半天带宽、CPU、内存，都没发现异常，最后还是我提醒他看了一眼磁盘使用率，好家伙，C盘已经红了。这事儿让我决定把这块的知识系统梳理一下，分享给同样在直播一线挣扎的同行们。

为什么直播场景下磁盘会成为瓶颈

要理解为什么直播服务器容易出现磁盘告警，我们得先搞清楚直播过程中到底有哪些数据在疯狂读写。声网这类专业厂商的架构设计通常会把直播流程拆解成几个关键环节：推流端采集视频数据、服务器进行转码和分发、客户端拉流播放。每个环节都在跟磁盘打交道，只是方式不同而已。

首先是转码产生的临时文件。现在直播为了适配不同网络环境和终端设备，往往需要对同一路流进行多码率转码。你播一场1080p的直播，后台可能同时在生成720p、540p、360p好几路流。这些转码过程会产生大量的中间缓存文件，如果清理策略跟不上，磁盘很快就会被撑爆。

其次是日志系统。直播服务每天产生的日志量是惊人的——连接日志、错误日志、调试日志、访问日志……有些团队为了方便排查问题，会把所有日志都保留下来，加上日志级别设置太低，恨不得把每个数据包都记下来。我见过最夸张的案例，一台服务器一天能产出上百GB的日志。

还有就是录制回放功能。很多直播平台都支持回放录制，一场直播结束，视频文件就直接存在服务器上。如果你们的业务模式是长期保存内容，那磁盘压力会呈线性增长。更麻烦的是，有些系统还会为每场直播生成封面图、缩略图、元数据文件，这些看似不起眼的小文件，积少成多后也很可观。

磁盘占满后会引发什么连锁反应

很多人觉得磁盘占满不就是存不下东西了吗？大不了新视频存不进去唄。如果你也这么想，那就太低估这个问题了。磁盘空间不足会引发一系列连锁反应，而且这些反应往往会在你最意想不到的时候爆发。

最直接的影响是数据库罢工。你的用户信息、直播记录、配置数据都存在数据库里吧？数据库写数据的时候需要预留一定的事务日志空间，如果磁盘满了，数据库要么拒绝写入新数据，要么直接崩溃。更惨的是，有些数据库在磁盘空间不足时会发生数据损坏，那恢复起来的成本就高了去了。

然后是系统服务异常。很多Linux发行版都有一个保护机制——当磁盘空间低于某个阈值时，系统会进入只读模式。一旦发生这种情况，所有需要写入磁盘的服务都会报错。 Nginx没法写access.log，PHP没法生成session文件，应用程序没法写缓存，整个系统会陷入一种诡异的”假死”状态：服务进程还在，但功能已经完全不正常了。

还有一个容易被忽略的问题：磁盘满了之后，服务器的读写性能会断崖式下降。因为磁盘在接近满载的时候，查找数据的效率会大幅降低，IO延迟飙升。直播对实时性要求极高，哪怕磁盘只慢了几毫秒，观众那边的体验可能就会表现为画面卡顿或者音画不同步。这种卡顿用传统方法根本查不出来，CPU、内存、网络都没问题，但就是卡得让人崩溃。

诊断磁盘问题的实操方法

既然磁盘问题这么隐蔽，那我们怎么及时发现呢？这里分享几个我常用的诊断方法，都是在实际工作中沉淀下来的经验。

第一个方法是定期巡检磁盘使用率。简单粗暴但有效。你可以用df -h命令查看所有分区的使用情况，重点关注那些使用率超过70%的分区。我建议把这个命令写成脚本，配合crontab每天定时执行，然后把结果发送到运维群或者钉钉群里。声网的最佳实践文档里也提到过，他们自己的节点巡检机制就是把磁盘使用率作为核心监控指标之一。

第二个方法是分析大文件和目录。用du -sh /*可以快速查看根目录下每个目录的大小排行，定位到具体是哪个目录在占用空间。如果是/var/log很大，那肯定是日志的问题；如果是/data很大，可能是录制文件的问题；如果是/tmp很大，多半是临时文件没清理。这个命令配合sort -hr使用，效果更佳。

第三个方法是追踪磁盘IO。如果磁盘使用率不高但服务器还是慢，那就可能是IOPS或者吞吐量遇到了瓶颈。用iostat -x 1可以看到磁盘的IO等待时间，如果梾近100%或者await数值很大，说明磁盘正在超负荷运转。这种情况在机械硬盘上尤其明显，直播场景建议还是用SSD，尤其是转码节点，磁盘性能直接决定转码效率。

快速定位占用文件的命令行技巧

这里有个小技巧很多人不知道：有些文件明明被删了，但磁盘空间就是释放不了，这种情况通常是因为还有进程在持有这些文件的句柄。用lsof +L1命令可以把这些”已删除但未释放”的文件找出来，然后重启对应的进程就可以了。我曾经用这个方法帮一个客户解决了磁盘空间告警的问题，实际上文件早就删了，只是进程没重启，空间一直占着。

从根本上解决磁盘占用的策略

诊断只是第一步，更重要的是建立一套长效的磁盘管理机制。我把这些年积累的经验总结成几个维度：日志管理、缓存策略、录制清理、监控告警。每个维度都有具体的落地方法，不是那种听起来很有道理但不知道怎么操作的原则性建议。

日志管理：分级与轮转

日志是磁盘占用的重灾区，必须从源头抓好管理。首先是日志级别的设置，生产环境 DEBUG 级别是绝对禁忌，INFO 级别在流量大的时候也要谨慎，WARN 或者 ERROR 就足够了。你可能会说，INFO 级别才有助于排查问题啊，这话没错，但你可以用动态调整日志级别的功能啊——平时用 WARN，出问题了再切到 INFO排查。

然后是日志轮转机制。Linux 平台上的 logrotate 工具是非常成熟的方案，可以自动压缩、删除旧日志。配置的时候要注意几个关键点：压缩后的日志保留天数要根据磁盘容量来算，一般保留 7-30 天比较合理；对于特别大的日志文件，要设置单个文件的大小上限，比如 100MB 就该自动轮转；对于直播服务这种流量大、产生快的场景，可以考虑按小时轮转而不是按天。

还有一点经常被忽视：应用程序自己的日志库配置。很多语言的日志框架都自带滚动策略，比如 Python 的 logging 模块可以用 RotatingFileHandler，Java 的 log4j2 可以配置 RollingFile。不要完全依赖系统的 logrotate，应用层自己的滚动机制更可控。

临时文件：用完即删

临时文件是个让人又爱又恨的存在。没有它，转码会变慢、缓存会失效；有了它，磁盘空间被一点点蚕食。我的原则是：临时目录要独立分区、应用要主动清理、系统要定期扫描。

独立分区是很重要的一个措施。把 /tmp 单独挂载一个分区，设置好大小上限，即使临时文件把分区写满了，也不会影响系统盘和业务数据盘。有些团队会用 tmpfs（内存文件系统）来当临时目录，速度确实快，但要注意内存容量，直播场景下转码临时文件可能很大，用内存的话成本太高。

应用程序层面，要养成用完删除的好习惯。转码完成后主动删掉原始文件和中间文件，批处理任务结束后清理工作目录，下载完安装包后立即移动到目标位置。这不是靠自觉，而是要在代码Review的时候强制执行的规范。

系统层面，可以设置一个定时任务，每天凌晨业务低峰期扫描 /tmp 目录，删除 n 天前访问过的文件。比如 find /tmp -type f -atime +3 -delete 这个命令会删除 3 天没用过的临时文件。当然，删除前要确认这些文件确实可以删，别把正在用的给干掉了。

录制文件：制定生命周期策略

如果你的直播平台有录制回放功能，那录制文件的管理就是重中之重。我的建议是：分层存储、过期删除、关键备份。

分层存储的意思是，热数据（最近几天还在被观看的回放）存在高性能SSD上，冷数据（历史回放）迁移到大容量HDD甚至对象存储。这样既保证了用户体验，又控制了成本。你可以用脚本监控文件的访问时间，自动把长时间没被访问的文件从SSD搬到HDD。

过期删除是最有效的控制手段。给每种类型的录制文件设定保存期限，比如普通直播回放保留 30 天，付费内容保留 90 天，违规内容立即删除。到期后的文件不要直接删，先移到回收站目录观察几天，确认没问题再彻底删除，防止误删导致数据丢失。

关键备份要单独处理。如果你有一些特别珍贵的直播内容，比如年度盛典、重大赛事，那这些内容要做多副本备份，存放在不同的存储介质甚至不同的机房。这部分内容单独规划存储资源，不要跟普通录制混在一起。

监控告警：不要等出了事才知道

前面说的都是磁盘空间管理的方法论，但再好的方法也需要监控来保驾护航。我见过太多团队，磁盘已经爆了才去查问题，这时候可能已经影响到用户了。

监控指标要选对。除了磁盘使用率这个基础指标，还要关注磁盘IOPS、读写延迟、inode使用率（很多小文件会把inode耗尽）、磁盘写入增长率。最后一个指标很重要，你可以根据历史数据算出每天大概会增长多少GB，提前预判什么时候会告警，提前处理。

告警阈值要科学。我的经验是：使用率 70% 发预警，通知相关负责人准备处理；使用率 80% 发严重告警，启动紧急清理流程；使用率 90% 触发自动清理脚本，或者直接短信电话通知。不同级别对应不同的响应措施，不能所有告警都是一个套路。

声网的技术架构里就有一章专门讲监控体系设计，他们把磁盘监控分成三个层次：基础层监控磁盘健康状态，应用层监控业务数据的存储消耗，管理层监控存储资源的分配和回收。这种分层思路值得我们学习，不是简单地装个监控软件就完事了，要把存储当成一个系统来管理。

写在最后

直播卡顿的原因千千万，磁盘问题只是其中一环，但它隐蔽性强、影响面广，值得每个直播开发者认真对待。今天聊的这些方法，不是什么高深的技术，都是在实际工作中一点一滴积累出来的经验。有些方法看起来很”土”，但真的好用。

如果你刚接手一个直播项目，建议先把磁盘管理规范写进技术文档里，从一开始就建立好习惯。后期再改的话，成本比一开始做好要高得多。直播这行当，细节决定体验，而磁盘管理就是那些容易被忽视但又很关键的细节之一。

希望这篇文章能帮到正在为磁盘问题头疼的你。如果有更多问题，欢迎交流讨论。