单纯增加连接池有什么危险？
我正在对 Apache 服务器进行一些性能测试，并收到可怕的消息“上下文池已耗尽！Dun Dun Dun”。 （添加了戏剧性的强调）
开发人员当前提出的建议是简单地增加连接池大小。虽然这可能是正确的，但我的脑海中响起了小声音说“好吧，这太简单了——这肯定有缺点”，我向社区询问其中一些可能是什么。
我想让它尽可能通用，这样它可能对大多数人来说最有用。
I'm doing some performance testing against an Apache server and getting the dreaded message "the context pool has been exhausted! Dun Dun Dun." (dramatic emphasis added)
The current proposal floating around by the devs is to simply increased the connection pool-size. While this may be valid, little bells are going off in my head saying "well, that's too simple - surely there are downsides to this" and I ask the community what some of those may be.
I would like to keep this as generic as possible so that it might be the most use to the most people.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
警告：怀旧帖子。
很多年前，我在大型机环境中工作。我的工作是运行临时 SQL 报告来评估圣诞节销售活动的有效性。 “在过去 Z 周内，与去年同期相比，X 线相对于 Y 线的表现如何”......以及类似的内容。
这是令人兴奋的：直接针对实时数据库进行临时查询，根据采购部门早上提出的问题做出下午的营销决策。不允许出现 SQL 错误，没有测试，没有开发环境，第一次就是对的，或者什么都没有。
我离开去吃午饭，我真是个疯子，精心设计了一个多表连接，可以给出期望的结果，尽管在 30 分钟的查询之后，我知道没有锁来阻止事务排序系统保存新的数据。订单。当时是十二月中旬，正值圣诞节订购季的高峰期。
我回来了，公司一片混乱。整个订购系统瘫痪了，一切都超时了，没有人知道为什么。
除了 CICS 无法获得连接之外。池已耗尽，因此新交易失败。
这是我的报告。它占用了大量的CPU。跑了很长时间。其他一切都运行得稍长一些。于是连接池就耗尽了连接，其他的都暂时死掉了。
我的查询完成了。它给出了正确的结果。采购部门很高兴，因为他们可以为第二天做出正确的决定。订单又开始被保存，你猜怎么着……
我感到震惊和尴尬，但令人惊讶的是，我暂时成为了当地的英雄，因为我及时提供了重要的报告。半小时的危机在当时是一场灾难，但一天后，就只是记忆了。
如果这里有一个寓意的话，那就是：
这类问题没有单一的正确答案。
如果可以的话，找出为什么你的连接耗尽，因为这可能表明某些事情严肃的。
但也可能不会，明天可能会出现不同的问题。
Warning: nostalgia post.
Many years ago, I worked in a mainframe environment. My job was to run ad-hoc SQL reports to evaluate the effectiveness of the Christmas sales campaigns. "How is line X doing, against line Y, over the last Z weeks, against the same weeks last year"... and similar.
It was exciting: ad-hoc queries, directly against the live database, marketing decisions being made for the afternoon, based on the morning's questions from the buying department. No SQL errors permitted, no testing, no development environment, it was right first time, or nothing.
I left for lunch, mad fool that I was, having crafted a multi-table join that would give the desired results, albeit after a 30 minute query, secure in the knowledge that no locks were being taken to prevent the transactional ordering system saving new orders. It was mid December, at the height of the Christmas ordering season.
I returned, the company in chaos. The whole ordering system was down, everything was timing out, no one new why.
Except that CICS couldn't get connections. The pool was exhausted, so new transactions just failed.
It was my report. It took a ton of CPU. It ran a long time. Everything else ran just that little bit longer. So the connection pool ran out of connections, and everything else died for a while.
My query completed. It gave the right results. The buying department was happy, since they could make the right decisions for the next day. Orders started getting saved again, and guess what...
I had been horrified and embarrassed, but amazingly, I was temporarily a local hero, for providing the crucial report just in time. The half-hour crisis was a catastrophe at the time, but a day later, just a memory.
If there's a moral here, it's this:
There's no single right answer to this sort of question.
If you can, find out why you're running out of connections, since it might be an indication of something serious.
But it might not, and tomorrow, there might be a different problem.