Have you already checked name resolution in your network? Try to configure your listener using the fully qualified domain name.
Regards. -----Mensagem original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Em nome de Wesley Naves de faira Enviada em: quarta-feira, 22 de outubro de 2008 13:31 Para: Brian Utterback Cc: dtrace-discuss@opensolaris.org Assunto: Re: [dtrace-discuss] function read sleeping 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 > -- +++++++++++++++++++++++++++++++++++++++++++++++ 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@opensolaris.org _______________________________________________ dtrace-discuss mailing list dtrace-discuss@opensolaris.org
