The truss shows that the problem is most likely on the other end of
the connection, not this end. Dtrace on the client is not going to
help you diagnose the server.
Wesley Naves de faira wrote:
> Well,
> i´m trying connect to Oracle using Listener using the following
> command: sqlplus user/[EMAIL PROTECTED], but this connection is very slow
> about
> 1 minute. Looking for some problem i saw that sqlplus is waiting many
> time to execute this read(...), than i need discovery why the sqlplus
> is waiting of the processes listener to continue connect ou why your
> state is sleeping.
> I think that some script Dtracer that ready some lock´s or
> syscall ou network parameters can help me, because Disk, Proc and
> Memory it not the bottleneck it´s ok.
>
>
> 2008/10/22 Brian Utterback <[EMAIL PROTECTED]>:
>> What are you asking here? The process did a blocking read, and it blocked
>> until there was data to be read, which seems to have happened 49 seconds
>> later. I would suggest that you concentrate on the other end of the
>> connection to see why it isn't sending data for 49 seconds.
>>
>> Or, are you saying that the data was sent and the OS didn't deliver it to
>> the application for 49 seconds?
>>
>> Wesley Naves de faira wrote:
>>> Hi,
>>> i´m a problem with oracle 9.2 / Listener in Solaris 10. When i
>>> connect direct on oracle it´s ok but when i try to connect using port
>>> 1100 on listener the connection is very slow, see truss command that i
>>> did in sqlplus xxx/[EMAIL PROTECTED]:
>>>
>>> 26366: 0.2730 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "",
>>> SOV_DEFAULT) = 8
>>> 26366: 0.2738 connect(8, 0xFFFFFFFF7FFF6284, 16, SOV_DEFAULT) = 0
>>> 26366: 0.2743 getsockname(8, 0xFFFFFFFF7FFF6284, 0xFFFFFFFF7FFF6294,
>>> SOV_DEFAULT) = 0
>>> 26366: 0.2745 setsockopt(8, tcp, TCP_NODELAY, 0xFFFFFFFF7FFF63F4, 4,
>>> SOV_DEFAULT) = 0
>>> 26366: 0.2764 fcntl(8, F_SETFD, 0x00000001) = 0
>>> 26366: 0.2768 brk(0x1003BD570) = 0
>>> 26366: 0.2770 brk(0x1003C1570) = 0
>>> 26366: 0.2791 access("/pcvrdi/oracle/product/920/lib/libnk59.so", F_OK)
>>> = 0
>>> 26366: 0.2802 access("/pcvrdi/oracle/product/920/lib/libngss9.so",
>>> F_OK) Err#2 ENOENT
>>> 26366: 0.2805 access("/pcvrdi/oracle/product/920/lib/libnnts9.so",
>>> F_OK) Err#2 ENOENT
>>> 26366: 0.2808 access("/pcvrdi/oracle/product/920/lib/libnrad9.so", F_OK)
>>> = 0
>>> 26366: 0.2815 sigaction(SIGPIPE, 0xFFFFFFFF7FFF65F0, 0xFFFFFFFF7FFF6718)
>>> = 0
>>> 26366: 0.2822 getpid() = 26366
>>> [26365]
>>> 26366: 0.2828 write(8, "\0 :\0\001\0\0\001 801 ,".., 58) = 58
>>> 26366: 0.2831 write(8, "\0F3\0\006\0\0\0\0\0 ( D".., 243) = 243
>>> 26366: read(8, 0x1003BF926, 2064) (sleeping...)
>>> <------------------------------------------------ THIS
>>> 26366: 49.5211 read(8, "\0\b\0\0\v\0\0\0", 2064) = 8
>>> 26366: 49.5225 write(8, "\0 :\0\001\0\0\001 801 ,".., 58) = 58
>>> 26366: 49.5229 write(8, "\0F3\0\006\0\0\0\0\0 ( D".., 243) = 243
>>> 26366: 49.5233 read(8, "\0 \0\002\0\0\001 8\f01".., 2064) = 32
>>> 26366: 49.5238 getpid() = 26366
>>> [26365]
>>> 26366: 49.5241 write(8, "\09C\0\006\0\0\0\0\0DEAD".., 156) = 156
>>> 26366: 49.5244 read(8, "\07F\0\006\0\0\0\0\0DEAD".., 2064) = 127
>>> 26366: 49.5254 sigaction(SIGTSTP, 0xFFFFFFFF7FFFB680, 0xFFFFFFFF7FFFB7A8)
>>> = 0
>>> 26366: 49.5257 fstat(0, 0xFFFFFFFF7FFFB870) = 0
>>> 26366: 49.5260 ioctl(0, TCGETA, 0xFFFFFFFF7FFFB7AC) = 0
>>> 26366: 49.5263 stat("/dev/tty", 0xFFFFFFFF7FFFB740) = 0
>>> 26366: 49.5266 stat("/dev/console", 0xFFFFFFFF7FFFB740) = 0
>>> 26366: 49.5269 stat("/dev/conslog", 0xFFFFFFFF7FFFB740) = 0
>>> 26366: 49.5273 stat("/dev/syscon", 0xFFFFFFFF7FFFB740) = 0
>>>
>>>
>>>
>>> I think do some dtrace script to look for all lock´s on system to
>>> discovery the root of problem because the CPU/DISK/MEM it´s ok. Other
>>> feature is that the listener process stay sleep all most time on
>>> prstat.
>>>
>>> There are some sugestion ?
>>>
>> --
>> blu
>>
>> "Murderous organizations have increased in size and scope; they are
>> more daring, they are served by the most terrible weapons offered by
>> modern science, and the world is nowadays threatened by new forces
>> which, if recklessly unchained, may some day wreck universal
>> destruction." - Arthur Griffith, 1898
>> ----------------------------------------------------------------------
>> Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
>> Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
>>
>
>
>
--
blu
"Murderous organizations have increased in size and scope; they are
more daring, they are served by the most terrible weapons offered by
modern science, and the world is nowadays threatened by new forces
which, if recklessly unchained, may some day wreck universal
destruction." - Arthur Griffith, 1898
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss@opensolaris.org
