Delay in commands returning ✗ Answered: red (solid confidence) — Several plausible diagnostic avenues are suggested (truss, onstat -g spi, auditing, GLS/msg file opens, general startup-time comparison) but the thread ends without anyone identifying the actual cause or confirming a fix.

Advisory only.

Delay before resonding to commands. On a certain server type (Sun M9000), and maybe others, I get about a second's delay issuing any onstat command ... even onstat -m. See below, took about one second. On any other server - a Sun v890, a Linux server, it takes a few millseconds. I've tried a shared-memory rather than TCP/IP connection. No difference. It doesn't seem to be causing any issue, I'm just curious ... Thanks Neil ***************************************************************************** -bash-3.00$ time onstat -p IBM Informix Dynamic Server Version 10.00.FC9 -- On-Line -- Up 00:02:41 -- 25968640 Kbytes Profile dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits %cached 7256 7738 161766 95.51 141 141 32 0.00 isamtot open start read write rewrite delete commit rollbk 165785 8971 16332 54645 0 0 0 0 0 gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs 0 0 0 0 0 0 0 ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes 0 0 0 29.99 48.62 1 4 bufwaits lokwaits lockreqs deadlks dltouts ckpwaits compress seqscans 0 0 127852 0 0 0 8 5 ixda-RA idx-RA da-RA RA-pgsused lchwaits 0 0 184 184 54368 real 0m1.027s user 0m0.006s sys 0m0.014s

On 21 Oct, 19:26, "Neil Truby" <neil.tr...@ardenta.com> wrote: > Delay before resonding to commands. > > On a certain server type (Sun M9000), and maybe others, I get about a > second's delay issuing any onstat command ... even onstat -m.  See below, > took about one second. > > On any other server - a Sun v890, a Linux server, it takes a few > millseconds. > > I've tried a shared-memory rather than TCP/IP connection.  No difference. > > It doesn't seem to be causing any issue, I'm just curious ... > > Thanks > Neil > ***************************************************************************** > -bash-3.00$ time onstat -p > > IBM Informix Dynamic Server Version 10.00.FC9     -- On-Line -- Up > 00:02:41 -- 25968640 Kbytes> > Profile > dskreads   pagreads   bufreads   %cached dskwrits   pagwrits   bufwrits > %cached > 7256       7738       161766     95.51   141        141        32 > 0.00 > > isamtot    open       start      read       write      rewrite    delete > commit     rollbk > 165785     8971       16332      54645      0          0          0 > 0          0 > > gp_read    gp_write   gp_rewrt   gp_del     gp_alloc   gp_free    gp_curs > 0          0          0          0          0          0          0 > > ovlock     ovuserthread ovbuff     usercpu  syscpu   numckpts   flushes > 0          0            0          29.99    48.62    1          4 > > bufwaits   lokwaits   lockreqs   deadlks    dltouts    ckpwaits   compress > seqscans > 0          0          127852     0          0          0          8 > 5 > > ixda-RA    idx-RA     da-RA      RA-pgsused lchwaits > 0          0          184        184        54368 > > real    0m1.027s > user    0m0.006s > sys     0m0.014s Well onstat just attaches to shared memory so the connection type is irrelevant. What about "time onstat -" how long does that take?? Before hand do onstat -z then onstat -g spi afterwards, what latches are taken? Try truss -d onstat - where is the time taken? onstat, at least for version 7 seems to open and close a lot of files under $INFORMIXDIR/gls and $INFORMIXDIR/msg

Neil Truby wrote: > Delay before resonding to commands. > > On a certain server type (Sun M9000), and maybe others, I get about a > second's delay issuing any onstat command ... even onstat -m. See > below, took about one second. > > On any other server - a Sun v890, a Linux server, it takes a few > millseconds. > > I've tried a shared-memory rather than TCP/IP connection. No difference. > > It doesn't seem to be causing any issue, I'm just curious ... > > Thanks > Neil > ***************************************************************************** > > -bash-3.00$ time onstat -p > > IBM Informix Dynamic Server Version 10.00.FC9 -- On-Line -- Up > 00:02:41 -- 25968640 Kbytes> > Profile > dskreads pagreads bufreads %cached dskwrits pagwrits bufwrits > %cached > 7256 7738 161766 95.51 141 141 32 0.00 > > isamtot open start read write rewrite delete > commit rollbk > 165785 8971 16332 54645 0 0 0 > 0 0 > > gp_read gp_write gp_rewrt gp_del gp_alloc gp_free gp_curs > 0 0 0 0 0 0 0 > > ovlock ovuserthread ovbuff usercpu syscpu numckpts flushes > 0 0 0 29.99 48.62 1 4 > > bufwaits lokwaits lockreqs deadlks dltouts ckpwaits > compress seqscans > 0 0 127852 0 0 0 8 5 > > ixda-RA idx-RA da-RA RA-pgsused lchwaits > 0 0 184 184 54368 > > > real 0m1.027s > user 0m0.006s > sys 0m0.014s > Do you have auditing turned on? I assume not, but just in case...? Regards.

what about startup times of simple things like vi? Is it a machine difference? Longer $PATH or $LD_LIBRARY_PATH with more or less to wade through? OS differences in the the implementation of "sticky" executables (ie retaining the executable in memory on the off-chance it will be called again) or maybe on one platform it's more expensive to attach to shared libraries; onstat probably attaches to several while vi probably doesn't... There's a process tracing tool that shows the system calls although the name escapes me. You could probably use that to know which part of program startup is taking the most time.