本节书摘来自异步社区出版社《MySQL排错指南》一书中的第4章，第4.2节，作者：【美】Sveta Smirnova（斯维特 斯米尔诺娃），更多章节内容可以访问云栖社区“异步社区”公众号查看。
4.2 操作系统限制
操作系统在MySQL上会存在其他限制。例如，我曾经见过一个案例，服务器故障是因为Linux主机设置了vm.overcommit_ratio = 50。这个参数指定系统经由malloc()可分配的全部虚拟内存百分比，一个进程尝试分配更多内存时将会失败。50%是许多Linux安装时的默认值。所以mysqld分配现有内存的50%，当它试图分配更多的时候就失败了。在多任务配置中，这个选项有利于防止其他关键进程受MySQL服务器影响，但在专有服务器环境中这个选项显然是很荒谬的。
另外一个重要的UNIX选项是ulimit，它用来限制用户各方面的资源[2]。当使用ulimit命令限制资源或者其他系统工具时，记住MySQL服务器也是运行在一个用户下，这些限制对任何人都生效。
3.9.1节提到了操作系统限制是如何影响open_files_limit变量的，我在这里举例说明一下。假设服务器的ulimit限制打开文件（-n选项）为1024，大多数系统的默认值。如果你试图以--open-files-limit=4096来启动mysqld，它并不会重写操作系统限制。
如果你有很多表，那么这个选项就非常重要。如果此值设置过小，那么MySQL服务器就会在打开表和关闭表操作上消耗大量时间，从而拖慢运行速度。如果服务器由于缺少资源不能打开新表，甚至会出现拒绝尝试连接的情况。
因为每个操作系统都有具体的特性，我不再针对系统限制调优进行深入讨论。我没有提到Windows，但请放心，它也有限制。
每当你怀疑操作系统限制了MySQL服务器，请先检查之前提到过的资源：内存、CPU、网络带宽。检查mysqld的资源是否小于硬件提供的。通常，性能问题出现在内存或CPU不够用时。另外，检查允许打开的文件数。
如果你发现mysqld应该并且可以使用更多的资源，检查操作系统优化的各个方面。比如，操作系统内核选项或者默认用户在可用内存量上没有限制，但是在运行mysqld的用户上做了专门限制。当大多数操作系统限制是很大的或者没有设置时，而用户账户的默认值很小，这是种常见的情况。
如果MySQL使用了有限的资源，你有时可能会很奇怪出问题时是由于缺乏资源，还是仅仅是没有用到它们，因为当时负载非常低。当服务器故障时，它要么在错误日志文件中输出消息，要么性能开始急剧下降。另一个迹象是，当你试图增加一个选项时，它并没有变。前面的open_files_limit例子说明了这点。在这种情况下，如果在启动时设置该选项，那么你就会在错误日志文件中找到这些消息，或者你会在动态设置该选项时发现一条警告。检查可疑变量的真实值也是一个好方法。
