AIX - Out of Memory

This is a multi-part message in MIME format.

------_=_NextPart_001_01CAAE4C.2AB7ABC6
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi All,

Looking for some help with regards to an 'Out of Memory' issue I have
with our Postgresql install on AIX. When running large updates or
select queries we get an out of memory error returned and details
entered in the log file like below. This is a 64-bit install and I have
set the ulimit for the postgres user to unlimited.

An example of the log details are below :

TopMemoryContext: 69552 total in 8 blocks; 4560 free (12 chunks); 64992
used
TopTransactionContext: 8192 total in 1 blocks; 7520 free (0 chunks);
672 used
AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
chunks); 131063232 used
PL/PgSQL function context: 24576 total in 2 blocks; 16328 free (4
chunks); 8248 used
CFuncHash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
Rendezvous variable hash: 8192 total in 1 blocks; 1680 free (0
chunks); 6512 used
PLpgSQL function cache: 24520 total in 2 blocks; 3744 free (0 chunks);
20776 used
Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks);
6512 used
Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks);
12688 used
MessageContext: 65536 total in 4 blocks; 31832 free (2 chunks); 33704
used
smgr relation table: 24576 total in 2 blocks; 13904 free (4 chunks);
10672 used
TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0
chunks); 32 used
Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used
PortalMemory: 8192 total in 1 blocks; 7888 free (0 chunks); 304 used
PortalHeapMemory: 1024 total in 1 blocks; 768 free (0 chunks); 256
used
ExecutorState: 57344 total in 3 blocks; 25472 free (13 chunks);
31872 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used
Relcache by OID: 24576 total in 2 blocks; 14912 free (3 chunks); 9664
used
CacheMemoryContext: 817392 total in 20 blocks; 120560 free (16
chunks); 696832 used
stprice_idx2: 2048 total in 1 blocks; 704 free (0 chunks); 1344 used
stprice_idx1: 2048 total in 1 blocks; 584 free (0 chunks); 1464 used
stprice_pkey: 2048 total in 1 blocks; 704 free (0 chunks); 1344 used
CachedPlan: 7168 total in 3 blocks; 1808 free (0 chunks); 5360 used
CachedPlanSource: 7168 total in 3 blocks; 1776 free (0 chunks); 5392
used
SPI Plan: 1024 total in 1 blocks; 688 free (0 chunks); 336 used
CachedPlan: 1024 total in 1 blocks; 96 free (0 chunks); 928 used
CachedPlanSource: 3072 total in 2 blocks; 1792 free (1 chunks); 1280
used
SPI Plan: 1024 total in 1 blocks; 808 free (0 chunks); 216 used
pg_attrdef_adrelid_adnum_index: 2048 total in 1 blocks; 608 free (0
chunks); 1440 used
pg_database_datname_index: 2048 total in 1 blocks; 752 free (0
chunks); 1296 used
pg_index_indrelid_index: 2048 total in 1 blocks; 704 free (0
chunks); 1344 used
pg_ts_dict_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_aggregate_fnoid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_language_name_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_statistic_relid_att_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_ts_dict_dictname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_namespace_nspname_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_opfamily_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_opclass_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_parser_prsname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_amop_fam_strat_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_opclass_am_name_nsp_index: 3072 total in 2 blocks; 1624 free (3
chunks); 1448 used
pg_trigger_tgrelid_tgname_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_cast_source_target_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_auth_members_role_member_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_attribute_relid_attnum_index: 3072 total in 2 blocks; 1600 free
(2 chunks); 1472 used
pg_ts_config_cfgname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_ts_config_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_conversion_default_index: 3072 total in 2 blocks; 1432 free (3
chunks); 1640 used
pg_language_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_enum_oid_index: 3072 total in 2 blocks; 1744 free (3 chunks);
1328 used
pg_proc_proname_args_nsp_index: 3072 total in 2 blocks; 1576 free (3
chunks); 1496 used
pg_ts_parser_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_database_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_conversion_name_nsp_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_class_relname_nsp_index: 3072 total in 2 blocks; 1600 free (2
chunks); 1472 used
pg_attribute_relid_attnam_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_class_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_amproc_fam_proc_index: 3072 total in 2 blocks; 1384 free (2
chunks); 1688 used
pg_operator_oprname_l_r_n_index: 3072 total in 2 blocks; 1384 free
(2 chunks); 1688 used
pg_index_indexrelid_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_type_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_rewrite_rel_rulename_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_authid_rolname_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_auth_members_member_role_index: 3072 total in 2 blocks; 1648 free
(2 chunks); 1424 used
pg_enum_typid_label_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_constraint_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_conversion_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
pg_ts_template_tmplname_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_ts_config_map_index: 3072 total in 2 blocks; 1624 free (3
chunks); 1448 used
pg_namespace_oid_index: 3072 total in 2 blocks; 1696 free (2
chunks); 1376 used
pg_type_typname_nsp_index: 3072 total in 2 blocks; 1648 free (2
chunks); 1424 used
pg_operator_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_amop_opr_fam_index: 3072 total in 2 blocks; 1600 free (2 chunks);
1472 used
pg_proc_oid_index: 3072 total in 2 blocks; 1696 free (2 chunks);
1376 used
pg_opfamily_am_name_nsp_index: 3072 total in 2 blocks; 1624 free (3
chunks); 1448 used
pg_ts_template_oid_index: 3072 total in 2 blocks; 1744 free (3
chunks); 1328 used
MdSmgr: 8192 total in 1 blocks; 7488 free (0 chunks); 704 used
LOCALLOCK hash: 24576 total in 2 blocks; 15984 free (5 chunks); 8592
used
Timezones: 53584 total in 2 blocks; 3744 free (0 chunks); 49840 used
ErrorContext: 8192 total in 1 blocks; 8160 free (0 chunks); 32 used
2010-02-15 09:20:24 GMT <postgres>ERROR: out of memory
2010-02-15 09:20:24 GMT <postgres>DETAIL: Failed on request of size 40.
2010-02-15 09:20:24 GMT <postgres>STATEMENT: update stprice set break2
=3D 9999999.99 where price2 =3D 0;

This is a 64-bit install (8.3) on AIX 5.3 , when I try to set the shared
memory setting higher the 64MB I also get the following error log and
query connection stopped when running a large select statement.

>>LOG: server process (PID 229740) was terminated by signal 11
>>DETAIL: The postmaster has commanded this server process to roll back
the current transaction and exit, because another server pro
cess exited abnormally and possibly corrupted shared memory.

Any help on this matter would be gratefully accepted

Thanks
fran

___________________________________________________

This email is intended for the named recipient. The information contained=

in it is confidential. You should not copy it for any purposes, nor
disclose its contents to any other party. If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not=

necessarily represent those of the company.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________

------_=_NextPart_001_01CAAE4C.2AB7ABC6
Content-Type: text/html;
charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version 6.5.7638.1">
<TITLE>AIX - Out of Memory</TITLE>
</HEAD>
<BODY>


Hi All,


Looking for some help with regards to an '=
Out of Memory' issue I have with our Postgresql install on AIX. When =
running large updates or select queries we get an out of memory error retur=
ned and details entered in the log file like below. This is a 64-bit =
install and I have set the ulimit for the postgres user to unlimited. =


An example of the log details are be=
low :


TopMemoryContext: 69552 total in 8 b=
locks; 4560 free (12 chunks); 64992 used

 TopTransactionContext: 8192 =
total in 1 blocks; 7520 free (0 chunks); 672 used

 AfterTriggerEven=
ts: 131063808 total in 26 blocks; 576 free (7 chunks); 131063232 used

 PL/PgSQL function context: 2=
4576 total in 2 blocks; 16328 free (4 chunks); 8248 used

 CFuncHash: 8192 total in 1 b=
locks; 1680 free (0 chunks); 6512 used

 Rendezvous variable hash: 81=
92 total in 1 blocks; 1680 free (0 chunks); 6512 used

 PLpgSQL function cache: 2452=
0 total in 2 blocks; 3744 free (0 chunks); 20776 used

 Operator class cache: 8192 t=
otal in 1 blocks; 1680 free (0 chunks); 6512 used

 Operator lookup cache: 24576=
total in 2 blocks; 11888 free (5 chunks); 12688 used

 MessageContext: 65536 total =
in 4 blocks; 31832 free (2 chunks); 33704 used

 smgr relation table: 24576 t=
otal in 2 blocks; 13904 free (4 chunks); 10672 used

 TransactionAbortContext: 327=
68 total in 1 blocks; 32736 free (0 chunks); 32 used

 Portal hash: 8192 total in 1=
blocks; 1680 free (0 chunks); 6512 used

 PortalMemory: 8192 total in =
1 blocks; 7888 free (0 chunks); 304 used

 PortalHeapMemory=
: 1024 total in 1 blocks; 768 free (0 chunks); 256 used

 Exec=
utorState: 57344 total in 3 blocks; 25472 free (13 chunks); 31872 used</FON=
T>

 =
; ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used

 =
; ExprContext: 0 total in 0 blocks; 0 free (0 chunks); 0 used

 Relcache by OID: 24576 total=
in 2 blocks; 14912 free (3 chunks); 9664 used

 CacheMemoryContext: 817392 t=
otal in 20 blocks; 120560 free (16 chunks); 696832 used

 stprice_idx2: 20=
48 total in 1 blocks; 704 free (0 chunks); 1344 used

 stprice_idx1: 20=
48 total in 1 blocks; 584 free (0 chunks); 1464 used

 stprice_pkey: 20=
48 total in 1 blocks; 704 free (0 chunks); 1344 used

 CachedPlan: 7168=
total in 3 blocks; 1808 free (0 chunks); 5360 used

 CachedPlanSource=
: 7168 total in 3 blocks; 1776 free (0 chunks); 5392 used

 SPI Plan: 1024 t=
otal in 1 blocks; 688 free (0 chunks); 336 used

 CachedPlan: 1024=
total in 1 blocks; 96 free (0 chunks); 928 used

 CachedPlanSource=
: 3072 total in 2 blocks; 1792 free (1 chunks); 1280 used

 SPI Plan: 1024 t=
otal in 1 blocks; 808 free (0 chunks); 216 used

 pg_attrdef_adrel=
id_adnum_index: 2048 total in 1 blocks; 608 free (0 chunks); 1440 used</FON=
T>

 pg_database_datn=
ame_index: 2048 total in 1 blocks; 752 free (0 chunks); 1296 used

 pg_index_indreli=
d_index: 2048 total in 1 blocks; 704 free (0 chunks); 1344 used

 pg_ts_dict_oid_i=
ndex: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_aggregate_fno=
id_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_language_name=
_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_statistic_rel=
id_att_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used

 pg_ts_dict_dictn=
ame_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_namespace_nsp=
name_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_opfamily_oid_=
index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_opclass_oid_i=
ndex: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_ts_parser_prs=
name_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_amop_fam_stra=
t_index: 3072 total in 2 blocks; 1384 free (2 chunks); 1688 used

 pg_opclass_am_na=
me_nsp_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used

 pg_trigger_tgrel=
id_tgname_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used</F=
ONT>

 pg_cast_source_t=
arget_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used

 pg_auth_members_=
role_member_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used<=
/FONT>

 pg_attribute_rel=
id_attnum_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used</F=
ONT>

 pg_ts_config_cfg=
name_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_authid_oid_in=
dex: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_ts_config_oid=
_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_conversion_de=
fault_index: 3072 total in 2 blocks; 1432 free (3 chunks); 1640 used

 pg_language_oid_=
index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_enum_oid_inde=
x: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_proc_proname_=
args_nsp_index: 3072 total in 2 blocks; 1576 free (3 chunks); 1496 used</FO=
NT>

 pg_ts_parser_oid=
_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_database_oid_=
index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_conversion_na=
me_nsp_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_class_relname=
_nsp_index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used

 pg_attribute_rel=
id_attnam_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used</F=
ONT>

 pg_class_oid_ind=
ex: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_amproc_fam_pr=
oc_index: 3072 total in 2 blocks; 1384 free (2 chunks); 1688 used

 pg_operator_oprn=
ame_l_r_n_index: 3072 total in 2 blocks; 1384 free (2 chunks); 1688 used</F=
ONT>

 pg_index_indexre=
lid_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_type_oid_inde=
x: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_rewrite_rel_r=
ulename_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used</FON=
T>

 pg_authid_rolnam=
e_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_auth_members_=
member_role_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used<=
/FONT>

 pg_enum_typid_la=
bel_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_constraint_oi=
d_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_conversion_oi=
d_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 pg_ts_template_t=
mplname_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used</FON=
T>

 pg_ts_config_map=
_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used

 pg_namespace_oid=
_index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_type_typname_=
nsp_index: 3072 total in 2 blocks; 1648 free (2 chunks); 1424 used

 pg_operator_oid_=
index: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_amop_opr_fam_=
index: 3072 total in 2 blocks; 1600 free (2 chunks); 1472 used

 pg_proc_oid_inde=
x: 3072 total in 2 blocks; 1696 free (2 chunks); 1376 used

 pg_opfamily_am_n=
ame_nsp_index: 3072 total in 2 blocks; 1624 free (3 chunks); 1448 used</FON=
T>

 pg_ts_template_o=
id_index: 3072 total in 2 blocks; 1744 free (3 chunks); 1328 used

 MdSmgr: 8192 total in 1 bloc=
ks; 7488 free (0 chunks); 704 used

 LOCALLOCK hash: 24576 total =
in 2 blocks; 15984 free (5 chunks); 8592 used

 Timezones: 53584 total in 2 =
blocks; 3744 free (0 chunks); 49840 used

 ErrorContext: 8192 total in =
1 blocks; 8160 free (0 chunks); 32 used

 2010-02-15 09:20:24 GMT <postgre=
s>ERROR: out of memory

 2010-02-15 09:20:24 GMT <postgre=
s>DETAIL: Failed on request of size 40.

 2010-02-15 09:20:24 GMT <postgre=
s>STATEMENT: update stprice set break2 =3D 9999999.99 where price2=
=3D 0;


This is a 64-bit install (8.3) on AIX 5.3 =
, when I try to set the shared memory setting higher the 64MB I also get th=
e following error log and query connection stopped when running a large sel=
ect statement.

>>LOG: server process (PID 229=
740) was terminated by signal 11 

 >>DETAIL: The postmaster has =
commanded this server process to roll back the current transaction and exit=
, because another server pro

cess exited abnormally and possibly corrup=
ted shared memory. 


Any help on this matter would be gratefull=
y accepted


Thanks

 fran


</BODY>

___________________________________________________

This email is intended for the named recipient. The information conta=
ined

in it is confidential. You should not copy it for any purposes, nor=

disclose its contents to any other party. If you received this email=

in error, please notify the sender immediately via email, and delete

it from your computer.

Any views or opinions presented are solely those of the author and do=
not

necessarily represent those of the company.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive

Wigston, Leicester LE18 1AT. Tel 0116 2888000

Registered in England and Wales, Reg No 00986161

VAT GB 115 5713 87 900

__________________________________________________
</HTML>

------_=_NextPart_001_01CAAE4C.2AB7ABC6--

"Thorne, Francis" <thornef [at] cromwell.co.uk> writes:
> Looking for some help with regards to an 'Out of Memory' issue I have
> with our Postgresql install on AIX. When running large updates or
> select queries we get an out of memory error returned and details
> entered in the log file like below. This is a 64-bit install and I have
> set the ulimit for the postgres user to unlimited.

The bloat seems to be here:

> AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
> chunks); 131063232 used

but it's hard to believe you'd be getting "out of memory" after only
130MB in a 64-bit build. Are you *sure* the postgres executable is
64-bit? Are you *sure* the postmaster has been launched with
nonrestrictive ulimit? On lots of setups that takes modifying the
PG startup script, not just fooling with some user's .profile.

> This is a 64-bit install (8.3) on AIX 5.3

8.3.what?

regards, tom lane

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Mon, Feb 15, 2010 at 10:57:06AM -0500, Tom Lane wrote:
> "Thorne, Francis" <thornef [at] cromwell.co.uk> writes:
> > Looking for some help with regards to an 'Out of Memory' issue I have
> > with our Postgresql install on AIX. When running large updates or
> > select queries we get an out of memory error returned and details
> > entered in the log file like below. This is a 64-bit install and I have
> > set the ulimit for the postgres user to unlimited.
>
> The bloat seems to be here:
>
> > AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
> > chunks); 131063232 used
>
> but it's hard to believe you'd be getting "out of memory" after only
> 130MB in a 64-bit build. Are you *sure* the postgres executable is
> 64-bit? Are you *sure* the postmaster has been launched with
> nonrestrictive ulimit? On lots of setups that takes modifying the
> PG startup script, not just fooling with some user's .profile.
>
> > This is a 64-bit install (8.3) on AIX 5.3
>
> 8.3.what?
>
> regards, tom lane

I no longer have an AIX box, but I had similar problems with other
applications that needed large amounts of memory. Some OS specific
steps needed to be taken to allow normal users to allocate large
blocks of memory. The information needed was in their on-line docs
as I recall, but I do not remember the details. The executables may
need to be built with specific options/flags to work.

Regards,
Ken

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

--- On Mon, 2/15/10, Kenneth Marshall <ktm [at] rice.edu> wrote:

> From: Kenneth Marshall <ktm [at] rice.edu>
> Subject: Re: [ADMIN] AIX - Out of Memory
> To: "Tom Lane" <tgl [at] sss.pgh.pa.us>
> Cc: "Thorne, Francis" <thornef [at] cromwell.co.uk>, pgsql-admin [at] postgresql.org
> Date: Monday, February 15, 2010, 11:18 AM
> On Mon, Feb 15, 2010 at 10:57:06AM
> -0500, Tom Lane wrote:
> > "Thorne, Francis" <thornef [at] cromwell.co.uk>
> writes:
> > > Looking for some help with regards to an 'Out of
> Memory' issue I have
> > > with our Postgresql install on AIX.=A0 When
> running large updates or
> > > select queries we get an out of memory error
> returned and details
> > > entered in the log file like below.=A0 This is
> a 64-bit install and I have
> > > set the ulimit for the postgres user to
> unlimited.=A0
> >
> > The bloat seems to be here:
> >
> > >=A0 =A0=A0=A0AfterTriggerEvents:
> 131063808 total in 26 blocks; 576 free (7
> > > chunks); 131063232 used
> >
> > but it's hard to believe you'd be getting "out of
> memory" after only
> > 130MB in a 64-bit build.=A0 Are you *sure* the
> postgres executable is
> > 64-bit?=A0 Are you *sure* the postmaster has been
> launched with
> > nonrestrictive ulimit?=A0 On lots of setups that
> takes modifying the
> > PG startup script, not just fooling with some user's
> .profile.
> >
> > > This is a 64-bit install (8.3) on AIX 5.3
> >
> > 8.3.what?
> >
> > =A0=A0=A0 =A0=A0=A0
> =A0=A0=A0 regards, tom lane
>
> I no longer have an AIX box, but I had similar problems
> with other
> applications that needed large amounts of memory. Some OS
> specific
> steps needed to be taken to allow normal users to allocate
> large
> blocks of memory. The information needed was in their
> on-line docs
> as I recall, but I do not remember the details. The
> executables may
> need to be built with specific options/flags to work.
>
> Regards,
> Ken
>

Ken,

I recently saw a similar issue. It is two-fold:

1. I used "su -" to become the postgres user, and inherited the previous a=
ccount's memory limits,
2. AfterTriggerEvents queues are caused by foreign key constraints, one pe=
r row. If you're loading data, dropping or disabling that constraint makes=
a world of difference. Just be sure to check afterwards if the RI has bee=
n violated prior to recreating the FK constraint.

Bob

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Mon, 2010-02-15 at 10:18 -0600, Kenneth Marshall wrote:
> On Mon, Feb 15, 2010 at 10:57:06AM -0500, Tom Lane wrote:
> > "Thorne, Francis" <thornef [at] cromwell.co.uk> writes:
> > > Looking for some help with regards to an 'Out of Memory' issue I have
> > > with our Postgresql install on AIX. When running large updates or
> > > select queries we get an out of memory error returned and details
> > > entered in the log file like below. This is a 64-bit install and I have
> > > set the ulimit for the postgres user to unlimited.
> >
> > The bloat seems to be here:
> >
> > > AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
> > > chunks); 131063232 used
> >
> > but it's hard to believe you'd be getting "out of memory" after only
> > 130MB in a 64-bit build. Are you *sure* the postgres executable is
> > 64-bit? Are you *sure* the postmaster has been launched with
> > nonrestrictive ulimit? On lots of setups that takes modifying the
> > PG startup script, not just fooling with some user's .profile.
> >
> > > This is a 64-bit install (8.3) on AIX 5.3
> >
> > 8.3.what?
> >
> > regards, tom lane
>
> I no longer have an AIX box, but I had similar problems with other
> applications that needed large amounts of memory. Some OS specific
> steps needed to be taken to allow normal users to allocate large
> blocks of memory. The information needed was in their on-line docs
> as I recall, but I do not remember the details. The executables may
> need to be built with specific options/flags to work.
>

AIX has other limits besides the ulimit, there for security purposes I
believe. 2GB per process is the default.

To OP - what is the size of the postgres process?
Are you using temp tables heavily or frequently in a given session?

I've seen the same issue on AIX before (64 bit build) reporting out of
memory on trivial request size. The issue was due to the use of temp
tables in a single session. PG does not release the memory for the temp
tables until the session ends. The postgres process grows up the the
2GB mark, then the final trivial request pushes it over the tipping
point, and you get the out of memory error.

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Thanks for the prompt reply, if I'm totally honest I'm not 100% sure the
postgres install has built correctly into a 64-bit build. I found it
really difficult to find any documentation on how to configure Postgres
correctly for a 64-bit install onto an AIX system. The only pieces of
information I found where from this forum and off the back of that I
configured postgres with the following settings.

BINDIR =3D /usr/local/pgsql837-64/bin

DOCDIR =3D /usr/local/pgsql837-64/doc

INCLUDEDIR =3D /usr/local/pgsql837-64/include

PKGINCLUDEDIR =3D /usr/local/pgsql837-64/include

INCLUDEDIR-SERVER =3D /usr/local/pgsql837-64/include/server

LIBDIR =3D /usr/local/pgsql837-64/lib

PKGLIBDIR =3D /usr/local/pgsql837-64/lib

LOCALEDIR =3D

MANDIR =3D /usr/local/pgsql837-64/man

SHAREDIR =3D /usr/local/pgsql837-64/share

SYSCONFDIR =3D /usr/local/pgsql837-64/etc

PGXS =3D /usr/local/pgsql837-64/lib/pgxs/src/makefiles/pgxs.mk

CONFIGURE =3D '--prefix=3D/usr/local/pgsql837-64' '--with-pgport=3D5422'
'--enable-thr
ead-safety' '--enable-integer-datetimes' 'CC=3Dgcc -maix64'
'LDFLAGS=3D-Wl,-bbigtoc'
CC =3D gcc -maix64

CPPFLAGS =3D

CFLAGS =3D -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
-Wdeclaration-a
fter-statement -Wendif-labels -fno-strict-aliasing -fwrapv

CFLAGS_SL =3D

LDFLAGS =3D -Wl,-bbigtoc
-Wl,-blibpath:/usr/local/pgsql837-64/lib:/usr/lib:/lib
LDFLAGS_SL =3D -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE

LIBS =3D -lpgport -lz -lreadline -lld -lm

VERSION =3D PostgreSQL 8.3.7

After this I configured the ulimit for the postgres user to the
following so that it had unlimited memory access

core file size (blocks, -c) 1048575
data seg size (kbytes, -d) 131072
file size (blocks, -f) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 2000
pipe size (512 bytes, -p) 64
stack size (kbytes, -s) 32768
cpu time (seconds, -t) unlimited
max user processes (-u) 2048
virtual memory (kbytes, -v) unlimited

The version of postgres that we are running is 8.3.7. If you can see an
obvious step that I have missed out or something I haven't configured
incorrectly I would be grateful if you could let me know. Our install
isnt really using temp tables as far as I can see

Thanks again for all your help

Fran
-----Original Message-----
From: Brad Nicholson [mailto:bnichols [at] ca.afilias.info]
Sent: 16 February 2010 15:21
To: Kenneth Marshall
Cc: Tom Lane; Thorne, Francis; pgsql-admin [at] postgresql.org
Subject: Re: [ADMIN] AIX - Out of Memory

On Mon, 2010-02-15 at 10:18 -0600, Kenneth Marshall wrote:
> On Mon, Feb 15, 2010 at 10:57:06AM -0500, Tom Lane wrote:
> > "Thorne, Francis" <thornef [at] cromwell.co.uk> writes:
> > > Looking for some help with regards to an 'Out of Memory' issue I
have
> > > with our Postgresql install on AIX. When running large updates or
> > > select queries we get an out of memory error returned and details
> > > entered in the log file like below. This is a 64-bit install and
I have
> > > set the ulimit for the postgres user to unlimited.
> >
> > The bloat seems to be here:
> >
> > > AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
> > > chunks); 131063232 used
> >
> > but it's hard to believe you'd be getting "out of memory" after only
> > 130MB in a 64-bit build. Are you *sure* the postgres executable is
> > 64-bit? Are you *sure* the postmaster has been launched with
> > nonrestrictive ulimit? On lots of setups that takes modifying the
> > PG startup script, not just fooling with some user's .profile.
> >
> > > This is a 64-bit install (8.3) on AIX 5.3
> >
> > 8.3.what?
> >
> > regards, tom lane
>
> I no longer have an AIX box, but I had similar problems with other
> applications that needed large amounts of memory. Some OS specific
> steps needed to be taken to allow normal users to allocate large
> blocks of memory. The information needed was in their on-line docs
> as I recall, but I do not remember the details. The executables may
> need to be built with specific options/flags to work.
>

AIX has other limits besides the ulimit, there for security purposes I
believe. 2GB per process is the default.

To OP - what is the size of the postgres process?
Are you using temp tables heavily or frequently in a given session?

I've seen the same issue on AIX before (64 bit build) reporting out of
memory on trivial request size. The issue was due to the use of temp
tables in a single session. PG does not release the memory for the temp
tables until the session ends. The postgres process grows up the the
2GB mark, then the final trivial request pushes it over the tipping
point, and you get the out of memory error.

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

___________________________________________________

This email is intended for the named recipient. The information contained=

in it is confidential. You should not copy it for any purposes, nor
disclose its contents to any other party. If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not=

necessarily represent those of the company.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Hi Francis,

I did not see my last response so I am trying again.

From some Google-ing:

If you need more memory (larger data segment) for your
Perl programs you can set:

/etc/security/limits
default: (or your user)
data = -1 (default is 262144 * 512 byte)

With the default setting the size is limited to 128MB.
The -1 removes this limit. If the "make test" fails please
change your /etc/security/limits as stated above.

Regards,
Ken

On Tue, Feb 16, 2010 at 04:04:41PM -0000, Thorne, Francis wrote:
>
> Thanks for the prompt reply, if I'm totally honest I'm not 100% sure the
> postgres install has built correctly into a 64-bit build. I found it
> really difficult to find any documentation on how to configure Postgres
> correctly for a 64-bit install onto an AIX system. The only pieces of
> information I found where from this forum and off the back of that I
> configured postgres with the following settings.
>
> BINDIR = /usr/local/pgsql837-64/bin
>
> DOCDIR = /usr/local/pgsql837-64/doc
>
> INCLUDEDIR = /usr/local/pgsql837-64/include
>
> PKGINCLUDEDIR = /usr/local/pgsql837-64/include
>
> INCLUDEDIR-SERVER = /usr/local/pgsql837-64/include/server
>
> LIBDIR = /usr/local/pgsql837-64/lib
>
> PKGLIBDIR = /usr/local/pgsql837-64/lib
>
> LOCALEDIR =
>
> MANDIR = /usr/local/pgsql837-64/man
>
> SHAREDIR = /usr/local/pgsql837-64/share
>
> SYSCONFDIR = /usr/local/pgsql837-64/etc
>
> PGXS = /usr/local/pgsql837-64/lib/pgxs/src/makefiles/pgxs.mk
>
> CONFIGURE = '--prefix=/usr/local/pgsql837-64' '--with-pgport=5422'
> '--enable-thr
> ead-safety' '--enable-integer-datetimes' 'CC=gcc -maix64'
> 'LDFLAGS=-Wl,-bbigtoc'
> CC = gcc -maix64
>
> CPPFLAGS =
>
> CFLAGS = -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Winline
> -Wdeclaration-a
> fter-statement -Wendif-labels -fno-strict-aliasing -fwrapv
>
> CFLAGS_SL =
>
> LDFLAGS = -Wl,-bbigtoc
> -Wl,-blibpath:/usr/local/pgsql837-64/lib:/usr/lib:/lib
> LDFLAGS_SL = -Wl,-bnoentry -Wl,-H512 -Wl,-bM:SRE
>
> LIBS = -lpgport -lz -lreadline -lld -lm
>
> VERSION = PostgreSQL 8.3.7
>
> After this I configured the ulimit for the postgres user to the
> following so that it had unlimited memory access
>
> core file size (blocks, -c) 1048575
> data seg size (kbytes, -d) 131072
> file size (blocks, -f) unlimited
> max memory size (kbytes, -m) unlimited
> open files (-n) 2000
> pipe size (512 bytes, -p) 64
> stack size (kbytes, -s) 32768
> cpu time (seconds, -t) unlimited
> max user processes (-u) 2048
> virtual memory (kbytes, -v) unlimited
>
> The version of postgres that we are running is 8.3.7. If you can see an
> obvious step that I have missed out or something I haven't configured
> incorrectly I would be grateful if you could let me know. Our install
> isnt really using temp tables as far as I can see
>
> Thanks again for all your help
>
> Fran
> -----Original Message-----
> From: Brad Nicholson [mailto:bnichols [at] ca.afilias.info]
> Sent: 16 February 2010 15:21
> To: Kenneth Marshall
> Cc: Tom Lane; Thorne, Francis; pgsql-admin [at] postgresql.org
> Subject: Re: [ADMIN] AIX - Out of Memory
>
> On Mon, 2010-02-15 at 10:18 -0600, Kenneth Marshall wrote:
> > On Mon, Feb 15, 2010 at 10:57:06AM -0500, Tom Lane wrote:
> > > "Thorne, Francis" <thornef [at] cromwell.co.uk> writes:
> > > > Looking for some help with regards to an 'Out of Memory' issue I
> have
> > > > with our Postgresql install on AIX. When running large updates or
> > > > select queries we get an out of memory error returned and details
> > > > entered in the log file like below. This is a 64-bit install and
> I have
> > > > set the ulimit for the postgres user to unlimited.
> > >
> > > The bloat seems to be here:
> > >
> > > > AfterTriggerEvents: 131063808 total in 26 blocks; 576 free (7
> > > > chunks); 131063232 used
> > >
> > > but it's hard to believe you'd be getting "out of memory" after only
> > > 130MB in a 64-bit build. Are you *sure* the postgres executable is
> > > 64-bit? Are you *sure* the postmaster has been launched with
> > > nonrestrictive ulimit? On lots of setups that takes modifying the
> > > PG startup script, not just fooling with some user's .profile.
> > >
> > > > This is a 64-bit install (8.3) on AIX 5.3
> > >
> > > 8.3.what?
> > >
> > > regards, tom lane
> >
> > I no longer have an AIX box, but I had similar problems with other
> > applications that needed large amounts of memory. Some OS specific
> > steps needed to be taken to allow normal users to allocate large
> > blocks of memory. The information needed was in their on-line docs
> > as I recall, but I do not remember the details. The executables may
> > need to be built with specific options/flags to work.
> >
>
> AIX has other limits besides the ulimit, there for security purposes I
> believe. 2GB per process is the default.
>
> To OP - what is the size of the postgres process?
> Are you using temp tables heavily or frequently in a given session?
>
> I've seen the same issue on AIX before (64 bit build) reporting out of
> memory on trivial request size. The issue was due to the use of temp
> tables in a single session. PG does not release the memory for the temp
> tables until the session ends. The postgres process grows up the the
> 2GB mark, then the final trivial request pushes it over the tipping
> point, and you get the out of memory error.
>
> --
> Brad Nicholson 416-673-4106
> Database Administrator, Afilias Canada Corp.
>
>
>
> ___________________________________________________
>
> This email is intended for the named recipient. The information contained
> in it is confidential. You should not copy it for any purposes, nor
> disclose its contents to any other party. If you received this email
> in error, please notify the sender immediately via email, and delete it from
> your computer.
>
> Any views or opinions presented are solely those of the author and do not
> necessarily represent those of the company.
>
> Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
> Wigston, Leicester LE18 1AT. Tel 0116 2888000
> Registered in England and Wales, Reg No 00986161
> VAT GB 115 5713 87 900
> __________________________________________________
>
>
> --
> Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-admin
>

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Tue, 2010-02-16 at 16:04 +0000, Thorne, Francis wrote:
> Thanks for the prompt reply, if I'm totally honest I'm not 100% sure the
> postgres install has built correctly into a 64-bit build. I found it
> really difficult to find any documentation on how to configure Postgres
> correctly for a 64-bit install onto an AIX system. The only pieces of
> information I found where from this forum and off the back of that I
> configured postgres with the following settings.

Can you post the output from the following command please?

dump -X64 -ovH /<PG_PATH>/bin/postgres

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Please find details as requested, thanks again for you help

/usr/local/pgsql837-64/bin/postgres:

***Object Module Header***
# Sections Symbol Ptr # Symbols Opt Hdr Len Flags
4 0x005e247c 46124 120 0x9002
Flags=3D( EXEC DYNLOAD RWNONEXEC )
Timestamp =3D "06 Nov 12:55:11 2009"
Magic =3D 0x1f7 (64-bit XCOFF)

***Optional Header***
Tsize Dsize Bsize Tstart Dstart
0x003cc912 0x0005dde6 0x00073a38 0x100001f8 0x20000b0a

SNloader SNentry SNtext SNtoc SNdata
0x0004 0x0002 0x0001 0x0002 0x0002

TXTalign DATAalign TOC vstamp entry
0x0005 0x0003 0x20059418 0x0001 0x20039c6c

maxSTACK maxDATA SNbss magic modtype
0x00000000 0x00000000 0x0003 0x010b 1L

***Loader Section***
Loader Header Information
VERSION# #SYMtableENT #RELOCent LENidSTR
0x00000001 0x00001570 0x00004df1 0x0000003c =

#IMPfilID OFFidSTR LENstrTBL OFFstrTBL
0x00000002 0x0006e1c8 0x000183c0 0x0006e204 =

***Import File Strings***
INDEX PATH BASE MEMBER

0 /usr/local/pgsql837-64/lib:/usr/lib:/lib

1 libc.a shr_64.o

Francis

-----Original Message-----
From: Brad Nicholson [mailto:bnichols [at] ca.afilias.info]
Sent: 16 February 2010 16:36
To: Thorne, Francis
Cc: pgsql-admin [at] postgresql.org
Subject: RE: [ADMIN] AIX - Out of Memory

On Tue, 2010-02-16 at 16:04 +0000, Thorne, Francis wrote:
> Thanks for the prompt reply, if I'm totally honest I'm not 100% sure
the
> postgres install has built correctly into a 64-bit build. I found it
> really difficult to find any documentation on how to configure
Postgres
> correctly for a 64-bit install onto an AIX system. The only pieces of
> information I found where from this forum and off the back of that I
> configured postgres with the following settings.

Can you post the output from the following command please?

dump -X64 -ovH /<PG_PATH>/bin/postgres

--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

___________________________________________________

This email is intended for the named recipient. The information contained=

in it is confidential. You should not copy it for any purposes, nor
disclose its contents to any other party. If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not=

necessarily represent those of the company.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Tue, 2010-02-16 at 16:44 +0000, Thorne, Francis wrote:
> Please find details as requested, thanks again for you help
>
> /usr/local/pgsql837-64/bin/postgres:
>
> ***Object Module Header***
> # Sections Symbol Ptr # Symbols Opt Hdr Len Flags
> 4 0x005e247c 46124 120 0x9002
> Flags=( EXEC DYNLOAD RWNONEXEC )
> Timestamp = "06 Nov 12:55:11 2009"
> Magic = 0x1f7 (64-bit XCOFF)

Your binary is 64-bit.

> ***Optional Header***
> Tsize Dsize Bsize Tstart Dstart
> 0x003cc912 0x0005dde6 0x00073a38 0x100001f8 0x20000b0a
>
> SNloader SNentry SNtext SNtoc SNdata
> 0x0004 0x0002 0x0001 0x0002 0x0002
>
> TXTalign DATAalign TOC vstamp entry
> 0x0005 0x0003 0x20059418 0x0001 0x20039c6c
>
> maxSTACK maxDATA SNbss magic modtype
> 0x00000000 0x00000000 0x0003 0x010b 1L

Bingo - maxDATA of 0x00000000. Ken's posting was correct. You have
1x256MB segment of memory available per process.

If you watch your server process while this is happening, it will be
hitting 256MB in size.

Upping this limit is probably the way to go. You can use the ldedit
command to up this limit for your binaries, or specify it when you build
Postgres. See the file docs/FAQ_AIX with the PG source for details.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

Hi Brad,

Thanks for all your help with this, sorry for my ignorance on this.
I've read through the F.A.O and found the section on setting MAXDATA but
can only see the example of setting this to 0x00000000 for 32-bit. I
cant see any example of what I need to change this to if I wanted to run
64-bit, I don't suppose you have an idea what I would need to change
this maxData figure to.

I assume using the LDEDIT command the maxData setting can be changed on
the fly and we wont need to re-compile Postgres.

Thanks again for all your help and patience !!

Fran

-----Original Message-----
From: Brad Nicholson [mailto:bnichols [at] ca.afilias.info]
Sent: 16 February 2010 18:46
To: Thorne, Francis
Cc: pgsql-admin [at] postgresql.org
Subject: RE: [ADMIN] AIX - Out of Memory

On Tue, 2010-02-16 at 16:44 +0000, Thorne, Francis wrote:
> Please find details as requested, thanks again for you help
>
> /usr/local/pgsql837-64/bin/postgres:
>
> ***Object Module Header***
> # Sections Symbol Ptr # Symbols Opt Hdr Len Flags
> 4 0x005e247c 46124 120 0x9002
> Flags=3D( EXEC DYNLOAD RWNONEXEC )
> Timestamp =3D "06 Nov 12:55:11 2009"
> Magic =3D 0x1f7 (64-bit XCOFF)

Your binary is 64-bit.

> ***Optional Header***
> Tsize Dsize Bsize Tstart Dstart
> 0x003cc912 0x0005dde6 0x00073a38 0x100001f8 0x20000b0a
>
> SNloader SNentry SNtext SNtoc SNdata
> 0x0004 0x0002 0x0001 0x0002 0x0002
>
> TXTalign DATAalign TOC vstamp entry
> 0x0005 0x0003 0x20059418 0x0001 0x20039c6c
>
> maxSTACK maxDATA SNbss magic modtype
> 0x00000000 0x00000000 0x0003 0x010b 1L

Bingo - maxDATA of 0x00000000. Ken's posting was correct. You have
1x256MB segment of memory available per process.

If you watch your server process while this is happening, it will be
hitting 256MB in size.

Upping this limit is probably the way to go. You can use the ldedit
command to up this limit for your binaries, or specify it when you build
Postgres. See the file docs/FAQ_AIX with the PG source for details.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

___________________________________________________

This email is intended for the named recipient. The information contained=

in it is confidential. You should not copy it for any purposes, nor
disclose its contents to any other party. If you received this email
in error, please notify the sender immediately via email, and delete it from
your computer.

Any views or opinions presented are solely those of the author and do not=

necessarily represent those of the company.

Cromwell Tools Limited, PO Box 14, 65 Chartwell Drive
Wigston, Leicester LE18 1AT. Tel 0116 2888000
Registered in England and Wales, Reg No 00986161
VAT GB 115 5713 87 900
__________________________________________________

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

On Thu, 2010-02-18 at 08:46 +0000, Thorne, Francis wrote:
> Hi Brad,
>
> Thanks for all your help with this, sorry for my ignorance on this.
> I've read through the F.A.O and found the section on setting MAXDATA but
> can only see the example of setting this to 0x00000000 for 32-bit. I
> cant see any example of what I need to change this to if I wanted to run
> 64-bit, I don't suppose you have an idea what I would need to change
> this maxData figure to.

We've set ours to the upper limit of 2GB (0x80000000). Your usage may
vary. You'll need to take into account the expected size of your
processes * the number of expected processes and make sure you have
enough RAM in the system to handle it.

> I assume using the LDEDIT command the maxData setting can be changed on
> the fly and we wont need to re-compile Postgres.

It can be, but I'm not sure exactly which components you will need to
touch.

We always build our binaries passing with this set higher, so I can't
comment on the effects of changing it on existing ones.

> Thanks again for all your help and patience !!
>
> Fran
>
> -----Original Message-----
> From: Brad Nicholson [mailto:bnichols [at] ca.afilias.info]
> Sent: 16 February 2010 18:46
> To: Thorne, Francis
> Cc: pgsql-admin [at] postgresql.org
> Subject: RE: [ADMIN] AIX - Out of Memory
>
> On Tue, 2010-02-16 at 16:44 +0000, Thorne, Francis wrote:
> > Please find details as requested, thanks again for you help
> >
> > /usr/local/pgsql837-64/bin/postgres:
> >
> > ***Object Module Header***
> > # Sections Symbol Ptr # Symbols Opt Hdr Len Flags
> > 4 0x005e247c 46124 120 0x9002
> > Flags=( EXEC DYNLOAD RWNONEXEC )
> > Timestamp = "06 Nov 12:55:11 2009"
> > Magic = 0x1f7 (64-bit XCOFF)
>
> Your binary is 64-bit.
>
> > ***Optional Header***
> > Tsize Dsize Bsize Tstart Dstart
> > 0x003cc912 0x0005dde6 0x00073a38 0x100001f8 0x20000b0a
> >
> > SNloader SNentry SNtext SNtoc SNdata
> > 0x0004 0x0002 0x0001 0x0002 0x0002
> >
> > TXTalign DATAalign TOC vstamp entry
> > 0x0005 0x0003 0x20059418 0x0001 0x20039c6c
> >
> > maxSTACK maxDATA SNbss magic modtype
> > 0x00000000 0x00000000 0x0003 0x010b 1L
>
> Bingo - maxDATA of 0x00000000. Ken's posting was correct. You have
> 1x256MB segment of memory available per process.
>
> If you watch your server process while this is happening, it will be
> hitting 256MB in size.
>
> Upping this limit is probably the way to go. You can use the ldedit
> command to up this limit for your binaries, or specify it when you build
> Postgres. See the file docs/FAQ_AIX with the PG source for details.
--
Brad Nicholson 416-673-4106
Database Administrator, Afilias Canada Corp.

--
Sent via pgsql-admin mailing list (pgsql-admin [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin

AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory

Re: AIX - Out of Memory