[ZBX-9722] postgresql memory leak Created: 2015 Jul 21 Updated: 2017 May 30 Resolved: 2015 Jul 21 |
|
Status: | Closed |
Project: | ZABBIX BUGS AND ISSUES |
Component/s: | Server (S) |
Affects Version/s: | 2.4.5 |
Fix Version/s: | None |
Type: | Incident report | Priority: | Trivial |
Reporter: | Peter Slavov | Assignee: | Unassigned |
Resolution: | Won't fix | Votes: | 0 |
Labels: | None | ||
Remaining Estimate: | Not Specified | ||
Time Spent: | Not Specified | ||
Original Estimate: | Not Specified |
Attachments: | zabbix_server.conf |
Description |
Hi, update trends set num=60,value_min=100.000000,value_avg=100.000000,value_max=100.000000 where itemid=37068 and clock=1437400800; update trends set num=60,value_min=99.910962,value_avg=99.910995,value_max=99.911000 where itemid=27705 and clock=1437400800; update trends set num=60,value_min=0.000000,value_avg=0.000000,value_max=0.000000 where itemid=31660 and clock=1437400800; update trends set num=60,value_min=96.644629,value_avg=96.644700,value_max=96.644709 where itemid=37192 and clock=1437400800; ... more like this When this happens, on the postgresql server (which is different server) the full amount of RAM + swap starts to be taken until the whole memory is full and the queries crashes with "out of memory" error. |
Comments |
Comment by Aleksandrs Saveljevs [ 2015 Jul 21 ] |
It should be noted just in case that the way you have obfuscated private information in "zabbix_server.conf" seems suspicious. You might wish to remove the current file and reattach a file obfuscated properly. |
Comment by richlv [ 2015 Jul 21 ] |
that does not seem to be a zabbix issue at all - maybe pgsql is configured to use more memory for buffers than available, maybe something else. overall db activity should not push it out of available memory. |
Comment by Peter Slavov [ 2015 Jul 21 ] |
yes I did that thanks. This was some old configurations that wore commented a while back... |
Comment by Peter Slavov [ 2015 Jul 21 ] |
@richlv Shared buffers in postgresql are configured to use 1GB and the memory consumed here is 4GB RAM + 8GB swap; |
Comment by richlv [ 2015 Jul 21 ] |
the sql queries to update multiple rows in one go are more complicated and we don't have tests showing performance being better one way or another. if you do tests, please do attach the results here, then we would have something to work from. |
Comment by Peter Slavov [ 2015 Jul 21 ] |
The difference here can be one execution plan and one lock VS multiple execution plans and multiple locks over the table, |
Comment by Peter Slavov [ 2015 Jul 22 ] |
Hi,
2. WHEN tables are not partitioned with 50 updates:
Anyway - I realize that this will never be changed, because there is no value for you, because you don't recommend partitioning. |