Informix Shared Memory Problem
Posted in 2011
A 32-bit IDS 9.30 instance on 32-bit PAE Linux (Scientific Linux 5.5) kept adding virtual shared-memory segments until shmat failed with ENOMEM ('out of available data space, check system MAXMEM') and connections were rejected, roughly when the attached segments filled the process address space around 2GB. SHMBASE had been moved to 0x44000000. Art Kagel suggested the issue was too many small segments: raise SHMMAX/SHMMNI via sysctl and increase SHMVIRTSIZE so memory is one larger segment rather than many; another poster suggested IFX_AUTOFREE for client connections. The poster was using periodic 'onmode -F' as a workaround and ended the thread thanking Kagel, so no confirmed fix is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
Topics: Platform-Specific Issues
Hi, I've a serious problem on Informix and I someone can help me. The problem arise on a machine with: Kenel version: 2.6.18-194.32.1.el5PAE #1 SMP on a Scientific Linux 5.5 (like RHEL 5.5) Informix version: Informix Dynamic Server Version 9.30.UC2 -- On-Line -- Up 02:30:49 -- 238284 Kbytes I've set SHMBASE to 0x44000000L and everything worked fine for about 5 days. The cat /proc/8602/maps is: 50ece000-516ce000 rw-s 00000000 00:09 42303502 /SYSV52594807 (deleted) 516ce000-51ece000 rw-s 00000000 00:09 42336271 /SYSV52594808 (deleted) 51ece000-528b3000 rw-s 00000000 00:09 42369040 /SYSV52594809 (deleted) ...... b7f0f000-b7f10000 rw-p b7f0f000 00:00 0 The problem occurs when the shared memory reaches the limit b7f0f000-b7f10000 in this case i've the messagge: 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system MAXMEM 06:32:32 shmdt: errno = 22 06:32:32 create_tcb: cannot allocate memory 06:32:32 (6972) connection rejected - too many users, or invalid user name 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system MAXMEM 06:32:32 shmdt: errno = 22 06:32:32 create_tcb: cannot allocate memory 06:32:32 (6973) connection rejected - too many users, or invalid user name 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system MAXMEM The value of kernel parameters are: cat /proc/sys/kernel/shmall 268435456 cat /proc/sys/kernel/shmmax 4294967295 The Informix version is a 32 bit, but the machine have 8290068k of memory! Can be a problem for an older 32bit version of Informix to work on a machine with more than 2 GB ? Can you help me ? At the moment we can change our version of informix for compatibility with our cobol prg! Thanks in advance for your help, Francesco.
What SHMBASE is recommended in the release notes? Art Art S. Kagel Advanced DataTools (www.advancedatatools.com) IIUG Board of Directors (art@iiug.org) Blog: http://informix-myview.blogspot.com/ Disclaimer: Please keep in mind that my own opinions are my own opinions and do not reflect on my employer, Advanced DataTools, the IIUG, nor any other organization with which I am associated either explicitly, implicitly, or by inference. Neither do those opinions reflect those of other individuals affiliated with any entity with which I am affiliated nor those of the entities themselves. On Tue, Feb 15, 2011 at 5:17 AM, Francesco Alfano <edacedpa@yahoo.it> wrote: > Hi, > I've a serious problem on Informix and I someone can help me. > > The problem arise on a machine with: > Kenel version: > 2.6.18-194.32.1.el5PAE #1 SMP on a Scientific Linux 5.5 (like RHEL 5.5) > > Informix version: > Informix Dynamic Server Version 9.30.UC2 -- On-Line -- Up 02:30:49 > -- 238284 Kbytes > > I've set SHMBASE to 0x44000000L and everything worked fine for about 5 > days. > > The cat /proc/8602/maps is: > 50ece000-516ce000 rw-s 00000000 00:09 42303502 /SYSV52594807 (deleted) > 516ce000-51ece000 rw-s 00000000 00:09 42336271 /SYSV52594808 (deleted) > 51ece000-528b3000 rw-s 00000000 00:09 42369040 /SYSV52594809 (deleted) > ....... > b7f0f000-b7f10000 rw-p b7f0f000 00:00 0 > > The problem occurs when the shared memory reaches the limit > b7f0f000-b7f10000 in this case i've the messagge: > 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system > MAXMEM > > 06:32:32 shmdt: errno = 22 > 06:32:32 create_tcb: cannot allocate memory > > 06:32:32 (6972) connection rejected - too many users, or invalid user name > 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system > MAXMEM > > 06:32:32 shmdt: errno = 22 > 06:32:32 create_tcb: cannot allocate memory > > 06:32:32 (6973) connection rejected - too many users, or invalid user name > 06:32:32 shmat: [ENOMEM][12]: out of available data space, check system > MAXMEM > > The value of kernel parameters are: > cat /proc/sys/kernel/shmall > 268435456 > > cat /proc/sys/kernel/shmmax > 4294967295 > > The Informix version is a 32 bit, but the machine have 8290068k of > memory! Can be a problem for an older 32bit version of Informix to work > on a machine with more than 2 GB ? > > Can you help me ? At the moment we can change our version of informix > for compatibility with our cobol prg! > > Thanks in advance for your help, Francesco. > > > > ******************************************************************************* > Forum Note: Use "Reply" to post a response in the discussion forum. > > --0015175ce020a2d0d4049c501bd5
Il 15/02/2011 12:03, Art Kagel ha scritto:
> What SHMBASE is recommended in the release notes?
>
> Art
>
> Art S. Kagel
> Advanced DataTools (www.advancedatatools.com)
> IIUG Board of Directors (art@iiug.org)
> Blog: http://informix-myview.blogspot.com/
It's
SHMBASE 0x10000000L
but on RHEL 5.5 it better put to x44000000L see below:
cat /proc/8602/maps
00048000-00053000 r-xp 00000000 fd:00 15335975 /opt/informix/bin/oninit
00053000-00056000 rw-p 0000a000 fd:00 15335975 /opt/informix/bin/oninit
00056000-0005f000 rw-p 00056000 00:00 0
00f5f000-00f60000 r-xp 00f5f000 00:00 0 [vdso]
08048000-0870e000 r-xp 08048000 00:00 0
0870e000-0883a000 rw-p 00e12000 fd:00 15335975 /opt/informix/bin/oninit
0883a000-0889a000 rw-p 0883a000 00:00 0
08b60000-08b66000 rw-p 08b60000 00:00 0 [heap]
42000000-4212c000 r-xp 42000000 00:00 0
4212c000-42131000 rw-p 005f7000 fd:00 15335975 /opt/informix/bin/oninit
42131000-42135000 rw-p 42131000 00:00 0
44000000-4e172000 rw-s 00000000 00:09 42106882 /SYSV52594801 (deleted)
4e172000-4e942000 rw-s 00000000 00:09 42139652 /SYSV52594802 (deleted)
4e942000-4f304000 rw-s 00000000 00:09 42172422 /SYSV52594803 (deleted)
4f304000-4fce9000 rw-s 00000000 00:09 42205191 /SYSV52594804 (deleted)
4fce9000-506ce000 rw-s 00000000 00:09 42237960 /SYSV52594805 (deleted)
506ce000-50ece000 rw-s 00000000 00:09 42270733 /SYSV52594806 (deleted)
b7f0f000-b7f10000 rw-p b7f0f000 00:00 0
b7f10000-b7f19000 r-xp b7f10000 00:00 0
b7f19000-b7f1a000 rw-p 0020d000 fd:00 15335975 /opt/informix/bin/oninit
b7f1a000-b7f1b000 rw-p b7f1a000 00:00 0
b7f1b000-b7f20000 r-xp b7f1b000 00:00 0
b7f20000-b7f21000 rw-p 000e0000 fd:00 15335975 /opt/informix/bin/oninit
b7f21000-b7f48000 rw-p b7f21000 00:00 0
b7f48000-b7f4a000 r-xp b7f48000 00:00 0
b7f4a000-b7f4b000 rw-p 001c5000 fd:00 15335975 /opt/informix/bin/oninit
b7f4b000-b7f6c000 r-xp b7f4b000 00:00 0
b7f6c000-b7f6d000 rw-p 00642000 fd:00 15335975 /opt/informix/bin/oninit
b7f6d000-b7f6e000 r-xp b7f6d000 00:00 0
b7f6e000-b7f6f000 rw-p 00667000 fd:00 15335975 /opt/informix/bin/oninit
b7f6f000-b7f7c000 r-xp b7f6f000 00:00 0
b7f7c000-b7f83000 rw-p 0065a000 fd:00 15335975 /opt/informix/bin/oninit
b7f83000-b7f84000 rw-p b7f83000 00:00 0
b7f84000-b7f85000 r-xp b7f84000 00:00 0
b7f85000-b7f86000 rw-p 00666000 fd:00 15335975 /opt/informix/bin/oninit
b7f86000-b7f99000 r-xp b7f86000 00:00 0
b7f99000-b7f9a000 rw-p 000d9000 fd:00 15335975 /opt/informix/bin/oninit
b7f9a000-b7f9d000 r--p 0000e000 fd:00 15335975 /opt/informix/bin/oninit
bffb0000-bffea000 rw-p bffc4000 00:00 0 [stack]
I may have solved the problem by using periodically onmode -F to free
shared memory.
Thanks for your response.
Is it possible that the problem is that you have too many shared memory
segments? There is a kernel parameter to set the maximum number of shared
segments per process. You can adjust that. If that's the problem, another
solution would be to increase the SHMVIRTSIZE parameter in the ONCONFIG file
to fold in all of those additional segments your instance is allocating so
that you have just one larger segment instead. On Linux a 32bit Informix
should be able to address at least 3.5GB and you only seem to have about
300MB allocated to this instance.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Tue, Feb 15, 2011 at 6:13 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 15/02/2011 12:03, Art Kagel ha scritto:
> > What SHMBASE is recommended in the release notes?
> >
> > Art
> >
> > Art S. Kagel
> > Advanced DataTools (www.advancedatatools.com)
> > IIUG Board of Directors (art@iiug.org)
> > Blog: http://informix-myview.blogspot.com/
>
> It's
>
> SHMBASE 0x10000000L>
> but on RHEL 5.5 it better put to x44000000L see below:
>
> cat /proc/8602/maps
> 00048000-00053000 r-xp 00000000 fd:00 15335975 /opt/informix/bin/oninit
> 00053000-00056000 rw-p 0000a000 fd:00 15335975 /opt/informix/bin/oninit
> 00056000-0005f000 rw-p 00056000 00:00 0
> 00f5f000-00f60000 r-xp 00f5f000 00:00 0 [vdso]
> 08048000-0870e000 r-xp 08048000 00:00 0
> 0870e000-0883a000 rw-p 00e12000 fd:00 15335975 /opt/informix/bin/oninit
> 0883a000-0889a000 rw-p 0883a000 00:00 0
> 08b60000-08b66000 rw-p 08b60000 00:00 0 [heap]
> 42000000-4212c000 r-xp 42000000 00:00 0
> 4212c000-42131000 rw-p 005f7000 fd:00 15335975 /opt/informix/bin/oninit
> 42131000-42135000 rw-p 42131000 00:00 0
> 44000000-4e172000 rw-s 00000000 00:09 42106882 /SYSV52594801 (deleted)
> 4e172000-4e942000 rw-s 00000000 00:09 42139652 /SYSV52594802 (deleted)
> 4e942000-4f304000 rw-s 00000000 00:09 42172422 /SYSV52594803 (deleted)
> 4f304000-4fce9000 rw-s 00000000 00:09 42205191 /SYSV52594804 (deleted)
> 4fce9000-506ce000 rw-s 00000000 00:09 42237960 /SYSV52594805 (deleted)
> 506ce000-50ece000 rw-s 00000000 00:09 42270733 /SYSV52594806 (deleted)
> b7f0f000-b7f10000 rw-p b7f0f000 00:00 0
> b7f10000-b7f19000 r-xp b7f10000 00:00 0
> b7f19000-b7f1a000 rw-p 0020d000 fd:00 15335975 /opt/informix/bin/oninit
> b7f1a000-b7f1b000 rw-p b7f1a000 00:00 0
> b7f1b000-b7f20000 r-xp b7f1b000 00:00 0
> b7f20000-b7f21000 rw-p 000e0000 fd:00 15335975 /opt/informix/bin/oninit
> b7f21000-b7f48000 rw-p b7f21000 00:00 0
> b7f48000-b7f4a000 r-xp b7f48000 00:00 0
> b7f4a000-b7f4b000 rw-p 001c5000 fd:00 15335975 /opt/informix/bin/oninit
> b7f4b000-b7f6c000 r-xp b7f4b000 00:00 0
> b7f6c000-b7f6d000 rw-p 00642000 fd:00 15335975 /opt/informix/bin/oninit
> b7f6d000-b7f6e000 r-xp b7f6d000 00:00 0
> b7f6e000-b7f6f000 rw-p 00667000 fd:00 15335975 /opt/informix/bin/oninit
> b7f6f000-b7f7c000 r-xp b7f6f000 00:00 0
> b7f7c000-b7f83000 rw-p 0065a000 fd:00 15335975 /opt/informix/bin/oninit
> b7f83000-b7f84000 rw-p b7f83000 00:00 0
> b7f84000-b7f85000 r-xp b7f84000 00:00 0
> b7f85000-b7f86000 rw-p 00666000 fd:00 15335975 /opt/informix/bin/oninit
> b7f86000-b7f99000 r-xp b7f86000 00:00 0
> b7f99000-b7f9a000 rw-p 000d9000 fd:00 15335975 /opt/informix/bin/oninit
> b7f9a000-b7f9d000 r--p 0000e000 fd:00 15335975 /opt/informix/bin/oninit
> bffb0000-bffea000 rw-p bffc4000 00:00 0 [stack]
>
> I may have solved the problem by using periodically onmode -F to free
> shared memory.
>
> Thanks for your response.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--0015175ce020d4290a049c50683f
Il 15/02/2011 12:24, Art Kagel ha scritto:
> Is it possible that the problem is that you have too many shared memory
> segments? There is a kernel parameter to set the maximum number of shared
> segments per process. You can adjust that. If that's the problem, another
> solution would be to increase the SHMVIRTSIZE parameter in the ONCONFIG file
> to fold in all of those additional segments your instance is allocating so
> that you have just one larger segment instead. On Linux a 32bit Informix
> should be able to address at least 3.5GB and you only seem to have about
> 300MB allocated to this instance.
>
In this instance there about 300 Mb because i've restarted Informix.
If i've increase SHMVIRTSIZE parameter when i've freed shared memory
with onmode -F, probably i've freed less memory because the segments are
partiallly used. It's correct ?
How can i set the maximum number of shared segment ?
Thanks for your response.
You may have to increase SHMMNI & SHMMAX with sysctl. See:
http://eloquence.marxmeier.com/sdb/html/linux_limits.html
and other references on doing this.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Tue, Feb 15, 2011 at 6:45 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 15/02/2011 12:24, Art Kagel ha scritto:
> > Is it possible that the problem is that you have too many shared memory
> > segments? There is a kernel parameter to set the maximum number of shared
> > segments per process. You can adjust that. If that's the problem, another
> > solution would be to increase the SHMVIRTSIZE parameter in the ONCONFIG
> file
> > to fold in all of those additional segments your instance is allocating
> so
> > that you have just one larger segment instead. On Linux a 32bit Informix
> > should be able to address at least 3.5GB and you only seem to have about
> > 300MB allocated to this instance.
> >
>
> In this instance there about 300 Mb because i've restarted Informix.
>
> If i've increase SHMVIRTSIZE parameter when i've freed shared memory
> with onmode -F, probably i've freed less memory because the segments are
> partiallly used. It's correct ?
>
> How can i set the maximum number of shared segment ?
>
> Thanks for your response.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--0015175cb2c65b181f049c522209
Il 15/02/2011 14:28, Art Kagel ha scritto:
> You may have to increase SHMMNI& SHMMAX with sysctl. See:
> http://eloquence.marxmeier.com/sdb/html/linux_limits.html
> and other references on doing this.
>
> Art
>
Thanks for your response, but my shmmax is 4294967295 and the problem
arise when the total allocated virtual segment is about 2 Gb!
It isn't a good solution to run "onmode -F" periodically ?
Thanks for you response.
As I suggested, did you check your SHMMNI setting, the number of segments
per process? It can't hurt to run onmode -F periodically, but if those
memory segments keep showing up again, then the memory is needed by the
engine to process queries, so you may as well fold those additional segments
into SHMVIRTSIZE and keep the memory permanently.
Also, you are aware that Informix 9.30 dates from 2000 and is well
out-of-support, right? You should upgrade to the 11.50 or 11.70 version.
There have been 4 or 5 rounds of performance improvements and lots of new
features since 9.30.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Tue, Feb 15, 2011 at 8:39 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 15/02/2011 14:28, Art Kagel ha scritto:
> > You may have to increase SHMMNI& SHMMAX with sysctl. See:
> > http://eloquence.marxmeier.com/sdb/html/linux_limits.html
> > and other references on doing this.
> >
> > Art
> >
>
> Thanks for your response, but my shmmax is 4294967295 and the problem
> arise when the total allocated virtual segment is about 2 Gb!
>
> It isn't a good solution to run "onmode -F" periodically ?
>
> Thanks for you response.
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--001517503b0876dfa4049c52659e
Il 15/02/2011 14:47, Art Kagel ha scritto:
> As I suggested, did you check your SHMMNI setting, the number of segments
> per process? It can't hurt to run onmode -F periodically, but if those
> memory segments keep showing up again, then the memory is needed by the
> engine to process queries, so you may as well fold those additional segments
> into SHMVIRTSIZE and keep the memory permanently.
This is my values:
/*
* SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
* be increased by sysctl
*/
#define SHMMAX 0x2000000 /* max shared seg size (bytes) */
#define SHMMIN 1 /* min shared seg size (bytes) */
#define SHMMNI 4096 /* max num of segs system wide */
#define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide
(pages) */
#define SHMSEG SHMMNI
The "intesive query" that causes the increase of the segments is
performed only one time a day and then, I hope, that the segments can be
removed. If I did not remove the segments, the new query execution
causes a further allocations of other segments!
> Also, you are aware that Informix 9.30 dates from 2000 and is well
> out-of-support, right? You should upgrade to the 11.50 or 11.70 version.
> There have been 4 or 5 rounds of performance improvements and lots of new
> features since 9.30.
>
I know, but at the moment I can not change
Hello.
In our experiences, external applications (java using connection pools,
ex) allocating
memory and not freeing it after processing informations, we just
recommended to set the IFX_AUTOFREE parameter on the connection string,
and it solved our problems.
Is your application an external one? Or it´s 4gl based, for example....
Best regards!
Em 15/02/2011 10:07, Francesco Alfano escreveu:
> Il 15/02/2011 14:47, Art Kagel ha scritto:
>> As I suggested, did you check your SHMMNI setting, the number of segments
>> per process? It can't hurt to run onmode -F periodically, but if those
>> memory segments keep showing up again, then the memory is needed by the
>> engine to process queries, so you may as well fold those additional segments
>> into SHMVIRTSIZE and keep the memory permanently.
> This is my values:
> /*
> * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
> * be increased by sysctl
> */
>
> #define SHMMAX 0x2000000 /* max shared seg size (bytes) */
> #define SHMMIN 1 /* min shared seg size (bytes) */
> #define SHMMNI 4096 /* max num of segs system wide */
> #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide
> (pages) */
> #define SHMSEG SHMMNI
>
> The "intesive query" that causes the increase of the segments is
> performed only one time a day and then, I hope, that the segments can be
> removed. If I did not remove the segments, the new query execution
> causes a further allocations of other segments!
>
>> Also, you are aware that Informix 9.30 dates from 2000 and is well
>> out-of-support, right? You should upgrade to the 11.50 or 11.70 version.
>> There have been 4 or 5 rounds of performance improvements and lots of new
>> features since 9.30.
>>
> I know, but at the moment I can not change
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Alexandre Marini
Tecnologia da Informação - DBA
msn: alexandre_marini@hotmail.com
SEFAZ-MS / SGI-UGSR / Sistemas IBM-Informix
Cert-Info-Mgmt_color <Cert-Info-Mgmt_color.jpg>
IBM Certified System Administrator - Informix Dynamic Server V10 / V11
SHMMAX is too small. It is only allowing a maximum segment of less than
2MB. I would want the maximum segment size to be at least 20GB. The other
parameters look OK.
Art
Art S. Kagel
Advanced DataTools (www.advancedatatools.com)
IIUG Board of Directors (art@iiug.org)
Blog: http://informix-myview.blogspot.com/
Disclaimer: Please keep in mind that my own opinions are my own opinions and
do not reflect on my employer, Advanced DataTools, the IIUG, nor any other
organization with which I am associated either explicitly, implicitly, or by
inference. Neither do those opinions reflect those of other individuals
affiliated with any entity with which I am affiliated nor those of the
entities themselves.
On Tue, Feb 15, 2011 at 9:07 AM, Francesco Alfano <edacedpa@yahoo.it> wrote:
> Il 15/02/2011 14:47, Art Kagel ha scritto:
> > As I suggested, did you check your SHMMNI setting, the number of segments
> > per process? It can't hurt to run onmode -F periodically, but if those
> > memory segments keep showing up again, then the memory is needed by the
> > engine to process queries, so you may as well fold those additional
> segments
> > into SHMVIRTSIZE and keep the memory permanently.
>
> This is my values:
> /*
> * SHMMAX, SHMMNI and SHMALL are upper limits are defaults which can
> * be increased by sysctl
> */
>
> #define SHMMAX 0x2000000 /* max shared seg size (bytes) */
> #define SHMMIN 1 /* min shared seg size (bytes) */
> #define SHMMNI 4096 /* max num of segs system wide */
> #define SHMALL (SHMMAX/PAGE_SIZE*(SHMMNI/16)) /* max shm system wide
> (pages) */
> #define SHMSEG SHMMNI
>
> The "intesive query" that causes the increase of the segments is
> performed only one time a day and then, I hope, that the segments can be
> removed. If I did not remove the segments, the new query execution
> causes a further allocations of other segments!
>
> > Also, you are aware that Informix 9.30 dates from 2000 and is well
> > out-of-support, right? You should upgrade to the 11.50 or 11.70 version.
> > There have been 4 or 5 rounds of performance improvements and lots of new
> > features since 9.30.
> >
> I know, but at the moment I can not change
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--20cf30334f251c20d2049c5e41a7
Il 16/02/2011 04:55, Art Kagel ha scritto: > SHMMAX is too small. It is only allowing a maximum segment of less than > 2MB. I would want the maximum segment size to be at least 20GB. The other > parameters look OK. > > Art > Thanks, Francesco.