系统图片访问异常（HTTP_206响应）排查解决

问题描述

• 周一上午，客户群大量反馈：线上所有系统的图片出现有时无法访问、访问加载慢、有时需要多次加载才可以显示等问题。

问题排查

• 根据这种有时无法访问的问题，首先推测是不是有的节点挂了，经排查，发现前后端docker服务集群中的所有服务节点均正常。
• 推断在应用程序服务正常，只是图片异常的情况，很有可能是nginx（通用入口服务器）或者fastdfs(文件服务器)的问题；经过多次刷新后，终于登录上后台管理系统，测试文件上传功能，成功；然后访问上传成功的图片，发现只加载了一半，而另一个同事测试移动端系统的图片http响应码为206（客户端通过发送范围请求头Range抓取到了资源的部分数据），而图片又不大，于是可以大致推断fastdfs正常，很有可能是nginx异常引起的。
• 登录nginx服务器（通用入口），执行top命令，发现nginx cpu占用20%左右，正常情况下都是占用0.几%，不至于这么多；执行free -mh命令，发现mem的free只剩下一百多mb,而used也只用的几百mb,反而buffer/cache很高。

• 执行df -h命令，未响应；执行df /命令，发现系统盘空间100%。综上所述，系统盘空间不够导致nginx无法正常存储运行日志，缓冲区占用较高说明磁盘空间不足开始向物理内存借用空间，系统盘需要扩充以快速解决问题。

临时解决

• 经过各方资源的积极配合和快速处理，系统盘成功又增加了50G可用空间，重启nginx后，线上图片访问恢复正常。

根本原因

• 临时解决后，准备找出哪个目录占用了大量空间，输入du -sh /*,查看根目录下各目录使用空间，发现/app目录占用了32G。

• 经排查，/app目录是很多nginx子配置的access_log目录，而/app目录竟然不是挂载到/data数据盘上的，而是挂在了系统盘上；这样，不断产生的日志文件导致了系统盘占满。

最终解决

• 把/app移动到空间足够的数据盘目录/data。

• df -h 查看空间并未释放，输入lsof | grep app，nginx进程之前打开了这些文件，还在向/app写日志，并未真正从磁盘删除。

• 修改nginx配置文件，查看nginx域名配置，把所有日志写入文件路径为/app开头的，替换成/data/app。

• 新的日志写入已经生效，老的还被nginx死进程占用着，需要删除nginx死进程。

• 删除死进程后查看磁盘挂载空间，/app占用的32G空间已释放。