RE: Increasing row retrieving speed via net8
Date: Wed, 18 Apr 2012 09:30:43 +0000
Message-ID: <FFB456FD9AC03C48B943326F553A70AC5044BEF7_at_umaildb2.netcracker.com>
Hi
Why do you think futex calls are your problem? JVM is multi-threaded by default and threads do use different system calls during their life. Doesn't mean your particular Net issue has anything to do with futex calls, which are, as far as I know, ~idle work.
Regards
Timur Akhmadeev
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of GG
Sent: Friday, April 13, 2012 20:02
To: tanel_at_tanelpoder.com
Cc: oracle-l_at_freelists.org
Subject: Re: Increasing row retrieving speed via net8
Making long story short .
After quick talk with OS Admin I got root access :) and first try was (well second because first I was typing rm -rf / too scary him :) :
strace -p _pid_of_pmdtm_binary -f -c
-f is a must because pmdtm makes like 19 threads and they do actual work I saw something like this
time spent 80% -> futex!!
10% poll
5 % read
5% other stuff .
so only 5% of work time socket was read and most of the time threads was fighting each other in somekind of concurency issue :) or feature .
So that explains why messing with sdu , socket buffers, tcp stack buffers and so on gave only minor changes in rows fetched per sec from that tool .
Comparing that to sqlplus , strace gives something like that:
time spent syscall
99% read
1 % write
Funny thing is You have to find 'sweet spot' when setting above net stack / net8 related parameters, its not about simply increasing them :). You can observe how things are going with strace on sqlplus and checking read syscall arguments , and how they are changing when You messing for example with sdu size . Tcpdump is quite useful and snapper of coz as we are DBAs . Just remember with 1500 MTU You cant do much , I think jumbo frames and/or GBit interface is the way to go if cant afford You can do parallelizm via opening many connections and aggregate them in 'smart' way . Thanks for all comments, now its time for Informatica vendor response :).
Regards
GregG
--
http://www.freelists.org/webpage/oracle-l
The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
--
http://www.freelists.org/webpage/oracle-l Received on Wed Apr 18 2012 - 04:30:43 CDT