Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwtFp-0007j1-Ix for pgsql-performance@arkaria.postgresql.org; Thu, 21 Feb 2019 18:39:29 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.89) (envelope-from ) id 1gwtFo-0004CK-6c for pgsql-performance@arkaria.postgresql.org; Thu, 21 Feb 2019 18:39:28 +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_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwr9y-00055U-Sh for pgsql-performance@lists.postgresql.org; Thu, 21 Feb 2019 16:25:19 +0000 Received: from gproxy8-pub.mail.unifiedlayer.com ([67.222.33.93]) by magus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.89) (envelope-from ) id 1gwr9u-00037p-6d for pgsql-performance@lists.postgresql.org; Thu, 21 Feb 2019 16:25:17 +0000 Received: from cmgw11.unifiedlayer.com (unknown [10.9.0.11]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id 025F41AC27A for ; Thu, 21 Feb 2019 08:59:44 -0700 (MST) Received: from host214.hostmonster.com ([74.220.215.214]) by cmsmtp with ESMTP id wqlDgWszID8RpwqlDgvHlw; Thu, 21 Feb 2019 08:59:43 -0700 X-Authority-Reason: nr=8 X-Authority-Analysis: $(_cmae_reason DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=pragmaticdata.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:To:Subject:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=6EJMzBh0P7qNX9/+U7gkmB4wyM4TdvnPgUh0ot3YgZw=; b=hbhL78RETAd1INWnpQcEFT5MP MZ2k3iMbNPI5hJM2MONQ4wfbbYVPBE78Cd6dm9WVbwMYSFU/azL121UhEAM1Sc1vJmpY2E/mNb9wj syMuJ7zCRQ9Zv7y2VgrkQ/j7it; Received: from [191.7.153.218] (port=59315 helo=[192.168.9.5]) by host214.hostmonster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gwqlD-003l8h-Gk for pgsql-performance@lists.postgresql.org; Thu, 21 Feb 2019 08:59:43 -0700 Subject: Re: neither CPU nor IO bound, but throttled performance To: pgsql-performance@lists.postgresql.org References: <1b6d8b15-75eb-f00e-2d16-27f79d81eae7@gusw.net> From: Gunther Schadow Message-ID: Date: Thu, 21 Feb 2019 10:59:44 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1F170E208CA19CF73F317C32" Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - host214.hostmonster.com X-AntiAbuse: Original Domain - lists.postgresql.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - pragmaticdata.com X-BWhitelist: no X-Source-IP: 191.7.153.218 X-Source-L: No X-Exim-ID: 1gwqlD-003l8h-Gk X-Source: X-Source-Args: X-Source-Dir: X-Source-Sender: ([192.168.9.5]) [191.7.153.218]:59315 X-Source-Auth: gunther+pragmaticdata.com X-Email-Count: 5 X-Source-Cap: cHJhZ21hdDE7cHJhZ21hdDE7aG9zdDIxNC5ob3N0bW9uc3Rlci5jb20= X-Local-Domain: yes List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Precedence: bulk This is a multi-part message in MIME format. --------------1F170E208CA19CF73F317C32 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Thank you Magnus. 68% steal. Indeed. You probably hit the target. Yes. That explains the discrepancy. I need to watch and understand that CPU credits issue. regards, -Gunther On 2/21/2019 4:08, Magnus Hagander wrote: > On Thu, Feb 21, 2019 at 12:34 AM Gunther > wrote: > > Hi, I have an Amazon Linux based Postgresql 11 server here on a > t2.medium EC2 instance. > > It is serving 24 worker processes that read jobs from a queue > (thanks to SELECT ... FOR UPDATE SKIP LOCKED!) and do jobs some of > which are reading and writing business data to the database, > others are only reading, and some don't hit the business data at > all, only the queue. > > Everything flows quite nicely. Except, I don't understand why I > can't max out the CPU or the IO, instead, IO is almost negligible > yet the CPU is at 30% hardly hitting 50%. > > Here I give you a view of top: > > top - 23:17:09 up 45 days, 2:07, 4 users, load average: 20.32, > 18.92, 13.80 Tasks: 338 total, 24 running, 111 sleeping, 0 > stopped, 0 zombie %Cpu(s): 28.7 us, 2.5 sy, 0.0 ni, 0.0 id, 0.0 > wa, 0.0 hi, 0.0 si, 68.7 st > > > If I read that right, it's about 70% "steal". The description for this > is "the percentage of time spent in involuntary wait by the virtual > CPU or CPUs while the hypervisor was servicing another virtual > processor.". > > So basically, the CPU is spent dealing with other peoples VMs on the > same hardware. Welcome to the multi-tenant cloud. > > In particular, I believe T series instances get a limited number of > CPU "credits" per hours. My guess is you've hit this limit and are > thus being throttled. T series are not intended for persistent > workloads. Either way, this is probably a question better asked at the > Amazon EC2 forums rather than PostgreSQL as you'll find more people > who know the EC2 interactions there. > -- >  Magnus Hagander >  Me: https://www.hagander.net/ >  Work: https://www.redpill-linpro.com/ --------------1F170E208CA19CF73F317C32 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Thank you Magnus. 68% steal. Indeed. You probably hit the target. Yes.

That explains the discrepancy. I need to watch and understand that CPU credits issue.

regards,
-Gunther

On 2/21/2019 4:08, Magnus Hagander wrote:
On Thu, Feb 21, 2019 at 12:34 AM Gunther <raj@gusw.net> wrote:

Hi, I have an Amazon Linux based Postgresql 11 server here on a t2.medium EC2 instance.

It is serving 24 worker processes that read jobs from a queue (thanks to SELECT ... FOR UPDATE SKIP LOCKED!) and do jobs some of which are reading and writing business data to the database, others are only reading, and some don't hit the business data at all, only the queue.

Everything flows quite nicely. Except, I don't understand why I can't max out the CPU or the IO, instead, IO is almost negligible yet the CPU is at 30% hardly hitting 50%.

Here I give you a view of top:

top - 23:17:09 up 45 days,  2:07,  4 users,  load average: 20.32, 18.92, 13.80
Tasks: 338 total,  24 running, 111 sleeping,   0 stopped,   0 zombie
%Cpu(s): 28.7 us,  2.5 sy,  0.0 ni,  0.0 id,  0.0 wa,  0.0 hi,  0.0 si, 68.7 st

If I read that right, it's about 70% "steal". The description for this is "the percentage of time spent in involuntary wait by the virtual CPU or CPUs while the hypervisor was servicing another virtual processor.".

So basically, the CPU is spent dealing with other peoples VMs on the same hardware. Welcome to the multi-tenant cloud. 

In particular, I believe T series instances get a limited number of CPU "credits" per hours. My guess is you've hit this limit and are thus being throttled. T series are not intended for persistent workloads. Either way, this is probably a question better asked at the Amazon EC2 forums rather than PostgreSQL as you'll find more people who know the EC2 interactions there.
 
--
--------------1F170E208CA19CF73F317C32--