AWS：连接太多
我有一个RDS实例托管MySQL数据库。实例大小为 db.t2.micro
我也有一个expressjs后端连接到mysql rds实例 via连接池：
另外，我还有一个移动应用程序，客户端，expressjs api。
我面临的问题是，通过移动应用程序或通过Postman，有时我会遇到'太多连接'错误，因此有几个请求失败：
在RDS实例上。在当前活动上，我有时会获得65个连接，表明它已达到极限。我需要清楚的是：
- 当200个移动应用程序实例连接到API时，
rds实例时，是否将其注册为200个连接或从expressjs的连接1个连接？ - 达到RDS实例65连接限制是否正常？
- 这只是我使用 db.t2.micro 实例大小的问题吗？升级实例大小会解决此问题吗？
- 我的要求有什么错吗？
谢谢您，感谢您的反馈。
I have an RDS instance hosting a mySQL database. Instance size is db.t2.micro
I also have an ExpressJS backend connecting to the mySQL RDS instance via a connection pool:
Additionally i have a mobile app, the client, feeding off the ExpressJS API.
The issue i'm facing is, either via the mobile app or via Postman, there are times where i get a 'Too many connections' error and therefore several requests fail:
On the RDS instance. On current activity i sometimes get 65 connections, showing it's reaching the limit. What i need clarity on is:
- When 200 mobile app instances connect to the API, to the
RDS instance, does it register as 200 connections or 1 connection fromExpressJS? - Is it normal to be reaching the RDS instance 65 connection limit?
- Is this just a matter of me using db.t2.micro instance size which is not recommended for prod? Will upgrading the instance size resolve this issue?
- Is there something i'm doing wrong with my requests?
Thank you and your feedback is appreciated.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果您的应用程序创建一个100的连接池，那就是它将尝试打开的数据库连接的数量。它必须低于您的MySQL连接限制。
通常，连接池打开 asl 池的连接，因此当客户端调用HTTP API时，它们就准备就绪。如果在给定的时刻没有很多客户端使用API，则连接通常不会运行SQL查询。数据库连接仍然连接。
当您
SSH到远程Linux服务器时，您只是在运行任何命令之前坐在shell提示中一段时间。您仍然连接。您询问是否不建议生产
db.t2.micro实例。是的，我会同意的。我认为，使用最小的实例来节省金钱很容易，但是在我看来，Adb.t2.micro对于轻度测试都太小了。实际上，无论大小如何
T2类型使用“可爆破”性能。这意味着它只能提供短暂的良好性能。一旦实例耗尽了其性能积分，它们就会缓慢地充电，并且在充电时，该实例的性能非常低。如果您希望随时提供一致的性能，则可以进行测试，但不能进行生产。If your app creates a connection pool of 100, that's the number of database connections it will try to open. It must be lower than your MySQL connection limit.
Typically connection pools open all the connections for the pool, so they are ready when a client calls the http API. The connections might normally be running no SQL queries, if there are not many clients using the API at a given moment. The database connections are nevertheless connected.
Sort of like when you
sshto a remote linux server but you just sit there at a shell prompt for a while before running any command. You're still connected.You asked if a
db.t2.microinstance was not recommended for production. Yes, I would agree with that. It's tempting to use the smallest instance possible to save money, but adb.t2.microis too small for anything but light testing, in my opinion.In fact, I would not use any
t2instance for production, regardless of size. Thet2type uses "burstable" performance. This means it can provide only brief periods of good performance. Once the instance depletes its performance credits, they recharge slowly, and while they recharge, the performance of that instance is very low. This is okay for testing, but not for production, if you expect to provide consistent performance at any time.