Re: running out of Unix Shared memory segments
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
<body text="#000000" bgcolor="#FFFFFF" link="#0000FF" vlink="#800080" alink="#FF0080">
<tt>Here is an interesting problem we encountered. (IDS 7.24)</tt><tt></tt>
<p><tt>I tried to use 'update statistics MEDIUM or HIGN for table(col)'</tt><tt></tt>
<p><tt>Informix said this would help.... but this statement ran on all
my table cols with</tt>
<br><tt>indexes caused the engine to go out and grab TONS of virtual memory!</tt><tt></tt>
<p><tt>apparently it stores these statistics in memory.....</tt><tt></tt>
<p><tt>I had to abort my attempts at update statistics on specific columns.</tt>
<br><tt>there is an obscure reference in the documentation that says..</tt>
<br><tt>'add about 4 MEG of memory before doing col-sepcific update stats'.</tt><tt></tt>
<p><tt>also</tt>
<br><tt>use onmode -F to attempt to free up memory segments.</tt>
<br><tt></tt> <tt></tt>
<p><tt>abr</tt><tt></tt>
<p><tt>Seepz wrote:</tt>
<blockquote TYPE=CITE><tt>I have got a couple of queries .</tt>
<br><tt>[We are currently running Informix version 7.11 on Digital Unix.
]</tt><tt></tt>
<p><tt>1. Frequently the following error message gets logged to the informix</tt>
<br><tt>online.log :</tt>
<br><tt>shmat: [EMFILE] [24]: out of shared memory segments, check system
SHMSEG.</tt>
<br><tt>Whenever we get this kind of error message the machine either
tends to slow</tt>
<br><tt>down extremely or freeze up. We are then forced to re initialize
Informix .</tt>
<br><tt>Can anyone give me a suggestion as to how to avoid this kind of
errors or how</tt>
<br><tt>to set up SHMSEG ?</tt><tt></tt>
<p><tt>2. Also we tend to get the following error message frequently while
running any</tt>
<br><tt>Unix Shell scripts : " out of swap space" . Any suggestions on
this ?</tt><tt></tt>
<p><tt>3. Ours is basically a telecom set up and we connect to Unix / informix
thro' a</tt>
<br><tt>T1 connection . Whenever the machine freezes up, we are denied
login to the</tt>
<br><tt>unix box. Whenever this happens no errors are logged onto the informix</tt>
<br><tt>online.log. Is there any way to know whether its unix or Informix
at fault for</tt>
<br><tt>the freeze up ?</tt><tt></tt>
<p><tt>Any help would be appreciated.</tt>
<br><tt>Jim</tt></blockquote>
<tt></tt><tt></tt>
<p><tt>--</tt>
<br><tt>Adam Richards, MCI WorldCom - V622-1328 - 719-535-1328</tt>
<br><tt>WWW: <A HREF="http://166.37.1.157/">http://166.37.1.157/</A></tt>;
<br><tt>EMAIL: adam.richards@wcom.com</tt>
<br><tt></tt>
</body>
</html>
Adam Richards wrote: > > Here is an interesting problem we encountered. (IDS 7.24) > > I tried to use 'update statistics MEDIUM or HIGN for table(col)' > > Informix said this would help.... but this statement ran on all my table cols > with > indexes caused the engine to go out and grab TONS of virtual memory! > > apparently it stores these statistics in memory..... > > I had to abort my attempts at update statistics on specific columns. > there is an obscure reference in the documentation that says.. > 'add about 4 MEG of memory before doing col-sepcific update stats'. The virtual memory allocation if for sort-work buffers. You can reduce the amount of such memory required by: 1) Only update statistics HIGH on a single column at a time, doing a MEDIUM on the whole table should not be as bad. 2) Reduce the resolution of the MEDIUMs you are doing. 3) Reduce the values of PDQPRIORITY and PSORT_NPROCS this will make the update stats run longer by allocating fewer sort threads each of which need sort-work memory areas. Art S. Kagel
Art, thanks fro your reply. i would like to do a HIGH on all lead column indexes. can you give me an example of syntax for setting PDQ and the PSORT_NPROCS? your help is appreciated. adam "Art S. Kagel" wrote: > Adam Richards wrote: > > > > Here is an interesting problem we encountered. (IDS 7.24) > > > > I tried to use 'update statistics MEDIUM or HIGN for table(col)' > > > > Informix said this would help.... but this statement ran on all my table cols > > with > > indexes caused the engine to go out and grab TONS of virtual memory! > > > > apparently it stores these statistics in memory..... > > > > I had to abort my attempts at update statistics on specific columns. > > there is an obscure reference in the documentation that says.. > > 'add about 4 MEG of memory before doing col-sepcific update stats'. > > The virtual memory allocation if for sort-work buffers. You can reduce > the amount of such memory required by: > > 1) Only update statistics HIGH on a single column at a time, doing a > MEDIUM on the whole table should not be as bad. > > 2) Reduce the resolution of the MEDIUMs you are doing. > > 3) Reduce the values of PDQPRIORITY and PSORT_NPROCS this will make the > update stats run longer by allocating fewer sort threads each of which > need sort-work memory areas. > > Art S. Kagel -- Adam Richards, MCI WorldCom - V622-1328 - 719-535-1328 WWW: http://166.37.1.157/ EMAIL: adam.richards@wcom.com