Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Yyhcz-0001FD-7X for pgsql-performance@arkaria.postgresql.org; Sat, 30 May 2015 14:20:45 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Yyhcy-0006zS-Kd for pgsql-performance@arkaria.postgresql.org; Sat, 30 May 2015 14:20:44 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Yyhcx-0006zM-Qq for pgsql-performance@postgresql.org; Sat, 30 May 2015 14:20:43 +0000 Received: from mail-wg0-f41.google.com ([74.125.82.41]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84) (envelope-from ) id 1Yyhct-0007Pa-SL for pgsql-performance@postgresql.org; Sat, 30 May 2015 14:20:43 +0000 Received: by wgv5 with SMTP id 5so82770490wgv.1 for ; Sat, 30 May 2015 07:20:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=GGhF5xVyhP4aSV4apcLtECMysIYk3bpKNKewvZiRxRE=; b=YLBfvqx6hIlWOceBipA1yBRCY4JtjOBCgRQSs9jS4jS+dLZV8ujNlQy51LnskPkNdN 641lmQN4q2RFHEv+TWSHEmUG3yP32e9ThhlxM1I0rtrsYLt3Irzx0APWH6kLpFaoQnHm g1halzGcIJldUi7hmCVW4ZQmhdJGbZM7hC+wK+H5TzpHtXnbB8Ove/ifvZzaeufReI5Y E+9UabP1JvRRZtBCqfguJceBl+vbqQa9QR82VcXCKRkspciF9PnHCjPVN710ZIdJCYxr /fX5Uid8bbd7Qrq9XQW3vMPGTO7s4XxuUmSKg+uFlxyccVQvkddVw/cwcJWW6nu5OCbZ iRIQ== X-Gm-Message-State: ALoCoQnAP3AJB1aeZ9UnaPamkPA8rLKXoiqpUWTZpicqwiYJmSTwX8KPqeBZp2eaUr/YfKSuIBioIpmQa74bBJhq5HFRqCiScqySd8Lf83i4PU5PIlfOwXgl2w+DtwDhJcw6WHbJMvZM5oWWRff9CdMRUk+K/du/91IM9ACKgdfY+nEvU10eWjPTP9XXNJeYAuwE9JTVEU8xbBx9kL20ktUMW500nK1WUw== X-Received: by 10.180.77.195 with SMTP id u3mr5186281wiw.30.1432995638073; Sat, 30 May 2015 07:20:38 -0700 (PDT) Received: from [10.137.2.12] (ip-78-45-136-74.net.upcbroadband.cz. [78.45.136.74]) by mx.google.com with ESMTPSA id um5sm13006027wjc.1.2015.05.30.07.20.35 for (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 30 May 2015 07:20:37 -0700 (PDT) Message-ID: <5569C730.3010701@2ndquadrant.com> Date: Sat, 30 May 2015 16:20:32 +0200 From: Tomas Vondra User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: Postgres is using 100% CPU References: <5568BBFF.8080807@2ndquadrant.com> In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Pg-Spam-Score: -2.6 (--) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org Hi, On 05/30/15 15:46, Ashik S L wrote: > We are using postgres SQL version 8.4.17.. FYI 8.4 is already unsupported for ~1 year, so you should consider upgrading to a newer release. Also, the newest version in that branch is 8.4.22, so with 8.4.17 you're missing ~1 year of patches. > Postgres DB szie is 900 MB and we are inserting 273 rows at once .and > each row is of 60 bytes.Every time we insert 16380 bytes of data. So you insert 273 rows and it gets stuck for 40 minutes? That's really strange, and I find it rather unlikely even with a badly misconfigured instance. It should easily insert thousands of rows per second. Can you elaborate more about the database structure, or at least the table(s) you're inserting into. Are there any foreign keys (in either direction), indexes or triggers? > I tried to make some config changes using above link. But I did not > see any improvement. > I made following changes in postgres.conf file: > shared_buffers = 512MB // It was 32MB > work_mem = 30MB > effective_cache_size = 512MB // I tried with 128MB 256MB also > > Please let me know any config changes that I can try out. I don't think this has anything to do with configuration. This seems like an issue at the application level, or maybe poorly designed schema. You mentioned you have multiple machines, and only some of them are having this issue. What are the differences between the machines? Are all the machines using the same schema? I assume each has a different amount of data. -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance