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/xxx at DB:
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 ?
--
+++++++++++++++++++++++++++++++++++++++++++++++
Wesley Naves de Faria
Analista de Suporte
SCSA - Sun Certified System Administrator for Solaris 10
SCNA - Sun Certified Network Administrator for Solaris 10
FreeBSD / OpenBSD / Linux
+++++++++++++++++++++++++++++++++++++++++++++++
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/xxx at DB: > > 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
Well,
i?m trying connect to Oracle using Listener using the following
command: sqlplus user/pass at DB, 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 <brian.utterback at
sun.com>:> 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/xxx at DB:
>>
>> 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
>
--
+++++++++++++++++++++++++++++++++++++++++++++++
Wesley Naves de Faria
Analista de Suporte
SCSA - Sun Certified System Administrator for Solaris 10
SCNA - Sun Certified Network Administrator for Solaris 10
FreeBSD / OpenBSD / Linux
+++++++++++++++++++++++++++++++++++++++++++++++
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/pass at DB, 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 <brian.utterback at sun.com>: >> 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/xxx at DB: >>> >>> 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
Thank?s,
now the tnslsnr on server is starter an there are 2792
connections. I need do a script to identify/filter only one connect to
analyse, but i don?t know where to begin to split the connections.
> 2008/10/22 Brian Utterback <brian.utterback at sun.com>:
>> 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/pass at DB, 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 <brian.utterback at sun.com>:
>>>>
>>>> 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/xxx at DB:
>>>>>
>>>>> 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
>>
>
>
>
> --
> +++++++++++++++++++++++++++++++++++++++++++++++
> Wesley Naves de Faria
> Analista de Suporte
> SCSA - Sun Certified System Administrator for Solaris 10
> SCNA - Sun Certified Network Administrator for Solaris 10
> FreeBSD / OpenBSD / Linux
> +++++++++++++++++++++++++++++++++++++++++++++++
>
--
+++++++++++++++++++++++++++++++++++++++++++++++
Wesley Naves de Faria
Analista de Suporte
SCSA - Sun Certified System Administrator for Solaris 10
SCNA - Sun Certified Network Administrator for Solaris 10
FreeBSD / OpenBSD / Linux
+++++++++++++++++++++++++++++++++++++++++++++++
Have you already checked name resolution in your network?
Try to configure your listener using the fully qualified domain name.
Regards.
-----Mensagem original-----
De: dtrace-discuss-bounces at opensolaris.org
[mailto:dtrace-discuss-bounces at opensolaris.org] Em nome de Wesley Naves de
faira
Enviada em: quarta-feira, 22 de outubro de 2008 13:31
Para: Brian Utterback
Cc: dtrace-discuss at opensolaris.org
Assunto: Re: [dtrace-discuss] function read sleeping
Well,
i?m trying connect to Oracle using Listener using the following
command: sqlplus user/pass at DB, 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 <brian.utterback at
sun.com>:> 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/xxx at DB:
>>
>> 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
>
--
+++++++++++++++++++++++++++++++++++++++++++++++
Wesley Naves de Faria
Analista de Suporte
SCSA - Sun Certified System Administrator for Solaris 10
SCNA - Sun Certified Network Administrator for Solaris 10
FreeBSD / OpenBSD / Linux
+++++++++++++++++++++++++++++++++++++++++++++++
_______________________________________________
dtrace-discuss mailing list
dtrace-discuss at opensolaris.org