Hi Glyn Asaba-san posted patch of a memory leak issue.( I confirmed that this issue already fixed pgpool-II-3.0.1-beta2). If your problem is same my memory leak issue, this problem is pgpool does NOT call free_parse(). or you do not use connection pooling, I think this problem does NOT occur. if you shutdown a connection, parser memory is cleared..
thanks 2011/8/24 Yoshiyuki Asaba <ysyk.as...@gmail.com> > I posted a patch for this issue. Could anybody review the patch? > > http://lists.pgfoundry.org/pipermail/pgpool-general/2011-July/003797.html > > Thanks, > > 2011/8/23 Glyn Astill <glynast...@yahoo.co.uk>: > > 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 <takehiro.w...@gmail.com> > > To: Glyn Astill <glynast...@yahoo.co.uk> > > Cc: "pgpool-general@pgfoundry.org" <pgpool-general@pgfoundry.org> > > 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 <glynast...@yahoo.co.uk> > > To: pgpool-general@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@pgfoundry.org > > http://pgfoundry.org/mailman/listinfo/pgpool-general > > > > > > > > > > _______________________________________________ > > Pgpool-general mailing list > > Pgpool-general@pgfoundry.org > > http://pgfoundry.org/mailman/listinfo/pgpool-general > > > > > > > > > > _______________________________________________ > > Pgpool-general mailing list > > Pgpool-general@pgfoundry.org > > http://pgfoundry.org/mailman/listinfo/pgpool-general > > > > > > > > -- > Yoshiyuki Asaba > ysyk.as...@gmail.com > -- ************************* Name:Takehiro Wada mail:takehiro.w...@gmail.com *************************
_______________________________________________ Pgpool-general mailing list Pgpool-general@pgfoundry.org http://pgfoundry.org/mailman/listinfo/pgpool-general
