From: | "Daniel Westermann (DWE)" <daniel(dot)westermann(at)dbi-services(dot)com> |
---|---|
To: | "pgsql-general(at)lists(dot)postgresql(dot)org" <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Out of memory with "create extension postgis" |
Date: | 2020-07-28 08:42:17 |
Message-ID: | ZR0P278MB0122BE5FB48902BADDD9ED17D2730@ZR0P278MB0122.CHEP278.PROD.OUTLOOK.COM |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Hi,
we have a very strange behavior on PostgreSQL 12.3 when we try to create the extension postgis. Postgres and postgis have both been installed from packages:
postgresql12-server-12.3-5PGDG
postgis30_12-3.0.1-5.rhel7
The OS is RedHat 7.7.
Creating other extensions works fine, we only see this for postgis. A gdb session attached to the psql process while creating the extension gives:
Program received signal SIGINT, Interrupt.
0x00007f19c0de9740 in __read_nocancel () from /lib64/libpthread.so.0
Detaching from program: /usr/pgsql-12/bin/psql, process 44202
The process eats all the available memory and finally dies:
# create extension postgis;
ERROR: out of memory
DETAIL: Failed on request of size 8265691 in memory context "PortalContext".
Time: 773569.877 ms (12:53.570)
Stats file from /proc:
# cat status
Name: psql
Umask: 0022
State: S (sleeping)
Tgid: 45958
Ngid: 0
Pid: 45958
PPid: 44075
TracerPid: 0
Uid: 280 280 280 280
Gid: 280 280 280 280
FDSize: 256
Groups: 280
VmPeak: 184604 kB
VmSize: 184600 kB
VmLck: 0 kB
VmPin: 0 kB
VmHWM: 4304 kB
VmRSS: 4304 kB
RssAnon: 980 kB
RssFile: 3324 kB
RssShmem: 0 kB
VmData: 672 kB
VmStk: 132 kB
VmExe: 604 kB
VmLib: 11288 kB
VmPTE: 180 kB
VmSwap: 0 kB
Threads: 1
SigQ: 0/15635
SigPnd: 0000000000000000
ShdPnd: 0000000000000000
SigBlk: 0000000000000000
SigIgn: 0000000000000000
SigCgt: 0000000180000002
CapInh: 0000000000000000
CapPrm: 0000000000000000
CapEff: 0000000000000000
CapBnd: 0000001fffffffff
CapAmb: 0000000000000000
NoNewPrivs: 0
Seccomp: 0
Speculation_Store_Bypass: thread vulnerable
Cpus_allowed: ffffffff,ffffffff,ffffffff,ffffffff
Cpus_allowed_list: 0-127
Mems_allowed: 00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000001
Mems_allowed_list: 0
voluntary_ctxt_switches: 47
stack file from /proc:
# cat stack
[<ffffffffa0c60805>] poll_schedule_timeout+0x55/0xc0
[<ffffffffa0c61f9d>] do_sys_poll+0x48d/0x590
[<ffffffffa0c621a4>] SyS_poll+0x74/0x110
[<ffffffffa118dede>] system_call_fastpath+0x25/0x2a
[<ffffffffffffffff>] 0xffffffffffffffff
limits from /proc:
# cat limits
Limit Soft Limit Hard Limit Units
Max cpu time unlimited unlimited seconds
Max file size unlimited unlimited bytes
Max data size unlimited unlimited bytes
Max stack size 8388608 unlimited bytes
Max core file size 0 0 bytes
Max resident set unlimited unlimited bytes
Max processes 4096 15635 processes
Max open files 1024 4096 files
Max locked memory 65536 65536 bytes
Max address space unlimited unlimited bytes
Max file locks unlimited unlimited locks
Max pending signals 15635 15635 signals
Max msgqueue size 819200 819200 bytes
Max nice priority 0 0
Max realtime priority 0 0
Max realtime timeout unlimited unlimited us
Stracing the psql process shows no activity. Looking at the used swap shows that the postmaster uses a huge amount:
find /proc -maxdepth 2 -path "/proc/[0-9]*/status" -readable -exec awk -v FS=":" '{process[$1]=$2;sub(/^[ \t]+/,"",process[$1]);} END {if(process["VmSwap"] && process["VmSwap"] != "0 kB") printf "%10s %-30s %20s\n",process["Pid"],process["Name"],process["VmSwap"]}' '{}' \;
...
48043 psql 1004 kB
48044 postmaster 21948064 kB
49059 postmaster 1008 kB
52550 rhsmcertd 144 kB
...
Any hints what could be the issue? Can I provide any other information that would help troubleshooting this issue?
Thanks in advance
Daniel
From | Date | Subject | |
---|---|---|---|
Next Message | Shaozhong SHI | 2020-07-28 10:54:10 | Issues of slow running queries when dealing with Big Data |
Previous Message | David Rowley | 2020-07-28 03:55:36 | Re: is JIT available |