stream目前性能很糟糕

tom_fans

用多个apply process我现在就是这样，我的意思是当繁忙情况，stream导致apply那台服务器load很高，当然这并没有影响我的capture那台机器。

我只是想说stream导致的apply那台机器load很高，那么我原先考虑的读写分离的技术stream不可用。

ward

晕的我怕怕，我还正准备用呢，实现读写分离，看来stream要抛弃了，但是到底用啥呢？！

jyzhao

stream技术还不是很成熟，不知道12g在这方面有没有改进

itpub.com.cn

原帖由 netbanker 于 2009-2-16 14:04 发表
I am not tallking about apply parallel, I am talking about more apply processes

我说的apply 并行指的就是使用多个apply processes,我可没说apply processes并行啊

orablue

原帖由 netbanker 于 2009-2-16 14:04 发表
I am not tallking about apply parallel, I am talking about more apply processes

支持这个建议,另外,可以在条件容许的情况下,将内存也调大一点.

tom_fans

我16G内存，加内存你说加多少？ 分配内存我都尽量多份一点的。  有人说用多个apply process，首先我就是建立多个apply process。服务器load非常大和用几个apply 没太大关系。

其实问题在于apply dequeue，然后应用的时候会增加服务器负担。 如果能减小这个负担，我想stream还是非常好的

orablue

1,PARALLEL_MAX_SERVERS 和APPLY PROCESS
2,INITRANS and PCTFREE parameters
3,APPLY PROCESS 需要的内存可以大一点.

netbanker

原帖由 itpub.com.cn 于 2009-2-18 09:22 发表

我说的apply 并行指的就是使用多个apply processes,我可没说apply processes并行啊

can you show us why the bottleneck is in dequeue? you mean you have only one queue table for all apply process?

netbanker

原帖由 tom_fans 于 2009-2-19 15:09 发表
我16G内存，加内存你说加多少？ 分配内存我都尽量多份一点的。  有人说用多个apply process，首先我就是建立多个apply process。服务器load非常大和用几个apply 没太大关系。

其实问题在于apply dequeue，然后应用的时候会增加服务器负担。 如果能减小这个负担，我想stream还是非常好的

if want to a donkey to run 100miles/hr, it is not realistic. if it is something about hardware, nobody can help you

shiri512003

也在看streams，这东西还是有点意思的，随着该产品的成熟度越来越高，加上成本上的巨大优势，还是很有前途的
呵呵