Ingres, memory and ulimits

Ingres, memory and ulimits

Post by Mason, Paul NI » Mon, 06 Sep 1999 04:00:00



Hi

Ok - here's the spec - 13 CPU (was 10), 5.5Gb memory Siemens E70 - Sinix
5.44 - OpenIngres 1.2/01 - patch 5725. 9 DBMSs with 160 connections each.
Roughly 50% of connections are through Net, 50% ABF. 21 Net servers (3
classes).

To cut a long story short I tried to go to 170 connections per DBMS and hit
this error

      ::[/tmp/ii.15077   , 030CC040]: Fri Sep  3 08:51:55 1999
E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

brk() failed with operating system error 12 (Not enough space)

OS error 12 is a ulimit error (data size I believe). So it's a per-process
limit problem. Which makes sense because we had oodles of free memory at the
time.

Oh and our syscheck doesn't work because our OS version is not strictly
certified (though CA will support us - it's a long story!). So when I make
these changes I often do it blind. Fun huh?

I've just asked the following question of CA Support - thought I'd try you
guys too.

Here are some key memory-grabbing parameters from the dbms setup.

ii.cib2.dbms.*.opf_memory:              51200000
ii.cib2.dbms.*.psf_memory:              51200000
ii.cib2.dbms.*.qsf_memory:              12900000
ii.cib2.dbms.*.rdf_memory:              18874368

Now I think these are all non-shared memory and therefore our per-server
memory requirement is > ~130Mb.

Now our ulimit settings are

time(seconds)        unlimited
file(blocks)         unlimited    
data(kbytes)         65536              
stack(kbytes)        2097152
coredump(blocks)     4194304
nofiles(descriptors) 250
vmemory(kbytes)      unlimited

What I would like to know is which bits of ingres memory are affected by
which ulimits. At least one of these is coming from the data segment and
hitting the data limit. From conversations with CA Support I suspect at
least part of this is coming from the vmemory - they told me normally when
they get a E_SC0107_BAD_SIZE_EXPAND it is the vmemory - but ours is
ulimited.

Maybe there are other parameters I should look at as well. Partly because of
the lack of sysheck - partly for my own understanding - I am trying to get a
clearer picture of which Ingres parameters affect which Unix parameters. I
have been told that this is the impossible dream and I know it varies unix
to unix - but I thought I'd start here.

Any insight gladly received.

BTW - we have solved (hopefully) the connectivity issues by adding an extra
DBMS (and 3 new CPUs for extra growth). I am reasonably confident my
160-connections DBMS will fit into my current per-process limits. At least
it hasn't fallen over yet!

Thanks

Paul Mason
NICL
Technical Support - Database Administration

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they  
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

 
 
 

Ingres, memory and ulimits

Post by Yang, Jim E » Mon, 06 Sep 1999 04:00:00


I could be wrong here. But ...

        vmemory(kbytes)      unlimited

        What I would like to know is which bits of ingres memory are
affected by
        which ulimits. At least one of these is coming from the data segment
and
        hitting the data limit. From conversations with CA Support I suspect
at
        least part of this is coming from the vmemory - they told me
normally when
        they get a E_SC0107_BAD_SIZE_EXPAND it is the vmemory - but ours is
        ulimited.

"Unlimited" only means UNRESTRICTED for a process and the ceiling is still
there set by a (tunable) kernel parameter, which you may change.

> -----Original Message-----

> Sent:      Sunday, September 05, 1999 9:23 AM
> To:        Ingres Mailing List
> Subject:   Ingres, memory and ulimits

> Hi

> Ok - here's the spec - 13 CPU (was 10), 5.5Gb memory Siemens E70 - Sinix
> 5.44 - OpenIngres 1.2/01 - patch 5725. 9 DBMSs with 160 connections each.
> Roughly 50% of connections are through Net, 50% ABF. 21 Net servers (3
> classes).

> To cut a long story short I tried to go to 170 connections per DBMS and
> hit
> this error

>       ::[/tmp/ii.15077   , 030CC040]: Fri Sep  3 08:51:55 1999
> E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

> brk() failed with operating system error 12 (Not enough space)

> OS error 12 is a ulimit error (data size I believe). So it's a per-process
> limit problem. Which makes sense because we had oodles of free memory at
> the
> time.

> Oh and our syscheck doesn't work because our OS version is not strictly
> certified (though CA will support us - it's a long story!). So when I make
> these changes I often do it blind. Fun huh?

> I've just asked the following question of CA Support - thought I'd try you
> guys too.

> Here are some key memory-grabbing parameters from the dbms setup.

> ii.cib2.dbms.*.opf_memory:              51200000
> ii.cib2.dbms.*.psf_memory:              51200000
> ii.cib2.dbms.*.qsf_memory:              12900000
> ii.cib2.dbms.*.rdf_memory:              18874368

> Now I think these are all non-shared memory and therefore our per-server
> memory requirement is > ~130Mb.

> Now our ulimit settings are

> time(seconds)        unlimited
> file(blocks)         unlimited    
> data(kbytes)         65536        
> stack(kbytes)        2097152
> coredump(blocks)     4194304
> nofiles(descriptors) 250
> vmemory(kbytes)      unlimited

> What I would like to know is which bits of ingres memory are affected by
> which ulimits. At least one of these is coming from the data segment and
> hitting the data limit. From conversations with CA Support I suspect at
> least part of this is coming from the vmemory - they told me normally when
> they get a E_SC0107_BAD_SIZE_EXPAND it is the vmemory - but ours is
> ulimited.

> Maybe there are other parameters I should look at as well. Partly because
> of
> the lack of sysheck - partly for my own understanding - I am trying to get
> a
> clearer picture of which Ingres parameters affect which Unix parameters. I
> have been told that this is the impossible dream and I know it varies unix
> to unix - but I thought I'd start here.

> Any insight gladly received.

> BTW - we have solved (hopefully) the connectivity issues by adding an
> extra
> DBMS (and 3 new CPUs for extra growth). I am reasonably confident my
> 160-connections DBMS will fit into my current per-process limits. At least
> it hasn't fallen over yet!

> Thanks

> Paul Mason
> NICL
> Technical Support - Database Administration

> **********************************************************************
> This email and any files transmitted with it are confidential and
> intended solely for the use of the individual or entity to whom they  
> are addressed. If you have received this email in error please notify
> the system manager.

> This footnote also confirms that this email message has been swept by
> MIMEsweeper for the presence of computer viruses.

> www.mimesweeper.com
> **********************************************************************


 
 
 

Ingres, memory and ulimits

Post by Jerry Lo » Mon, 06 Sep 1999 04:00:00



Quote:>Hi

>Ok - here's the spec - 13 CPU (was 10), 5.5Gb memory Siemens E70 - Sinix
>5.44 - OpenIngres 1.2/01 - patch 5725. 9 DBMSs with 160 connections each.
>Roughly 50% of connections are through Net, 50% ABF. 21 Net servers (3
>classes).

>To cut a long story short I tried to go to 170 connections per DBMS and hit
>this error

>      ::[/tmp/ii.15077   , 030CC040]: Fri Sep  3 08:51:55 1999
>E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

------------------------------------------^^^^^^^
Quote:

>brk() failed with operating system error 12 (Not enough space)

----------------------------------------------^^^^^^^^^^^^^^^^

This says the process in question asked the kernel for more address
space with a call to brk() and the kernel responded that there was not
enough space available to service the request.  When you increase the
number of connections to your server, you (mainly) increase the size
of the data area.

Check for reservable swap space.  Not sure about Sinix, but some OSs
require that space be allocated in the swap file(s) for the entire
virtual address space of procesess as soon as it is requested.  Some
other OSs only allocate swap for the non-text address space, since
text can be reread from the executable file.  When space isn't
available, possibly due to fragmentation in the swap file(s), brk()
fails with errno=12.

 
 
 

Ingres, memory and ulimits

Post by Nabil Cour » Tue, 07 Sep 1999 04:00:00


Quote:>      ::[/tmp/ii.15077   , 030CC040]: Fri Sep  3 08:51:55 1999
>E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

>brk() failed with operating system error 12 (Not enough space)

>data(kbytes)         65536
>stack(kbytes)        2097152

This is usually related to the per-proc-data-size
which appears to be set very low according to
your ulimit output. It appears that your data and
stack size setting should be swapped.  65536 KB
for stack size is fairly common on other UNIX flavors.
However, if correct, the data size is way too low.
Monitor your dbms size growth using the
ps command.  It will reach a point when it cannot
expand.

Quote:>Maybe there are other parameters I should look at as well. Partly because
of
>the lack of sysheck - partly for my own understanding - I am trying to get
a
>clearer picture of which Ingres parameters affect which Unix parameters. I
>have been told that this is the impossible dream and I know it varies unix
>to unix - but I thought I'd start here.

It may be true that it is the impossible dream.  However,
I believe that the Ingres documentation can include an
appendix on recommendations for setting kernel
parameters.  Ingres documentation, for as long as
I remember, has always addressed 3 or 4 kernel
parameters.  A zillion years later, and the documentation
is still the same.

Nabil Courdy

===================

 
 
 

Ingres, memory and ulimits

Post by Kim Fog » Tue, 14 Sep 1999 04:00:00


Quote:>E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

>brk() failed with operating system error 12 (Not enough space)

Have seen that problem recently on both Alpha/OSF and AIX.
Solved the problem by raising the data-area, ulimit -d.
Your 65MB seems way below the needs for a DBMS with
160 sessions.
 
 
 

Ingres, memory and ulimits

Post by Mason, Paul NI » Thu, 16 Sep 1999 04:00:00


Kim

Yes - with CA Tech Support's help that's exactly what we did.

Paul Mason
NICL
Technical Support - Database Administration

-----Original Message-----

Sent: Monday, September 13, 1999 10:53 PM

(NICL); Watson, Richard (NICL); Watson, Chris (NICL); Mason, Paul (NICL)
Subject: Re: Ingres, memory and ulimits

----------------------------------------------------------------------------
>E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

>brk() failed with operating system error 12 (Not enough space)

Have seen that problem recently on both Alpha/OSF and AIX.
Solved the problem by raising the data-area, ulimit -d.
Your 65MB seems way below the needs for a DBMS with
160 sessions.

**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they  
are addressed. If you have received this email in error please notify
the system manager.

This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.

www.mimesweeper.com
**********************************************************************

 
 
 

Ingres, memory and ulimits

Post by Piers Collin » Thu, 16 Sep 1999 04:00:00


Ditto

I've seen the same problem on ICL unix boxes, where raising the ulimit
parameters solved the problem. I read in another recent news thread that
it's recommended to set ulimits to unlimited for the Ingres user which I
guess is fine if Ingres is the only thing which runs on the box.


writes

Quote:>>E_SC0107_BAD_SIZE_EXPAND Error expanding virtual size of server.

>>brk() failed with operating system error 12 (Not enough space)

>Have seen that problem recently on both Alpha/OSF and AIX.
>Solved the problem by raising the data-area, ulimit -d.
>Your 65MB seems way below the needs for a DBMS with
>160 sessions.

--
Piers T Collins
 
 
 

1. Memory problem with Ingres Windows 4GL

Hello,

We are running Ingres v 6.4/03 (su4.u42/00)
and W4GL 2.0/01(su4.u42/00) on a Sun SPARC Station 1+
(Sun OS 4.1.1)

The following error has been logged:

OC      Error calling QSF
     to allocate a piece of memory.
      ::[1142            , 00553FA0]: Wed Aug 24 17:05:08 1994
E_QS0001_NOMEM QSF dynamic memory pool is exhausted.

There is no shortage of virtual memory when the condition occurs.

Can I fix the problem by adjusting one of the parameters
in one of the ingres .opt files? If so which one?

Any help is very much appreciated.

Thanks

Shaun

Shaun McCullagh (RA)
School of Information Systems.,
University of East Anglia.,
Norwich
England NR4 7TJ



*******************************************************************
Life is like sanskrit read to a pony
*******************************************************************

2. TQuery fetches all records when updating any other table or query

3. shared memory in ingres 6.4/04 on sunOS 4.1

4. Bug when testing DTD request !?

5. Shared Memory Address Bug, Ingres on Sun 4.1.3

6. Problem installing on Windows 2000 Server

7. INGRES HELP - out of virutal memory?

8. Pick programmer seeking work in UK

9. How does Ingres allocate OPF memory?

10. Ingres Memory map

11. Ingres II Shared Memory -- Solaris 2.6

12. Ingres/Solaris memory usage query

13. Memory Leaks from Ingres 6.4 on SPARCserver 1000