乐趣区

关于druid:数据库连接池监控

连接池数量到底该配置成多少?

加了数据库连接池监控之后,就能够验证连接池数量是否配置的太大,因为之前都是乱配的,配了好几百,前面发现理论的沉闷连贯数量只有几个,所以配置数量个别只有几十个就能够了,因为

  • 1. 并发申请没有那么高,可能就是个位数,高的时候是十位数,所以几十个就足够了。
  • 2. 如果不思考并发数量,也只须要配置几十个,就是 cpu 的数量 *2,20 来个就能够了。

所以最终的后果是,如果没有并发,配置 cpu 数量 * 2 就能够了,20 个就足够了。如果有一点并发 (几十个),就 30 到 50 个就够了。如果并发达到 50 个,就还能够再往上加到 100,然而最好不要超过 100,超过 100 就应该加机器了,因为并发太多,机器也解决不过去,会导致处理速度变慢,所以就要加机器,好比每个人要做的事件变少了,速度就变快了。

数据库连接池的连贯跟线程池有关系吗?

数据库连接池的连贯跟线程池有关系吗?没关系。

切换连贯,是切换线程吗?不是。

一个是切换线程上下文耗资源,因为要用户态和内核态切换,一个是创立数据库连贯耗资源,因为要三次握手。

所以,这两个货色没有任何关系,惟一的共同点就是复用对象,一个是线程对象,一个是数据库连贯对象。

为什么要复用对象?因为这两种对象,一个是创立代价太高,一个是切换代价太高 (线程数量少,切换次数就少)。

数据库连接池满了怎么办?

数据库连接池满了怎么办?阻塞。默认就是阻塞,直到连接池有新的连贯能够用。举个例子,比方配置的是 30,当初满了,第 31 个申请来了,这个时候就阻塞,直到 30 个连贯里有一个连贯曾经执行实现了,当初闲暇进去了,这个时候这个闲暇的连贯就去执行方才的第 31 个申请。

数据库连接池获取连贯的耗时?

个别失常状况就是几 ms,然而如果是新创建的连贯,就要耗时几百 ms,大略是 200ms 左右。如果是启动的时候,即连接池初始化的时候,获取连贯须要 1s,即差不多 1000ms。这些都是实在的监控数据,而且是生产环境的,测试环境也一样也差不多。

退出移动版