Issues still occour with V3_0_STABLE as shown below:
4873 root 20 0 199m 102m 968 S 0 1.3 0:29.89 pgpool: glyn SEE
10.10.100.101(27550) idle
4491 root 20 0 199m 102m 996 S 0 1.3 0:48.80 pgpool: glyn TEMP
10.10.100.101(27551) idle
Is this what you meant Takehiro? I believe CVS head is now v3.1 is it not?
These are quite aparent leaks, not sure just how they have been missed.
Can someone please advise? Should be ba abandonign 3.0.4 and test with 3.1
onwards, and if so is there a timeline for it coming out of beta?
Thanks
Glyn
>________________________________
>From: TakehiroWada <[email protected]>
>To: Glyn Astill <[email protected]>
>Cc: "[email protected]" <[email protected]>
>Sent: Thursday, 18 August 2011, 16:27
>Subject: Re: [Pgpool-general] 3.0.1 memory leaks?
>
>
>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 <[email protected]>
>>>To: [email protected]
>>>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
>>>[email protected]
>>>http://pgfoundry.org/mailman/listinfo/pgpool-general
>>>
>>>
>>>
>>
>>
>>_______________________________________________
Pgpool-general mailing list [email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-general
>
>
>_______________________________________________
Pgpool-general mailing list
[email protected]
http://pgfoundry.org/mailman/listinfo/pgpool-general
