我正在对 Apache 服务器进行一些性能测试，并收到可怕的消息“上下文池已用尽！Dun Dun Dun。” （添加了戏剧性的强调）
目前开发人员提出的建议是简单地增加连接池大小。虽然这可能是有效的，但我的脑海中不断响起小铃铛说“好吧，这太简单了 - 这肯定有缺点”，我问社区其中一些可能是什么。
我想让它尽可能通用，这样它可能对大多数人来说是最有用的。
【问题讨论】：
标签： performance connection connection-pooling threadpool
警告：怀旧帖。
许多年前，我在大型机环境中工作。我的工作是运行临时 SQL 报告来评估圣诞节销售活动的有效性。 “在过去的 Z 周，与去年的同一周相比，X 线与 Y 线的表现如何”......以及类似的情况。
令人兴奋：直接针对实时数据库的临时查询，下午根据采购部门的问题做出营销决策。不允许出现 SQL 错误，不允许测试，没有开发环境，第一次就对了，或者什么都没有。
我去吃午饭了，我真是个傻瓜，我设计了一个多表连接，尽管经过了 30 分钟的查询，但它可以提供所需的结果，并且知道没有使用任何锁来阻止事务排序系统保存新订单。那是 12 月中旬，正值圣诞节订购旺季。
我回来了，公司一片混乱。整个订购系统崩溃了，一切都超时了，没有一个新的原因。
除了 CICS 无法获得连接。池已用完，因此新事务刚刚失败。
这是我的报告。它占用了大量的 CPU。它跑了很长时间。其他一切都运行了那么一点点。于是连接池中的连接用完了，其他的都死了一会儿。
我的查询已完成。它给出了正确的结果。采购部门很高兴，因为他们可以在第二天做出正确的决定。订单又开始保存了，你猜怎么着...
我既惊恐又尴尬，但令人惊讶的是，我暂时成为了当地的英雄，因为及时提供了关键的报告。半小时的危机在当时是一场灾难，但一天后，只是记忆。
如果这里有道德的话，那就是：
这类问题没有唯一的正确答案。
如果可以，请找出连接不足的原因，因为这可能表明存在严重问题。
但可能不会，明天可能会出现不同的问题。
【讨论】：