[转载] oracle能开多大的连接池？# Java - 爪哇娇娃
t*k
1 楼
【 以下文字转载自 Database 讨论区 】
【 原文由 threestick 所发表 】
在一般的server上的话能开多少？
如果在有四个CPU，2G的小型机上又能开多少？
能够满足多少人在线（BS上）提交数据到数据库？
【 原文由 threestick 所发表 】
在一般的server上的话能开多少？
如果在有四个CPU，2G的小型机上又能开多少？
能够满足多少人在线（BS上）提交数据到数据库？
w*r
2 楼
I guess the oracle administrator has to tuning this value based on real
time statistics. The server side should set the maximum connection allow
ed. My companies server now set it to 120, we are still testing to see t
he real performance. Sometime, the pool size is not quite important, the
application can use multi-thread mechanism to synchronizely get the con
nection from pool, if the server's performance is good enough, a relativ
ely smaller pool size wont kill too much performance. For the da
【在 t********k 的大作中提到】
: 【 以下文字转载自 Database 讨论区 】
: 【 原文由 threestick 所发表 】
: 在一般的server上的话能开多少？
: 如果在有四个CPU，2G的小型机上又能开多少？
: 能够满足多少人在线（BS上）提交数据到数据库？
time statistics. The server side should set the maximum connection allow
ed. My companies server now set it to 120, we are still testing to see t
he real performance. Sometime, the pool size is not quite important, the
application can use multi-thread mechanism to synchronizely get the con
nection from pool, if the server's performance is good enough, a relativ
ely smaller pool size wont kill too much performance. For the da
【在 t********k 的大作中提到】
: 【 以下文字转载自 Database 讨论区 】
: 【 原文由 threestick 所发表 】
: 在一般的server上的话能开多少？
: 如果在有四个CPU，2G的小型机上又能开多少？
: 能够满足多少人在线（BS上）提交数据到数据库？
t*k
3 楼
比如我有1万左右的在线用户
有时提交数据比较频繁
但在平时很空闲
一年中可能就一二个月会有大量用户访问
在繁忙时只要提交数据成功
不要让用户等待很久
后台处理放在另外的程序中进行
这样的话一台数据库服务器不知能不能承担
【在 w*r 的大作中提到】
: I guess the oracle administrator has to tuning this value based on real
: time statistics. The server side should set the maximum connection allow
: ed. My companies server now set it to 120, we are still testing to see t
: he real performance. Sometime, the pool size is not quite important, the
: application can use multi-thread mechanism to synchronizely get the con
: nection from pool, if the server's performance is good enough, a relativ
: ely smaller pool size wont kill too much performance. For the da
有时提交数据比较频繁
但在平时很空闲
一年中可能就一二个月会有大量用户访问
在繁忙时只要提交数据成功
不要让用户等待很久
后台处理放在另外的程序中进行
这样的话一台数据库服务器不知能不能承担
【在 w*r 的大作中提到】
: I guess the oracle administrator has to tuning this value based on real
: time statistics. The server side should set the maximum connection allow
: ed. My companies server now set it to 120, we are still testing to see t
: he real performance. Sometime, the pool size is not quite important, the
: application can use multi-thread mechanism to synchronizely get the con
: nection from pool, if the server's performance is good enough, a relativ
: ely smaller pool size wont kill too much performance. For the da
xt
4 楼
才10,000? 我认为1000的Connection pool足以胜任.随便哪个DBMS
都能开这么多.
【在 t********k 的大作中提到】
: 比如我有1万左右的在线用户
: 有时提交数据比较频繁
: 但在平时很空闲
: 一年中可能就一二个月会有大量用户访问
: 在繁忙时只要提交数据成功
: 不要让用户等待很久
: 后台处理放在另外的程序中进行
: 这样的话一台数据库服务器不知能不能承担
c*s
5 楼
这不会是你想要多少就有多少的。要看你的Oracle license允许多少个并发连接。过去遇
到的几个客户一般是50~1000个链接的license，允许我们的应用占5~20个。
同时在线人很多不一定就需要很多链接。最少需要多少链接要看你的程序了，有没有故意
并发打开连接的代码，有也不会太多。过去我做的项目一般最小连接需要是3个，做压力
测试时把连接池设成3，20个线程每线程启动300个session，只要代码没错就没问题。
实施时看客户dbadmin愿意分给我多少连接，改连接池大小。当然越大越快。
CPU, 内存不是主要因素，毕竟数据库就一个。连接数是瓶颈。
一般的程序一个连接也可以满足1000人同时提交数据, 就是慢点, 大家排一个队。
【在 t********k 的大作中提到】
: 【 以下文字转载自 Database 讨论区 】
: 【 原文由 threestick 所发表 】
: 在一般的server上的话能开多少？
: 如果在有四个CPU，2G的小型机上又能开多少？
: 能够满足多少人在线（BS上）提交数据到数据库？
到的几个客户一般是50~1000个链接的license，允许我们的应用占5~20个。
同时在线人很多不一定就需要很多链接。最少需要多少链接要看你的程序了，有没有故意
并发打开连接的代码，有也不会太多。过去我做的项目一般最小连接需要是3个，做压力
测试时把连接池设成3，20个线程每线程启动300个session，只要代码没错就没问题。
实施时看客户dbadmin愿意分给我多少连接，改连接池大小。当然越大越快。
CPU, 内存不是主要因素，毕竟数据库就一个。连接数是瓶颈。
一般的程序一个连接也可以满足1000人同时提交数据, 就是慢点, 大家排一个队。
【在 t********k 的大作中提到】
: 【 以下文字转载自 Database 讨论区 】
: 【 原文由 threestick 所发表 】
: 在一般的server上的话能开多少？
: 如果在有四个CPU，2G的小型机上又能开多少？
: 能够满足多少人在线（BS上）提交数据到数据库？
w*r
6 楼
Well, to solve this problem is totally depend on your implementation.
Generally, I would just use a sql execution threadpool and a sqlTaskQueue to
getInstances of the connection and release the instances of connection as soon
as possible in your transaction. Oracle has a connection implementation in its
JDBC pacakage. To gain the maximum throughput, the sql execution threadpool
could be tuned to keep running as fast as possible by keep its connection
instances and only release the connection whe
【在 t********k 的大作中提到】
: 比如我有1万左右的在线用户
: 有时提交数据比较频繁
: 但在平时很空闲
: 一年中可能就一二个月会有大量用户访问
: 在繁忙时只要提交数据成功
: 不要让用户等待很久
: 后台处理放在另外的程序中进行
: 这样的话一台数据库服务器不知能不能承担
Generally, I would just use a sql execution threadpool and a sqlTaskQueue to
getInstances of the connection and release the instances of connection as soon
as possible in your transaction. Oracle has a connection implementation in its
JDBC pacakage. To gain the maximum throughput, the sql execution threadpool
could be tuned to keep running as fast as possible by keep its connection
instances and only release the connection whe
【在 t********k 的大作中提到】
: 比如我有1万左右的在线用户
: 有时提交数据比较频繁
: 但在平时很空闲
: 一年中可能就一二个月会有大量用户访问
: 在繁忙时只要提交数据成功
: 不要让用户等待很久
: 后台处理放在另外的程序中进行
: 这样的话一台数据库服务器不知能不能承担
t*k
7 楼
开1000？
那要多好的硬件水平了？
客户现有的是一台4CPU 2G RAM的机器
在旧系统中4000人在线就要当机
当然旧系统好象是在提交数据后马上进行处理
我们现在做是提交后不马上处理
处理让另外一个程序去做
因而用户提交数据后连接可以马上释放
这可能能缓解好多问题
但不知能不能最终解决提交数据等待问题
谢谢各位的帮助
【在 xt 的大作中提到】
:
: 才10,000? 我认为1000的Connection pool足以胜任.随便哪个DBMS
: 都能开这么多.
那要多好的硬件水平了？
客户现有的是一台4CPU 2G RAM的机器
在旧系统中4000人在线就要当机
当然旧系统好象是在提交数据后马上进行处理
我们现在做是提交后不马上处理
处理让另外一个程序去做
因而用户提交数据后连接可以马上释放
这可能能缓解好多问题
但不知能不能最终解决提交数据等待问题
谢谢各位的帮助
【在 xt 的大作中提到】
:
: 才10,000? 我认为1000的Connection pool足以胜任.随便哪个DBMS
: 都能开这么多.
t*k
8 楼
谢谢
现在还想到一个解决的方法就是
1.在繁忙时（一年中就只有几天时间，一个月左右吧）用高级复制
这样有二台oracle，一台用来读，一台用来写或是二台都能读写
用高级复制的话对硬件的要求不是太高
但听说如果写数据量大的话，高级复制会有很多问题出现
2.用Logical Standby
Logical Standby、的Standby的数据库可以给应用程序读访问
那也行啊，可以缓解好大的压力
但用Standby技术对硬件要求太高
有点儿为难
3.干脆用一个MySQL,e用来进行写
用户提交的数据（只有在一张表中）都先保存到这
而另一程序同时从MySQL中读数据到Oracle里
数据处理放在主数据库Oracle中
但这还是有一个数据不一致性问题
因为数据处理有较强的实时性
根据提交时间的先后排队处理的
上面三个方案哪一个更可行？
【在 w*r 的大作中提到】
: Well, to solve this problem is totally depend on your implementation.
: Generally, I would just use a sql execution threadpool and a sqlTaskQueue to
: getInstances of the connection and release the instances of connection as soon
: as possible in your transaction. Oracle has a connection implementation in its
: JDBC pacakage. To gain the maximum throughput, the sql execution threadpool
: could be tuned to keep running as fast as possible by keep its connection
: instances and only release the connection whe
现在还想到一个解决的方法就是
1.在繁忙时（一年中就只有几天时间，一个月左右吧）用高级复制
这样有二台oracle，一台用来读，一台用来写或是二台都能读写
用高级复制的话对硬件的要求不是太高
但听说如果写数据量大的话，高级复制会有很多问题出现
2.用Logical Standby
Logical Standby、的Standby的数据库可以给应用程序读访问
那也行啊，可以缓解好大的压力
但用Standby技术对硬件要求太高
有点儿为难
3.干脆用一个MySQL,e用来进行写
用户提交的数据（只有在一张表中）都先保存到这
而另一程序同时从MySQL中读数据到Oracle里
数据处理放在主数据库Oracle中
但这还是有一个数据不一致性问题
因为数据处理有较强的实时性
根据提交时间的先后排队处理的
上面三个方案哪一个更可行？
【在 w*r 的大作中提到】
: Well, to solve this problem is totally depend on your implementation.
: Generally, I would just use a sql execution threadpool and a sqlTaskQueue to
: getInstances of the connection and release the instances of connection as soon
: as possible in your transaction. Oracle has a connection implementation in its
: JDBC pacakage. To gain the maximum throughput, the sql execution threadpool
: could be tuned to keep running as fast as possible by keep its connection
: instances and only release the connection whe
w*r
9 楼
dump 3, 3 make things worse, if you need your data updating can be shown in a
sort of "real-time" manner, 3 is definitely not a choice at all. Logical
Standby would not help your performance issue either, I think your solution
could be seperated into several parts, for the application part, you have to
make optimization to release the connection to RDBMS as soon as possible(as I
described several options in last post) for the server side, to improve the
performance, you could try to optimize the
【在 t********k 的大作中提到】
: 谢谢
: 现在还想到一个解决的方法就是
: 1.在繁忙时（一年中就只有几天时间，一个月左右吧）用高级复制
: 这样有二台oracle，一台用来读，一台用来写或是二台都能读写
: 用高级复制的话对硬件的要求不是太高
: 但听说如果写数据量大的话，高级复制会有很多问题出现
: 2.用Logical Standby
: Logical Standby、的Standby的数据库可以给应用程序读访问
: 那也行啊，可以缓解好大的压力
: 但用Standby技术对硬件要求太高
sort of "real-time" manner, 3 is definitely not a choice at all. Logical
Standby would not help your performance issue either, I think your solution
could be seperated into several parts, for the application part, you have to
make optimization to release the connection to RDBMS as soon as possible(as I
described several options in last post) for the server side, to improve the
performance, you could try to optimize the
【在 t********k 的大作中提到】
: 谢谢
: 现在还想到一个解决的方法就是
: 1.在繁忙时（一年中就只有几天时间，一个月左右吧）用高级复制
: 这样有二台oracle，一台用来读，一台用来写或是二台都能读写
: 用高级复制的话对硬件的要求不是太高
: 但听说如果写数据量大的话，高级复制会有很多问题出现
: 2.用Logical Standby
: Logical Standby、的Standby的数据库可以给应用程序读访问
: 那也行啊，可以缓解好大的压力
: 但用Standby技术对硬件要求太高
t*k
10 楼
是啊，第三个是万不得义才会选用的
而且做起来问题多多
RAC是能实现我所需的功能
但RAC的成本太高
客户（国内大学）可能不太会愿意投入太多
当然有些学校财大气粗可以选用此技术
但如果做成一个产品
我们不得不考虑在较低成本方案中选用一个
我估计用Standby或是一些中间件客户都会考虑要不要
因为这些费用不匪啊
难以取舍
非常感谢
据网上一个个朋友告诉我（他是一个Oracle DBA)
只要配置Oracle得当，一台server也能胜任
我去看看AQ之类的东西
能不能解决
再次感谢
【在 w*r 的大作中提到】
: dump 3, 3 make things worse, if you need your data updating can be shown in a
: sort of "real-time" manner, 3 is definitely not a choice at all. Logical
: Standby would not help your performance issue either, I think your solution
: could be seperated into several parts, for the application part, you have to
: make optimization to release the connection to RDBMS as soon as possible(as I
: described several options in last post) for the server side, to improve the
: performance, you could try to optimize the
而且做起来问题多多
RAC是能实现我所需的功能
但RAC的成本太高
客户（国内大学）可能不太会愿意投入太多
当然有些学校财大气粗可以选用此技术
但如果做成一个产品
我们不得不考虑在较低成本方案中选用一个
我估计用Standby或是一些中间件客户都会考虑要不要
因为这些费用不匪啊
难以取舍
非常感谢
据网上一个个朋友告诉我（他是一个Oracle DBA)
只要配置Oracle得当，一台server也能胜任
我去看看AQ之类的东西
能不能解决
再次感谢
【在 w*r 的大作中提到】
: dump 3, 3 make things worse, if you need your data updating can be shown in a
: sort of "real-time" manner, 3 is definitely not a choice at all. Logical
: Standby would not help your performance issue either, I think your solution
: could be seperated into several parts, for the application part, you have to
: make optimization to release the connection to RDBMS as soon as possible(as I
: described several options in last post) for the server side, to improve the
: performance, you could try to optimize the
xt
11 楼
才10,000人,我就不信搞不定.1000的connection pool都浪费.我认为最大256足够用.
我就不信10000人提交数据的速度居然比DBMS存储速度的1/40还快.
我办公室机器1G MEM,开256个connection根本没有问题.
【在 t********k 的大作中提到】
: 谢谢
: 现在还想到一个解决的方法就是
: 1.在繁忙时（一年中就只有几天时间，一个月左右吧）用高级复制
: 这样有二台oracle，一台用来读，一台用来写或是二台都能读写
: 用高级复制的话对硬件的要求不是太高
: 但听说如果写数据量大的话，高级复制会有很多问题出现
: 2.用Logical Standby
: Logical Standby、的Standby的数据库可以给应用程序读访问
: 那也行啊，可以缓解好大的压力
: 但用Standby技术对硬件要求太高
t*k
12 楼
10,000人如果差不多同时提交数据的话呢？
【在 xt 的大作中提到】
:
: 才10,000人,我就不信搞不定.1000的connection pool都浪费.我认为最大256足够用.
: 我就不信10000人提交数据的速度居然比DBMS存储速度的1/40还快.
: 我办公室机器1G MEM,开256个connection根本没有问题.
【在 xt 的大作中提到】
:
: 才10,000人,我就不信搞不定.1000的connection pool都浪费.我认为最大256足够用.
: 我就不信10000人提交数据的速度居然比DBMS存储速度的1/40还快.
: 我办公室机器1G MEM,开256个connection根本没有问题.
xt
13 楼
这种可能性有多大?能持续多久? 你完全可以弄个message queue把
他们排起队来处理.10000个DB Transaction用不多久的.我认为如果
256个连接不够,你的程序设计肯定有问题.
【在 t********k 的大作中提到】
: 10,000人如果差不多同时提交数据的话呢？
t*k
14 楼
但我的要先进先出的
message queue好象是无序的吧？
【在 xt 的大作中提到】
:
: 这种可能性有多大?能持续多久? 你完全可以弄个message queue把
: 他们排起队来处理.10000个DB Transaction用不多久的.我认为如果
: 256个连接不够,你的程序设计肯定有问题.
message queue好象是无序的吧？
【在 xt 的大作中提到】
:
: 这种可能性有多大?能持续多久? 你完全可以弄个message queue把
: 他们排起队来处理.10000个DB Transaction用不多久的.我认为如果
: 256个连接不够,你的程序设计肯定有问题.
xt
15 楼
你自己不会做个有序的?谁告诉你message queue无序?
【在 t********k 的大作中提到】
: 但我的要先进先出的
: message queue好象是无序的吧？
m*t
16 楼
There is a reason people call it a "queue", you know. 8-)
【在 t********k 的大作中提到】
: 但我的要先进先出的
: message queue好象是无序的吧？
相关阅读
请教一段代码，关于hashCode()jtextfield上的listener被触发之前的值怎么读？求好的java开源项目怎样才能跟上技术发展generic 疑问如何确保每次读入的字符串都是unique的When running a .jar file, error message: cannot connect to window serverudacity新课程Introduction to programming in Java分布式看什么annotation一问，如何在编译时处理自定义annotationObject stream & serilization有啥用处？what is really hard is testing被面how to manage heap in java jvmNetbean duplicate class error一个bug竟然是legacy code埋的地雷。高人帮我看看这个网页上面的数据 (转载)我算不算CS啊？做test automation 应该做什么样的java training怎么学习distributed system?Java Map 存 1 million 记录