Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cxax0-0007JY-2R for pgsql-admin@arkaria.postgresql.org; Mon, 10 Apr 2017 15:09:54 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.84_2) (envelope-from ) id 1cxawz-0006I9-HR for pgsql-admin@arkaria.postgresql.org; Mon, 10 Apr 2017 15:09:53 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA384:256) (Exim 4.84_2) (envelope-from ) id 1cxawy-0006Hz-T8 for pgsql-admin@postgresql.org; Mon, 10 Apr 2017 15:09:53 +0000 Received: from mail-ua0-x22b.google.com ([2607:f8b0:400c:c08::22b]) by makus.postgresql.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.84_2) (envelope-from ) id 1cxaww-00026s-Cm for pgsql-admin@postgresql.org; Mon, 10 Apr 2017 15:09:51 +0000 Received: by mail-ua0-x22b.google.com with SMTP id 49so40608139uau.2 for ; Mon, 10 Apr 2017 08:09:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:subject:date:message-id:mime-version:thread-index :content-language; bh=oKgiky+kN/UVN6GHu7ONOSSbdCZYJIxSSr3Mn6KGruU=; b=FPMZU4KQL2ZhQI+HIGZ/7pyktaDPJ5ytuHiH/qlUpRndjz913Nb50sYnukuxbUt46/ NA/RXP+V0bH+88+eCQu1nt3Ks9q2wy0Kd+jADKbmd4jB6GxyuNztryeqUnf1bVQWjuMk XHgqOvp0WzCfFTGY85LwNkL87uPIvnt+5y+PHYmXFoJ21Cq0H0MNdAwICP7gdD5wX+HW jqkaIBLy1JJH7vFZ0C+9qPzu9TijFNBQO0PQfHsc1WryttQIVOtY5L+wAeGT9y7TuIIv FcIm+XkZeeM5tM8v1AI6bd6X+KdMwAKM8+Dl1Y2+DUkHK5c8V3IBCGaeFDRm6oVA7y8x TYxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :thread-index:content-language; bh=oKgiky+kN/UVN6GHu7ONOSSbdCZYJIxSSr3Mn6KGruU=; b=cThauFkAPD0Exhrajq8ukaYRZnRmqLRv7/1ASVDHIcxKmCBvsMDcPv4iqEBhZWQ27L IIPxpJ0kPnwQ2MCAA/x31gf4g93cjfbOLqU5/cpeRDrjWpbum9i0Kx5EoPpjJC9sgnOO PakGMYsYGFcmIqQ7s5Sw4GY/SxzVKX1qSg7ohSj1WkrzbDE/pJoWIchT8xekNHnQ08Z+ oYuApEYVJ3JX62XA5nt2V5ZXnhC/xoFC+LgMu25QDevRzAmE0ztlMHr5IKkYv69yeSI/ wQWvu9tsBl4+V2zR2p+19DRnarh36WSGcoYnInIqCyZuhsOMEt3HRDGn6KCnbK2TXRmM niNg== X-Gm-Message-State: AN3rC/4XouDBqdIhuUTmCK9wS+TaJVTj6fP3IFexL0WU8oPOrBXM5b7aucEAQoj39OPS1A== X-Received: by 10.159.36.11 with SMTP id 11mr5538851uaq.84.1491836989193; Mon, 10 Apr 2017 08:09:49 -0700 (PDT) Received: from irylachi ([200.55.161.75]) by smtp.gmail.com with ESMTPSA id k9sm3651397vke.14.2017.04.10.08.09.45 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 10 Apr 2017 08:09:48 -0700 (PDT) From: "Lazaro Garcia" To: Subject: Help bad results with pgbench Date: Mon, 10 Apr 2017 11:09:42 -0400 Message-ID: <003101d2b20c$7d2f4fd0$778def70$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0032_01D2B1EA.F61DAFD0" X-Mailer: Microsoft Outlook 15.0 Thread-Index: AdKyDHtEYREliz61RamAkrpB2DR9vQ== Content-Language: es-mx X-Pg-Spam-Score: -1.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 This is a multipart message in MIME format. ------=_NextPart_000_0032_01D2B1EA.F61DAFD0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Good morning everyone. I'm having the following problem with pgbench and test again: I create a database with a scale of 200 and execute a test (read only) with 40 users and this is the result: pgbench -U postgres -p 5433 -j 10 -c 40 -T 30 -h 127.0.0.1 -S pgbench scaling factor: 200 query mode: simple number of clients: 40 number of threads: 10 duration: 30 s number of transactions actually processed: 2682306 latency average = 0.446 ms latency stddev = 0.303 ms tps = 89329.960851 (including connections establishing) tps = 89348.642359 (excluding connections establishing) Then restart the server and when I run the test again the result is really very bad and the IO starts to climb (here the weird thing is that I'm not writing just reading) scaling factor: 200 query mode: simple number of clients: 40 number of threads: 10 duration: 30 s number of transactions actually processed: 6933 latency average = 174.032 ms tps = 229.842173 (including connections establishing) tps = 229.870409 (excluding connections establishing) Can someone give me some suggestions so I can determine what's going on? PostgreSQL 9.6.2. Thank you very much for your time. Regards. ------=_NextPart_000_0032_01D2B1EA.F61DAFD0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable

Good morning = everyone.

 

I'm having the following problem with pgbench and test = again:

 

I create a database with a scale of 200 and execute a test = (read only) with 40 users and this is the = result:

 

pgbench -U postgres -p 5433 -j 10 -c 40 -T 30 -h 127.0.0.1 = -S  pgbench

 

scaling factor: 200

query mode: = simple

number of clients: 40

number of threads: = 10

duration: 30 s

number of transactions actually = processed: 2682306

latency average =3D 0.446 ms

latency stddev =3D 0.303 = ms

tps =3D = 89329.960851 (including connections = establishing)

tps =3D 89348.642359 (excluding connections = establishing)

 

Then restart the server and when I run the test again the = result is really very bad and the IO starts to climb (here the weird = thing is that I'm not writing just reading)

 

scaling factor: = 200

query = mode: simple

number of clients: 40

number of threads: = 10

duration: 30 s

number of transactions actually = processed: 6933

latency average =3D 174.032 ms

tps =3D 229.842173 (including = connections establishing)

tps = =3D 229.870409 (excluding connections establishing)

 

Can someone give me some suggestions so I can determine = what's going on?

 

PostgreSQL 9.6.2.

 

Thank you very much for your = time.

 

Regards.

 

 

 

 

------=_NextPart_000_0032_01D2B1EA.F61DAFD0--