今天起床发现一台服务应用不能正常启动，进入系统，重启服务居然报空间不足错误：

No space left on device

查看了下各个磁盘空间情况，发现各个盘空间充足，那怎么就会报空间不足呢：

突然想起，以前看到过，Linux系统下好像对文件数量有限制，一旦文件数量配额用完，就算空间再多，也不能创建文件，赶紧清理下一些不要的日志文件，重启服务，果然服务重启正常。应用恢复了，感觉爬下相关学习资料，看看Linux下都有那些限制：

首先看下ulimit 这个命令

ulimit 是一个计算机命令，用于shell启动进程所占用的资源，可用于修改系统资源限制

-H 设置硬资源限制.

-S 设置软资源限制.

-a 显示当前所有的资源限制.

-c size:设置core文件的最大值.单位:blocks

-d size:设置数据段的最大值.单位:kbytes

-f size:设置创建文件的最大值.单位:blocks

-l size:设置在内存中锁定进程的最大值.单位:kbytes

-m size:设置可以使用的常驻内存的最大值.单位:kbytes

-n size:设置内核可以同时打开的文件描述符的最大值.单位:n

-p size:设置管道缓冲区的最大值.单位:kbytes

-s size:设置堆栈的最大值.单位:kbytes

-t size:设置CPU使用时间的最大上限.单位:seconds

-v size:设置虚拟内存的最大值.单位:kbytes

-u <程序数目> 　用户最多可开启的程序数目

我使用这个命令看了下我系统的资源限制：

好像没有发现有文件、目录多少的限制数据，继续爬网

inode - 索引节点

资料显示，当一个盘的inode耗尽，会出现No space left on device， 造成磁盘的不可写入，那么inode是什么？

要理解inode，需要理解磁盘文件存储规则，是理解Linux文件系统和磁盘存储的基础：

首先磁盘的最小存储单元为“扇区（sector）”，操作系统在读取数据的时候，不会一个一个扇区的读取，而是一次性读取一个"块（block）"。一个块由多个扇区组成，是文件存储的最小单元。一个扇区的存储大小一般为512字节，而块着包含2的N次方个扇区。块是系统定义的，所以在windows中，块又被叫做簇（cluster）。块的大小最常见的是4K，所以有个叫“4K对齐”的东西，4K对接是由于现在的磁盘容量不断扩大，每个扇区512字节就太小了，于是每个扇区由512字节改成了4096字节，为了保证磁盘读写效率，所以有了"4K对齐"的概念。

文件的二进制数据是存储在块中的，那么当我们需要创建或读取某个文件的时候，必须要知道这个文件的存储块，额记录这个这个信息的地方就是inode表。在系统创建文件系统的时候，就会创建大量的inode，并将磁盘空间的一部分用于存储这些inodex信息（单我们购买的移动硬盘格式化后发现可用空间大小和磁盘标注的大小不一样，一般都比标准的小，就是有一部分空间用于存储这些信息了）。所以创建和访问某个文件，必须要对应一个inode，inode记录了文件的相关信息，比如创建日期、文件大小等。所以一旦inode耗尽没有了，就算磁盘有空间，也不能创建文件，会出现文章开头的报错信息。

检查每个磁盘的inode信息

知道问题出在那了，那怎么查看磁盘还有多少个inode可用呢，可以使用下面命令：

tune2fs -l /dev/vda1 | grep "inodes"

查看发现，一个盘居然只有22个Free inodes 了，估计过两天又要耗尽，赶紧开始清理文件。

也可以通过，df -i 查看，不过2个命令查看的结果不一致，不知道什么原因

找出文件数量最多的文件夹

现在是要找出文件数量最多的文件夹，查看文件情况，并清理，我使用以下命令

for i in /*; do echo $i; find $i | wc -l; done

一层一层目录排查，排查到最后发现，/var/spool/postfix/maildrop这个目录下存在大量文件：

通过网上资料显示：

由于 Linux 在执行 cron 时，会将 cron 执行脚本中的 output 和 warning 信息，都会以邮件的形式发送 cron 所有者， 而由于客户环境中的 sendmail 和 postfix 没有正常运行，导致邮件发送不成功，全部小文件堆积在了 maildrop 目录下面，而且没有自动清理转换的机制，所以长时间，导致这个目录已堆积了大量的文件。

既然是没用的文件，首先当然是清理这个目录了：

cd /var/spool/postfix/maildrop

rm -rf *

执行居然提示

-bash: /bin/rm: Argument list too long

文件太多了，怎么办，只能换成下面命令了：

find /var/spool/postfix/maildrop -name "*" | xargs rm -rf "*"

清理完成后，查看inode

怎么保证以后不再产生这些垃圾文件呢，网上方法是直接修改“/etc/crontab”，将‘MAILTO=root’替换成‘MAILTO=""，然后重启 crond 服务。

目录限制

Linux同一路径下，子目录个数限制为31998，这个没用遇到过，所以还是创建多级目录把。

打开的文件数限制

日志文件报错：Too many open files in system

赶紧查看了下当前打开文件数据：

lsof|wc -l

数据显示：212640

通过ulimit -n 命令查看的是655350，没有达到最大啊，怎么回事呢？是不是还有那个地方有这个设置限制，查了下发现还真有，执行下面命令：

cat /proc/sys/fs/file-max

数据显示为：212644，还真和打开数量接近，使用下面命令修改的和ulimit一样：

echo 655350 > /proc/sys/fs/file-max

这样可以马上生效，但是系统重启，又会失效，如果需要永久有效，需要修改 /etc/sysctl.conf文件，后面加上fs.file-max = 655350，执行sysctl -p 生效

所以当系统中出现 Too many open files in system 错误的时候，这2个地方都需要看下