我在高负载时间内看到了一些错误：
mysql_connect() [<a
href='function.mysql-connect'>function.mysql-connect</a>]: [2002] Resource
temporarily unavailable (trying to connect via
unix:///var/lib/mysql/mysql.sock)
据我所知，mysql 服务器没有达到其最大连接限制，但还有其他原因阻止它提供查询服务。 MySQL 还会遇到哪些其他限制？
我正在运行 RHEL 6.2 64 位和 MySQL 5.5.21
假设您的系统当前是基于 Unix 的（如问题陈述中所示）。如果这是正确的，那么您可能会遇到以下问题：
-
你已经用完了memory可用于 MySQL。
这是您最有可能面临的问题。 MySQL 连接池中的每个连接都需要内存才能运行，如果该资源耗尽，则无法建立更多连接。当然，各种操作的内存占用和最大数据包大小可以调整你相当于my.cnf如果您发现这是一个问题。
这是一个可以提供帮助的附加线程，但您也可以考虑使用更简单的分析工具，例如top对正在发生的事情有一个大致的估计。
-
你已经用完了文件描述符可用于您的 MySQL 用户帐户。
另一个常见问题：如果您尝试为需要文件 IO 超过 1,024 边界（默认情况）的请求提供服务，您将遇到操作失败的情况。这是因为大多数系统对每个用户一次可以打开的文件描述符的数量指定了软限制和硬限制，超过此阈值可能会导致问题。
这通常会在日志文件中表达一系列明显的迹象。查看/var/log/messages以及您的类似目录（例如，/var/log/mysql看看你是否能找到任何有趣的东西。
-
你遇到了一个活锁或死锁您的线程无法满足的场景。
由于内存和文件描述符耗尽，如果超出系统能够处理的计算负载，线程可能会超时。它不会抛出此错误消息，但这是将来需要注意的事情。
-
您的系统已用完可用的 PIDfork.
另一个常见场景：fork在任何给定时间只有这么多 PID 可供使用。如果您的系统只是过度分叉，它将无法为请求提供服务。
最简单的检查是查看是否有任何其他服务可以连接到该计算机。例如，尝试通过 SSH 进入盒子，但发现不能，这就是一个很大的线索。
-
上游代理或连接管理器已耗尽资源并停止服务请求。
如果您的客户端和 MySQL 之间有任何服务层，则需要检查它是否崩溃、挂起或以其他方式变得不稳定。上述建议适用。
-
您的端口映射器已耗尽自身65,536 个连接后.
不太可能，但同样，可能是一种疲惫的情况。如上所述检查琐碎的服务连接，嗯，也是这里最好的停靠点。
简而言之：这是一种资源耗尽的情况，包括服务器只是“关闭”。您将必须进一步分析您的系统以查看您阻止的内容。在这种情况下，给我们的所有错误消息都是资源对客户端不可用的事实 - 我们需要查看有关该资源的更多信息server以确定更适当的补救措施。
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
