Thread: AIX - Out of Memory
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 = 9999999.99 where price2 = 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
__________________________________________________
"Thorne, Francis" <thornef@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
On Mon, Feb 15, 2010 at 10:57:06AM -0500, Tom Lane wrote: > "Thorne, Francis" <thornef@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
--- On Mon, 2/15/10, Kenneth Marshall <ktm@rice.edu> wrote: > From: Kenneth Marshall <ktm@rice.edu> > Subject: Re: [ADMIN] AIX - Out of Memory > To: "Tom Lane" <tgl@sss.pgh.pa.us> > Cc: "Thorne, Francis" <thornef@cromwell.co.uk>, pgsql-admin@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@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 > Ken, I recently saw a similar issue. It is two-fold: 1. I used "su -" to become the postgres user, and inherited the previous account's memory limits, 2. AfterTriggerEvents queues are caused by foreign key constraints, one per row. If you're loading data, dropping or disablingthat constraint makes a world of difference. Just be sure to check afterwards if the RI has been violated priorto recreating the FK constraint. Bob
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@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.
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@ca.afilias.info] Sent: 16 February 2010 15:21 To: Kenneth Marshall Cc: Tom Lane; Thorne, Francis; pgsql-admin@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@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 __________________________________________________
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@ca.afilias.info]
> Sent: 16 February 2010 15:21
> To: Kenneth Marshall
> Cc: Tom Lane; Thorne, Francis; pgsql-admin@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@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@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.
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)
***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@ca.afilias.info]
Sent: 16 February 2010 16:36
To: Thorne, Francis
Cc: pgsql-admin@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
__________________________________________________
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.
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@ca.afilias.info] Sent: 16 February 2010 18:46 To: Thorne, Francis Cc: pgsql-admin@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. ___________________________________________________ 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 __________________________________________________
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@ca.afilias.info] > Sent: 16 February 2010 18:46 > To: Thorne, Francis > Cc: pgsql-admin@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.