SEO

I'm running into a problem where my program is running out
of memory at under 2GB, but lsattr says my realmem is 8GB.

I have compiled with xlC -q64 and different -bmaxdata values,
but to no avail.

Below is a simple program that uses an STL vector and
pushes random unsigned long long integers (8 bytes).
It fails at counter=136216567, meaning that it runs out of
memory at 136216567*8=1089732536 bytes = 1GB (and I
assume the next vector reallocation will push the vector
past 2GB).


Can someone suggest what I can do? I would like to be able
to use up as much of my system's 8GB as possible.


Compile:
xlC -bmaxdata:0x80000000 -O5 -qunroll -q64 memorytest.C


#include <stdio.h>
#include <vector>
#include <string.h>
#include <time.h>
#include <stdlib.h> /* random, srandom */

using namespace std;

vector<unsigned long long> v;

main()
{
unsigned long long value;
int counter;
srandom(time(NULL));

for (counter = 0; counter < 500000000; counter++)
{
value = ((unsigned long long)random() << 32) | (unsigned
long)random();
try
{
v.push_back(value);
}
catch(bad_alloc ex)
{
perror("problem: ");
printf("push_back failed: %s\n", ex.what());
printf("counter = %d\n", counter);
printf("vector capacity: %d\n", v.capacity());
exit(1);
}
if ((counter % 2000000) == 0) printf("%d\n", counter);
}


}





The end result is:
problem: : Not enough space
push_back failed: bad allocation
counter = 136216567
vector capacity: 136216567

In article <1133144242.046705.46250@g43g2000cwa.googlegroups. com>, Digital Puer <digital_puer@hotmail.com> wrote:
> I'm running into a problem where my program is running out
> of memory at under 2GB, but lsattr says my realmem is 8GB.

What OS version?

This is a fundamental limitation of anything before v5.

With v5 and onwards, a non-issue, particularly on 64-bit hardware, I
believe.

-Dan

I do'nt think that -bmaxdata is needed with -q64 option set.
Some points to check:

- What dit the "ulimit -a" command returns ?

- Is your kernel 64 bits ?
#ls -l /unix
lrwxrwxrwx 1 root system 21 Mar 20 2003 /unix ->
/usr/lib/boot/unix_64

Patrick

Digital Puer wrote:
> I'm running into a problem where my program is running out
> of memory at under 2GB, but lsattr says my realmem is 8GB.
>
> I have compiled with xlC -q64 and different -bmaxdata values,
> but to no avail.
>
> Below is a simple program that uses an STL vector and
> pushes random unsigned long long integers (8 bytes).
> It fails at counter=136216567, meaning that it runs out of
> memory at 136216567*8=1089732536 bytes = 1GB (and I
> assume the next vector reallocation will push the vector
> past 2GB).
>
>
> Can someone suggest what I can do? I would like to be able
> to use up as much of my system's 8GB as possible.
>
>
> Compile:
> xlC -bmaxdata:0x80000000 -O5 -qunroll -q64 memorytest.C
>
>
> #include <stdio.h>
> #include <vector>
> #include <string.h>
> #include <time.h>
> #include <stdlib.h> /* random, srandom */
>
> using namespace std;
>
> vector<unsigned long long> v;
>
> main()
> {
> unsigned long long value;
> int counter;
> srandom(time(NULL));
>
> for (counter = 0; counter < 500000000; counter++)
> {
> value = ((unsigned long long)random() << 32) | (unsigned
> long)random();
> try
> {
> v.push_back(value);
> }
> catch(bad_alloc ex)
> {
> perror("problem: ");
> printf("push_back failed: %s\n", ex.what());
> printf("counter = %d\n", counter);
> printf("vector capacity: %d\n", v.capacity());
> exit(1);
> }
> if ((counter % 2000000) == 0) printf("%d\n", counter);
> }
>
>
> }
>
>
>
>
>
> The end result is:
> problem: : Not enough space
> push_back failed: bad allocation
> counter = 136216567
> vector capacity: 136216567
>

Here is ulimit -a :

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) 131072
stack(kbytes) 32768
memory(kbytes) 32768
coredump(blocks) 0
nofiles(descriptors) 2000



Here is /unix :

/unix@ -> /usr/lib/boot/unix_6







Patrick Begou wrote:
> I do'nt think that -bmaxdata is needed with -q64 option set.
> Some points to check:
>
> - What dit the "ulimit -a" command returns ?
>
> - Is your kernel 64 bits ?
> #ls -l /unix
> lrwxrwxrwx 1 root system 21 Mar 20 2003 /unix ->
> /usr/lib/boot/unix_64
>
> Patrick
>
> Digital Puer wrote:
> > I'm running into a problem where my program is running out
> > of memory at under 2GB, but lsattr says my realmem is 8GB.
> >
> > I have compiled with xlC -q64 and different -bmaxdata values,
> > but to no avail.
> >
> > Below is a simple program that uses an STL vector and
> > pushes random unsigned long long integers (8 bytes).
> > It fails at counter=136216567, meaning that it runs out of
> > memory at 136216567*8=1089732536 bytes = 1GB (and I
> > assume the next vector reallocation will push the vector
> > past 2GB).
> >
> >
> > Can someone suggest what I can do? I would like to be able
> > to use up as much of my system's 8GB as possible.
> >
> >
> > Compile:
> > xlC -bmaxdata:0x80000000 -O5 -qunroll -q64 memorytest.C
> >
> >
> > #include <stdio.h>
> > #include <vector>
> > #include <string.h>
> > #include <time.h>
> > #include <stdlib.h> /* random, srandom */
> >
> > using namespace std;
> >
> > vector<unsigned long long> v;
> >
> > main()
> > {
> > unsigned long long value;
> > int counter;
> > srandom(time(NULL));
> >
> > for (counter = 0; counter < 500000000; counter++)
> > {
> > value = ((unsigned long long)random() << 32) | (unsigned
> > long)random();
> > try
> > {
> > v.push_back(value);
> > }
> > catch(bad_alloc ex)
> > {
> > perror("problem: ");
> > printf("push_back failed: %s\n", ex.what());
> > printf("counter = %d\n", counter);
> > printf("vector capacity: %d\n", v.capacity());
> > exit(1);
> > }
> > if ((counter % 2000000) == 0) printf("%d\n", counter);
> > }
> >
> >
> > }
> >
> >
> >
> >
> >
> > The end result is:
> > problem: : Not enough space
> > push_back failed: bad allocation
> > counter = 136216567
> > vector capacity: 136216567
> >

In article <1133205637.014501.157820@g47g2000cwa.googlegroups .com>, Digital Puer <digital_puer@hotmail.com> wrote:
> Here is ulimit -a :
>
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 131072
> stack(kbytes) 32768
> memory(kbytes) 32768
> coredump(blocks) 0
> nofiles(descriptors) 2000

1. What is the OS version?

If it is 4.3.3 or older, you are stuck with 2 GB max.

2. What is the type-model number of the hardware? E.g. 9076-270, etc.

If you are running 5.1 or later on 64-bit hardware, then you're almost
there. You might consider adjusting some of the ulimit values, though.

-Dan

Dan Foster wrote:
> In article <1133205637.014501.157820@g47g2000cwa.googlegroups .com>, Digital Puer <digital_puer@hotmail.com> wrote:
> > Here is ulimit -a :
> >
> > time(seconds) unlimited
> > file(blocks) unlimited
> > data(kbytes) 131072
> > stack(kbytes) 32768
> > memory(kbytes) 32768
> > coredump(blocks) 0
> > nofiles(descriptors) 2000
>
> 1. What is the OS version?
>
> If it is 4.3.3 or older, you are stuck with 2 GB max.
>
> 2. What is the type-model number of the hardware? E.g. 9076-270, etc.
>
> If you are running 5.1 or later on 64-bit hardware, then you're almost
> there. You might consider adjusting some of the ulimit values, though.


I am not sure about the OS version, but 'uname -a' returns this:

AIX XXX 2 5 0004A20D4C00

the model number is: IBM,7028-6E4

In article <1133213728.997183.239820@z14g2000cwz.googlegroups .com>, "Digital
Puer" <digital_puer@hotmail.com> writes:
>
> I am not sure about the OS version, but 'uname -a' returns this:
>
> AIX XXX 2 5 0004A20D4C00

that's 5.2

In article <1133213728.997183.239820@z14g2000cwz.googlegroups .com>, Digital Puer <digital_puer@hotmail.com> wrote:
>
> I am not sure about the OS version, but 'uname -a' returns this:
>
> AIX XXX 2 5 0004A20D4C00

That's AIX 5.2. (Another way to tell: 'oslevel')

> the model number is: IBM,7028-6E4

Ahh, good. That's 64-bit hardware. Also, your serial number apparently
is 10-4A20D. (Also can see it from 'lsattr -El sys0 -a systemid')

Your ulimit settings seems to be restricting you. Might want to set
'data', 'memory', and possibly 'stack' to unlimited values for the user
you are running the application for.

# vi /etc/security/limits

will do the trick. Not sure if you have to reboot or not.

You can set it in the default entry or override default entry with
specific per-user settings.

You may also have insufficient swap space configured?

What does 'lsps -a' say?

My first test failed almost at 1 GB (but not at that exact point)
because I ran out of paging (swap) space even though I had *plenty* of
physical memory left.

You can tell if this happens because programs gets killed and 'errpt'
mentions VMM messages and software program abnormally terminated, with
'errpt -a|more' mentioning due to system running out of paging space.

I am testing it on one of my AIX 5.2 machines with VisualAge C/C++ 6.0 +
latest patches for both OS and VAC.

-Dan

In article <slrndonaea.2rn.usenet@zappy.catbert.org>, Dan Foster <usenet@evilphb.org> wrote:
> You may also have insufficient swap space configured?
>
> What does 'lsps -a' say?
>
> My first test failed almost at 1 GB (but not at that exact point)
> because I ran out of paging (swap) space even though I had *plenty* of
> physical memory left.
>
> You can tell if this happens because programs gets killed and 'errpt'
> mentions VMM messages and software program abnormally terminated, with
> 'errpt -a|more' mentioning due to system running out of paging space.

I tested your program on one of my 64-bit AIX 5.2 machines. The test
aborted early because I did not have enough paging space configured.

But I did verify that with your compile flags and no -bmaxdata option, I
was able to hit 1.6 GB allocated before test failed.

I am sure it would have had passed 2 GB if I had more paging space set
up and if I had used very large program support with right bmaxdata
flags. I already had ulimit set to unlimited.

I can't set up more paging space on that machine because it is a
production server, and I do not have a similar sized test machine.

But basically, you need to look at three more things: ulimit, paging
space, and -bmaxdata option.

1. You probably need at least 8 GB of paging space configured.

# smitty lvm
Paging Space
Add Another Paging Space
<pick which VG to put PS on>
<enter number of LPs for PS>
<go down to 'Start using this paging space NOW?', press tab to set to yes>
<go down to 'Use this paging space each time the system is RESTARTED?',
press tab to set to yes>
<press enter to execute>
<press esc-0 or F10 when done with SMIT>

# lsps -a

2. Read this IBM page on very large program support:

http://publib16.boulder.ibm.com/pser...rg_support.htm

It applies to AIX 5.1 and later.

It suggests using: -bmaxdata:0xD0000000/dsa instead of what you used
before. That turns on *Very* large program support. Large Program
Support is NOT enough because that is limited to 2 GB RAM.

3. Adjust ulimit (see other post on how to do it).

-Dan

As says Dan Foster
1) increase your paging space (may be add a second one if you want
easily remove it later)

2) increase your limits for data and memory in /etc/security/limits
(stack not needed in you case I think).

These are the parameters for an AIX 5.2 with 8 Gbytes memory here:
#lsps -a
Page Space Physical Volume Volume Group Size %Used Active
Auto Type
paging00 hdisk0 rootvg 3968MB 5 yes
yes lv
hd6 hdisk0 rootvg 3968MB 5 yes
yes lv
#ulimit -a
time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 4194304
memory(kbytes) unlimited
coredump(blocks) 2097151
nofiles(descriptors) unlimited

Takes care, data and memory are in 512bytes blocs in /etc/security.
You need to loogout/logon after changing this file (no reboot needed).

Patrick



Digital Puer wrote:
> Here is ulimit -a :
>
> time(seconds) unlimited
> file(blocks) unlimited
> data(kbytes) 131072
> stack(kbytes) 32768
> memory(kbytes) 32768
> coredump(blocks) 0
> nofiles(descriptors) 2000
>
>
>
> Here is /unix :
>
> /unix@ -> /usr/lib/boot/unix_6
>
>
>
>
>
>
>
> Patrick Begou wrote:
>
>>I do'nt think that -bmaxdata is needed with -q64 option set.
>>Some points to check:
>>
>>- What dit the "ulimit -a" command returns ?
>>
>>- Is your kernel 64 bits ?
>>#ls -l /unix
>>lrwxrwxrwx 1 root system 21 Mar 20 2003 /unix ->
>>/usr/lib/boot/unix_64
>>
>>Patrick
>>
>>Digital Puer wrote:
>>
>>>I'm running into a problem where my program is running out
>>>of memory at under 2GB, but lsattr says my realmem is 8GB.
>>>
>>>I have compiled with xlC -q64 and different -bmaxdata values,
>>>but to no avail.
>>>
>>>Below is a simple program that uses an STL vector and
>>>pushes random unsigned long long integers (8 bytes).
>>>It fails at counter=136216567, meaning that it runs out of
>>>memory at 136216567*8=1089732536 bytes = 1GB (and I
>>>assume the next vector reallocation will push the vector
>>>past 2GB).
>>>
>>>
>>>Can someone suggest what I can do? I would like to be able
>>>to use up as much of my system's 8GB as possible.
>>>
>>>
>>>Compile:
>>>xlC -bmaxdata:0x80000000 -O5 -qunroll -q64 memorytest.C
>>>
>>>
>>>#include <stdio.h>
>>>#include <vector>
>>>#include <string.h>
>>>#include <time.h>
>>>#include <stdlib.h> /* random, srandom */
>>>
>>>using namespace std;
>>>
>>>vector<unsigned long long> v;
>>>
>>>main()
>>>{
>>> unsigned long long value;
>>> int counter;
>>> srandom(time(NULL));
>>>
>>> for (counter = 0; counter < 500000000; counter++)
>>> {
>>> value = ((unsigned long long)random() << 32) | (unsigned
>>>long)random();
>>> try
>>> {
>>> v.push_back(value);
>>> }
>>> catch(bad_alloc ex)
>>> {
>>> perror("problem: ");
>>> printf("push_back failed: %s\n", ex.what());
>>> printf("counter = %d\n", counter);
>>> printf("vector capacity: %d\n", v.capacity());
>>> exit(1);
>>> }
>>> if ((counter % 2000000) == 0) printf("%d\n", counter);
>>> }
>>>
>>>
>>>}
>>>
>>>
>>>
>>>
>>>
>>>The end result is:
>>>problem: : Not enough space
>>>push_back failed: bad allocation
>>>counter = 136216567
>>>vector capacity: 136216567
>>>
>
>