Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1aQCiF-0006vl-IM for pgsql-admin@arkaria.postgresql.org; Mon, 01 Feb 2016 11:32:07 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84) (envelope-from ) id 1aQCiE-0003Mn-Is for pgsql-admin@arkaria.postgresql.org; Mon, 01 Feb 2016 11:32:06 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84) (envelope-from ) id 1aQCiE-0003Mh-8l for pgsql-admin@postgresql.org; Mon, 01 Feb 2016 11:32:06 +0000 Received: from mail-wm0-x22b.google.com ([2a00:1450:400c:c09::22b]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1aQCiA-0005sK-Vg for pgsql-admin@postgresql.org; Mon, 01 Feb 2016 11:32:05 +0000 Received: by mail-wm0-x22b.google.com with SMTP id 128so66252582wmz.1 for ; Mon, 01 Feb 2016 03:32:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:subject:from:reply-to:to:date:in-reply-to:references :content-type:mime-version:content-transfer-encoding; bh=F6pf3dwWXL0v8vM3b3MGWDsJkwRN2Nz3KlazvmLzGKY=; b=MFnAFg8GQLjRzeJeCAvq0D1vF2bWQT4owns5vUH3jJwqNZHEzuFdFOQoSsOAIptQaH IbpnyVT3TeiVa2xZNvrQehKB62r0enXRHiNANjF2h+CnkV7dH9cY/ym+1wiB0oyLVBsS ZHDy7gjZbwOxBqOPfx+vg0oMkqpLgtJ3TzJ9K8Nt7nh52+P26U6UGHHPh+GAL7oweUGy o/5SsRfjTXJt+kdDMdAjdAB5akpkUK5Mr8nHtcJHFqvq6yC+PyLd6UsSDgUz5SyF5Vjx JBfSYW1zEIBxdeUcWMjmQkIhqzpZpZyd8p5rFnQds5hW91t5bZnedktxFbdAgcuyYkm6 zfhw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:subject:from:reply-to:to:date :in-reply-to:references:content-type:mime-version :content-transfer-encoding; bh=F6pf3dwWXL0v8vM3b3MGWDsJkwRN2Nz3KlazvmLzGKY=; b=Lj7c4FfN1vJ/f1+EJMkuEFhUZgAW+74E2HiqbwC9W1QuLIQaIShEETDIfBb+tBkzfl Cz3NAFbo5qL259jiFuRl4isC1YAcq5Ma6YbpunnTzrQlDiEW11GjSXoWZt47UL0cC92/ /gXM3XL5VRfK5Ga3XbQHWKGJrK3n4+udWcGjkpLCrMKJwin2ubieBA35TZnDPUXdf5Ts jb5jiF7BWJMUMDNN4MEe1lgzINu9JNYDUPN3gQ72/bJhdfEclyXVu9nt4+y0FZkXkLCy ZAMQC2sKM8oKDlVJjIoiGNjqNoNao0mykNkzBqTwH3htflV3c2hqw1Npq1M9BL9v4kMv SGDg== X-Gm-Message-State: AG10YOSWFBoZym2CFixVbXKQY9QvIzg3O/Y+VV9eKgvpTwk9NddVlnYOIIb46ivPOoxIEw== X-Received: by 10.28.156.73 with SMTP id f70mr4342966wme.52.1454326322316; Mon, 01 Feb 2016 03:32:02 -0800 (PST) Received: from enterprisedb01 (148.Red-83-52-254.dynamicIP.rima-tde.net. [83.52.254.148]) by smtp.googlemail.com with ESMTPSA id v22sm4838869wmv.12.2016.02.01.03.32.01 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 01 Feb 2016 03:32:01 -0800 (PST) Message-ID: <1454326320.5847.85.camel@gmail.com> Subject: Re: Per thread Connection memory From: jaime soler Reply-To: jaime.soler@gmail.com To: Thorsten =?ISO-8859-1?Q?Sch=F6ning?= , pgsql-admin Date: Mon, 01 Feb 2016 12:32:00 +0100 In-Reply-To: <34973063.20160129141840@am-soft.de> References: <1690525.20160127153353@am-soft.de> <34973063.20160129141840@am-soft.de> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.16.5-1ubuntu3.1 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-Pg-Spam-Score: -2.7 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-admin Precedence: bulk Sender: pgsql-admin-owner@postgresql.org El vie, 29-01-2016 a las 14:18 +0100, Thorsten Schöning escribió: > Guten Tag Ankur Kaushik, > am Freitag, 29. Januar 2016 um 13:16 schrieben Sie: > > > To Kill idle connection in every 10 sec , But after 15 -30 Min top > > command show as below > > Killing idle connections is completely pointless, because those are > kept open for performance reasons, pgbouncer is designed to keep > connections open and idle, so that applications use them faster. If > you want less idle connections, reduce the configuration for those in > pgbouncer, but in the end you defeat its purpose that way. +1. If you don't want to keep many connections open in idle state, you can configure them at pgbouncer level or pool configuration in tomcat or application level. > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ > > COMMAND > > 10454 root 20 0 7101m 2.4g 11m S 751.3 15.4 > > 84:47.60 java > > You problem is obviously that you don't have any clue what your > problem is, therefore you're just guessing things around. Don't do > that, at least look at the logs of your Tomcat, you may even use Java > Mission Control to monitor the performance of Tomcat and so on. This > high load might even be the result of your script introducing some > kind of a race condition, where you kill a connection just in that > moment where it was given to a using process in Tomcat. Java is consuming 7/8 core of cpu, so i think you your look closer into tomcat and java processes. How about your work_mem parameter and top stats relatives of postgresql server ? > > If your problem is with Tomcat consuming too much memory or having > unexplainable high CPU load, don't waste your time with advancing the > complexity of your setup by installing pgbouncer. Focus on Tomcat and > its logs first. +1 > > Mit freundlichen Grüßen, > > Thorsten Schöning > > -- > Thorsten Schöning E-Mail: Thorsten.Schoening@AM-SoFT.de > AM-SoFT IT-Systeme http://www.AM-SoFT.de/ > > Telefon...........05151- 9468- 55 > Fax...............05151- 9468- 88 > Mobil..............0178-8 9468- 04 > > AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln > AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow > > > -- Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-admin