Cool, There was a reason why I stated "fetch more rows at a time" as the #1 item to fix.... The TCP buffer and SDU size tweaking does not help much when your main wait event is "SQL*Net message from client". The TCP buffer and SDU size tweaking would help to reduce the "SQL*Net more data to client" waits though, assuming that your link still has bandwidth left. If it doesn't no need to bother... Tanel. On Tue, Apr 17, 2012 at 6:39 PM, GG <grzegorzof@xxxxxxxxxx> wrote: > W dniu 2012-04-16 20:13, Tanel Poder pisze: > >> And if you're wondering, how come it's possible that 10 x application >> connections can retrieve 10 x more than a single application connection - >> this is why I listed the Bandwidth Delay Product as #2 in the list. If you >> have too small TCP buffer sizes for your network latency (delay) and link >> max theoretical throughput (bandwidth) then this buffer size ends up >> throttling your TCP connection throughput. The reason - TCP is a reliable >> protocol, thus a TCP packet can not be discarded from the TCP send buffer >> before an ACK has arrived for at least that packet sequence number (or >> higher). So, the higher the network latency (time to get ACK) and the lower >> the TCP buffer size, the lower your connection's throughput will be >> throttled to. >> >> With 10 x connections however, each connection have their own TCP >> send/receive buffers, thus the aggregate throughput for all the connections >> is 10 x higher. >> > Well , it was about buffers but not tcp at least not in that moment :). > Informatica got its own buffers: > *DTM Buffer Cache and DTM Buffer Block size > and default values are not optimal for large (270 columns) row sources. > Looks like with that buffers You can scale fetch size and with 200MB > buffer I was having 400k fetch size :) . > Now I can saturated 100Mbit with 1 connection :) > So now its time to play with tcp/ip stack / sdu buffers when we finished > with application . > Still dont know how strace looks like now , probably get root tomorrow :). > Regards > GregG > > > * > -- //www.freelists.org/webpage/oracle-l