[Pgpool-general] 3.0.1 memory leaks?
takehiro wada
takehiro.wada at gmail.com
Wed Aug 24 07:35:24 UTC 2011
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.asaba at 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 <glynastill at 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.wada at gmail.com>
> > To: Glyn Astill <glynastill at yahoo.co.uk>
> > Cc: "pgpool-general at pgfoundry.org" <pgpool-general at 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 <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
> > http://pgfoundry.org/mailman/listinfo/pgpool-general
> >
> >
> >
> >
> > _______________________________________________
> > Pgpool-general mailing list
> > 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
> >
> >
>
>
>
> --
> Yoshiyuki Asaba
> ysyk.asaba at gmail.com
>
--
*************************
Name:Takehiro Wada
mail:takehiro.wada at gmail.com
*************************
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pgfoundry.org/pipermail/pgpool-general/attachments/20110824/d2dd2f4f/attachment-0001.html>
More information about the Pgpool-general
mailing list