云服务器index挂载满了，最直接的解决方法是清理inode占用，删除日志、缓存和临时文件，必要时扩容数据盘。这里的“index”通常指文件系统inode索引，当inode耗尽时，即使磁盘有剩余空间，系统也无法创建新文件，下面按诊断、清理、预防三步走。
如何确认云服务器index挂载满了
先确认问题确实出在inode上,登录服务器执行以下命令：
![[享干货]云服务器满了怎么办？如何清理网站服务器空间？硬盘占用100%可以删除二进制日志或者备份](https://i1.hdslb.com/bfs/archive/47e4adeec6aad21fc95c2170bb7db6153b16f885.jpg)
df -i
如果看到或/data挂载点的IUse%接近100%，说明inode确实满了，再执行df -h查看空间使用率，多数情况下空间还有富余，这就是“文件多但个头小”的典型特征。
用一条命令定位inode占用大户
find / -xdev -type f | cut -d '/' -f 2 | sort | uniq -c | sort -n
这条命令按一级目录统计文件数量，输出结果后看哪个目录文件数最多，就顺藤摸瓜继续深挖，例如/var和/tmp是重灾区。
区分“存储空间满”和“inode满”
二者表现类似，但解决思路不同，存储空间满用du -sh /排查大文件，inode满用find / -type f | wc -l统计文件数量。如果服务器报错“No space left on device”且df -h显示剩余空间充足，基本可以断定是inode耗尽。
inode满了怎么清理：从日志到缓存
确认是inode问题后，按下面顺序清理，每步操作后执行df -i验证效果。
第一优先级：系统日志文件
日志虽然通常不大，但碎片化严重，先查看/var/log目录下的小文件：
find /var/log -type f -size -1M | wc -l
发现大量小日志后，用ls -la /var/log/按时间排序，找到最近被轮转的日志文件，处理方式不是直接删,而是使用日志轮转：
logrotate -f /etc/logrotate.conf
该命令强制轮转日志，之后系统会自动清理旧日志，手动操作时，
cat /dev/null > /var/log/messages比rm命令更好,避免删除正在被进程占用的文件导致句柄泄漏。
第二优先级：临时文件和Session文件
/tmp目录下的临时文件、PHP session文件、上传临时文件都是inode消耗大户，检查PHP session目录：
find /var/lib/php/session -type f | wc -l
如果你的网站访问量较大，这里可能堆积数十万个session文件,清理命令：
find /var/lib/php/session -type f -mtime +7 -delete
删除7天前的session文件，保留近期活跃会话，避免影响正常登录的用户，检查/tmp下的文件，find /tmp -type f -mtime +7 -delete同理。
第三优先级：邮件队列和缓存文件
安装了邮件服务或PHP框架的服务器，邮件队列容易堆积,查看队列文件数：
find /var/spool/mqueue -type f 2>/dev/null | wc -l
如果发现大量未发送的邮件，清理时先停掉邮件服务，再删除队列，使用Composer、npm等包管理工具的项目，vendor或node_modules目录有海量小文件，网站在运行期间这些文件不能直接删，需要找到项目备份后清理,或者直接删除站点重新部署。
清理后的复查手段
df -i
如果IUse%降到80%以下，基本恢复正常，如果还是满的，说明有更为隐蔽的占用,比如删除文件后进程仍持有句柄：
lsof +L1
输出结果中+L1标记的就是已删除但仍被进程占用的文件,找出来重启对应进程即可释放。
inode满的深层原因与预防策略
清理只是治标,治本需要理解inode的分配机制。
inode数量和磁盘分区的对应关系
inode数量在格式化分区时就已固定，据行业共识，ext4文件系统默认每16KB空间分配一个inode，如果服务器存储大量小于16KB的小文件，inode就会很快消耗完，云服务商默认的数据盘分区策略不一定适合高小文件场景，
使用前检查分区inode数量并预估需求非常关键。
预防方案：调整文件系统参数
对于尚未使用的新数据盘,格式化时可以指定更大的inode比例：
mkfs.ext4 -i 8192 /dev/vdb1
-i 8192表示每8192字节分配一个inode，相比默认值16KB提高了一倍，该操作会擦除整块磁盘，已有数据不可使用此方案,需提前备份迁移。
预防方案：定期扫描和监控
部署crontab定时任务,每周扫描一次文件总数并记录：
echo "/5 df -i | awk 'NR==2 && $5>85 {print "inode warning"}' >> /var/log/inode_monitor.log" | crontab -
实际使用时，建议脚本在inode使用率超过80%时自动清理临时文件，超过90%时发送邮件告警，这样可以第一时间发现异常,从容应对。
云服务器数据盘inode满导致的网站异常场景
这类问题在运行中的网站上表现非常明显,下面是一个典型场景。
症状：动态页面报错，静态资源正常
用户访问网站首页正常，但涉及登录、上传、评论的功能全部报500错误，查看应用日志（如/var/log/nginx/error.log），出现write(28) No space left on device，执行df -h显示磁盘剩余20GB，多份健康检查脚本都显示正常，此时需要自查df -i，很容易发现数据盘的IUse%为100%。
解决办法：优先抢救而非扩容
在这种场景下，业务中断带来的损失大于扩容成本。先执行df -i确认分区，再清理最明显的临时目录，同时联系云服务商扩容数据盘，双线并行，很多云服务商支持在线扩容，但扩容的是存储容量，不能直接增加inode，如果清理不彻底,新空间也存不了多少小文件。
有条件的企业，建议把静态文件、上传图片移到对象存储OSS或COS，从架构上减少小文件对云服务器数据盘的压力，这种方法虽然前期改造工作量稍大,但能从根本上解决inode瓶颈。
扩展思路：index挂载占用与内存的关联
如果清理完inode后系统速度仍然缓慢，考虑另一种可能swap分区或内存文件系统tmpfs也占用了“index”。
tmpfs对inode的隐形消耗
默认情况下，/dev/shm挂载为tmpfs，它会占用内存的50%，如果有程序在这个目录下创建大量小文件，内存会被逐渐消耗，表现为系统物理内存充足但无法分配新内存,查看：
df -h /dev/shm
如果使用率超过60%，就需要检查哪些服务在写/dev/shm，这类问题不常见，但排查难度大,建议先在服务器上检查是否有相关服务。
关于云服务器inode问题的常见问答
云服务器index挂载满了，不扩容能恢复吗
能，多数云服务器inode耗尽可以通过清理垃圾文件恢复，比如系统日志、临时文件、缓存以及旧的备份包，如果清理后不久又复发，说明业务本身产生了大量小文件,这种情况建议调整架构或重新规划文件系统。
inode满了会有什么明显影响
服务器无法创建任何新文件，包括新的日志、session、上传的图片文件，现象是网站出现500错误，数据库写入失败，甚至ssh登录后无法新建临时文件，此时shutdown、top等依赖/dev/shm的命令可能无法正常运行,重启服务器可能无法正常启动服务。
为什么磁盘空间充足却无法写入文件
文件系统由空间和inode两部分构成，文件目录、权限、大小等元数据存储在inode中，磁盘剩余空间大但inode耗尽时，系统无法为文件分配索引节点，因此即使有空间也写不进去，这就是“文件多而小”场景下常见的资源耗尽状态。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/%e4%ba%91%e6%9c%8d%e5%8a%a1%e5%99%a8index%e6%8c%82%e8%bd%bd%e6%bb%a1%e4%ba%86%e6%80%8e%e4%b9%88%e5%8a%9e%ef%bc%9f%e7%a3%81%e7%9b%98%e7%a9%ba%e9%97%b4%e4%b8%8d%e8%b6%b3%e6%80%8e%e4%b9%88%e6%b8%85/
