[pgpool-general: 5651] Re: oom when memory_cache_enabled is on
Pavel
balroga3 at yandex.ru
Fri Jul 28 17:22:40 JST 2017
Yes, of course. I wrongly put an equal sign between number of selects
and number of connections. Sorry.
Our testing software reconnects, but not as often.
You wrote 28 июля 2017 г., 2:05:37:
> To fire child_max_connections, your client needs to reconnect to
> Pgpool-II. Just sending many selects does not trigger it.
> Best regards,
> --
> Tatsuo Ishii
> SRA OSS, Inc. Japan
> English: http://www.sraoss.co.jp/index_en.php
> Japanese:http://www.sraoss.co.jp
>> I've tried to force pgpool to restart its child processes by setting
>> really low numbers in child_max_connections, for example
>> child_max_connections = 10
>> but still even after serving more than 200k selects with
>> max_init_children = 500 all pgpool child processes' pids are the
>> same as they were right after pgpool start.
>>
>> Does it mean that pgpool didn't restart any of its childs or is this
>> an expected behaviour and child's pid is not supposed to change when
>> pgpool restarts its child process?
>>
>>
>>> Hello.
>>
>>> We started testing our project under heavy load and encountered out of
>>> memory condition if pgpool is running with memory_cache_enabled=on, both
>>> with shmem and memcached.
>>
>>> Under simulated heavy load pgpool consumes all available memory (16Gb)
>>> in just a few minutes and then kernel kills it.
>>
>>> I've found this old similar bug thread:
>>> http://www.pgpool.net/mantisbt/view.php?id=52
>>> and tried running pgpool with valgrind, but (perhaps due to high
>>> number of pgpool childs?) system was almost unresponsive and i had to
>>> restart pgpool without valgrind.
>>
>>> I'm attaching pgpool log which was written during the short period of
>>> valgrind activity.
>>> There are some records, but I have zero experience in this area and I
>>> have no idea if they are indicating a problem or not. One of the
>>> records:
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== at
>>> 0x4C2DB8F: malloc (in
>>> /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== by
>>> 0x448063: save_ps_display_args (ps_status.c:173)
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== by 0x407F41: main (main.c:192)
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612==
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== LEAK SUMMARY:
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612==
>>> definitely lost: 96 bytes in 1 blocks
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612==
>>> indirectly lost: 343 bytes in 11 blocks
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612==
>>> possibly lost: 0 bytes in 0 blocks
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== still
>>> reachable: 254,475 bytes in 3,102 blocks
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== suppressed: 0 bytes in 0 blocks
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== Reachable
>>> blocks (those to which a pointer was found) are not shown.
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== To see
>>> them, rerun with: --leak-check=full --show-leak-kinds=all
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612==
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== For counts
>>> of detected and suppressed errors, rerun with: -v
>>> Jul 26 09:27:59 ip-172-31-26-132 pgpool2[3707]: ==4612== ERROR
>>> SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
>>
>>
>>
>>> "ulimit -a" output of user postgres (pgpool is running under this
>>> account):
>>> postgres at ip-172-31-26-132:~$ ulimit -a
>>> core file size (blocks, -c) 0
>>> data seg size (kbytes, -d) unlimited
>>> scheduling priority (-e) 0
>>> file size (blocks, -f) unlimited
>>> pending signals (-i) 64124
>>> max locked memory (kbytes, -l) 64
>>> max memory size (kbytes, -m) unlimited
>>> open files (-n) 10000
>>> pipe size (512 bytes, -p) 8
>>> POSIX message queues (bytes, -q) 819200
>>> real-time priority (-r) 0
>>> stack size (kbytes, -s) 8192
>>> cpu time (seconds, -t) unlimited
>>> max user processes (-u) 64124
>>> virtual memory (kbytes, -v) unlimited
>>> file locks (-x) unlimited
>>
>>
>>
>>
>>
>>
>>
>> --
>> Best regards,
>> Pavel mailto:balroga3 at yandex.ru
>>
>> _______________________________________________
>> pgpool-general mailing list
>> pgpool-general at pgpool.net
>> http://www.pgpool.net/mailman/listinfo/pgpool-general
--
Best regards,
Pavel mailto:balroga3 at yandex.ru
More information about the pgpool-general
mailing list