[Pgpool-general] 3.0.1 memory leaks?
TakehiroWada
takehiro.wada at gmail.com
Thu Aug 18 15:27:16 UTC 2011
Hi Glyn
the similar issue occurs pgpool(3.0.1 and 3.0.3) of my env.
I think this issue is because pgpool does not call free_parse().
my issue does not occur on CVS head version.
Please check whether your issue occurs on CVS head version?
thanks
(11/08/18 18:53), Glyn Astill wrote:
> Hi Guys,
>
> Just reviving this thread. We are using PgPool in raw mode on Linux
> and I'm still seeing this massive consumption of memory by the pgpool
> child processes in 3.0.4. If you look at the outputs of "ps aux"
> below you gan see the huge difference between 2.3.3 and 3.0.4
>
> Pgpool 2.3.3:
>
> Way5-pool2:~# ps aux
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> pgpool 16941 3.0 0.0 70236 2212 pts/0 S 09:24 0:17
> pgpool: glyn SEE 10.10.100.101(61398) idle
> pgpool 17012 5.6 0.0 70876 2900 pts/0 S 09:24 0:31
> pgpool: glyn TEMP 10.10.100.101(61399) idle
>
> Pgpool 3.0.4:
>
> Way5-pool:/tmp# ps aux (3.0.4)
> USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
> pgpool 22724 0.0 5.0 172980 104120 pts/1 S Aug17 0:05
> pgpool: glyn TEMP 10.10.100.101(61429) idle
> pgpool 24539 0.0 5.0 173156 104192 pts/1 S Aug17 0:03
> pgpool: glyn SEE 10.10.100.101(61428) idle
>
> I'm using the same configuration file for both as follows:
>
> listen_addresses = '*'
> port = 5432
> pcp_port = 9898
> socket_dir = '/tmp'
> pcp_socket_dir = '/tmp'
> backend_socket_dir = '/tmp'
> pcp_timeout = 10
> num_init_children = 600
> max_pool = 1
> child_life_time = 300
> connection_life_time = 30
> child_max_connections = 0
> client_idle_limit = 0
> authentication_timeout = 60
> logdir = '/tmp'
> pid_file_name = '/var/run/pgpool/pgpool.pid'
> replication_mode = false
> load_balance_mode = false
> replication_stop_on_mismatch = false
> failover_if_affected_tuples_mismatch = false
> replicate_select = false
> reset_query_list = 'ABORT; DISCARD ALL'
> white_function_list = ''
> black_function_list = 'nextval,setval'
> print_timestamp = true
> master_slave_mode = false
> master_slave_sub_mode = 'slony'
> delay_threshold = 0
> log_standby_delay = 'none'
> connection_cache = true
> health_check_timeout = 20
> health_check_period = 0
> health_check_user = 'nobody'
> failover_command = ''
> fail_over_on_backend_error = true
> insert_lock = false
> ignore_leading_white_space = true
> log_statement = false
> log_per_node_statement = false
> log_connections = false
> log_hostname = false
> parallel_mode = false
> enable_query_cache = false
> pgpool2_hostname = ''
> system_db_hostname = 'localhost'
> system_db_port = 5432
> system_db_dbname = 'pgpool'
> system_db_schema = 'pgpool_catalog'
> system_db_user = 'pgpool'
> system_db_password = ''
> backend_hostname0 = '10.10.10.95'
> backend_port0 = 5432
> backend_weight0 = 1
> enable_pool_hba = false
> recovery_user = 'nobody'
> recovery_password = ''
> recovery_1st_stage_command = ''
> recovery_2nd_stage_command = ''
> recovery_timeout = 90
> client_idle_limit_in_recovery = 0
> lobj_lock_table = ''
> ssl = false
> debug_level = 0
>
> Does anyone know why this might be?
>
> Thanks
> Glyn
>
> ------------------------------------------------------------------------
> *From:* Glyn Astill <glynastill at yahoo.co.uk>
> *To:* pgpool-general at pgfoundry.org
> *Sent:* Friday, 4 February 2011, 12:39
> *Subject:* [Pgpool-general] 3.0.1 memory leaks?
>
> Hi Guys,
>
> Yesterday I deployed 3.0.1 to one of our connection pool servers,
> however the machine appears to have crashed after running out of
> memory.
>
> I've just run a simple test here, with pgpool in raw mode. All
> I've done is write a program to connect, prepare, execute and
> deallocate a statement over and over in a loop. The program has
> been running for about hour and the child pgpool process is using
> 600Mb of memory and increasing (see below).
>
> Any ideas how to track this down?
>
> Thanks
> Glyn
>
> Way5-pool:/var/log# cat /proc/2885/status
> Name: pgpool
> State: S (sleeping)
> Tgid: 2885
> Pid: 2885
> PPid: 2852
> TracerPid: 0
> Uid: 1000 1000 1000 1000
> Gid: 1 1 1 1
> FDSize: 64
> Groups: 1
> VmPeak: 629344 kB
> VmSize: 629344 kB
> VmLck: 0 kB
> VmHWM: 561736 kB
> VmRSS: 561736 kB
> VmData: 560780 kB
> VmStk: 88 kB
> VmExe: 824 kB
> VmLib: 6840 kB
> VmPTE: 1224 kB
> Threads: 1
> SigQ: 0/16375
> SigPnd: 0000000000000000
> ShdPnd: 0000000000000000
> SigBlk: 0000000000000000
> SigIgn: 0000000000003000
> SigCgt: 0000000180004a07
> CapInh: 0000000000000000
> CapPrm: 0000000000000000
> CapEff: 0000000000000000
> CapBnd: ffffffffffffffff
> Cpus_allowed: 0000000f
> Cpus_allowed_list: 0-3
> Mems_allowed: 00000000,00000003
> Mems_allowed_list: 0-1
> voluntary_ctxt_switches: 2314936
> nonvoluntary_ctxt_switches: 77355
>
>
>
>
>
>
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org <mailto:Pgpool-general at pgfoundry.org>
> http://pgfoundry.org/mailman/listinfo/pgpool-general
>
>
>
>
> _______________________________________________
> Pgpool-general mailing list
> Pgpool-general at pgfoundry.org
> http://pgfoundry.org/mailman/listinfo/pgpool-general
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20110819/86a0fad7/attachment.html>
More information about the Pgpool-general
mailing list