Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1Ydg3b-0006tS-L7 for pgsql-performance@arkaria.postgresql.org; Thu, 02 Apr 2015 14:25:19 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.80) (envelope-from ) id 1Ydg3a-0007WA-E6 for pgsql-performance@arkaria.postgresql.org; Thu, 02 Apr 2015 14:25:18 +0000 Received: from makus.postgresql.org ([2001:4800:1501:1::229]) by malur.postgresql.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from ) id 1Ydg3Z-0007Uu-F4 for pgsql-performance@postgresql.org; Thu, 02 Apr 2015 14:25:17 +0000 Received: from mail-wg0-x22f.google.com ([2a00:1450:400c:c00::22f]) by makus.postgresql.org with esmtps (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1Ydg3R-0001cc-Ad for pgsql-performance@postgresql.org; Thu, 02 Apr 2015 14:25:15 +0000 Received: by wgdm6 with SMTP id m6so87138195wgd.2 for ; Thu, 02 Apr 2015 07:25:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=LGtX4lLqDisLLQNRQpIFFJQ8EbKVK2aeSuI14R0BLOc=; b=bWCDy9XiIBprEGM04oKpnKCupzBo/vdUcemO0zWwnFrnNhYdX/m/Mxnvm7wIeEhGNU ai7bn5ps6BZ0DFe2qDe5GTQz1SDO0CZkaW7TmnFlU31V1Fqv1NH/MXwL/wYDh7x1ukCt Cs4o49XH5ZSEVrQfKgn4ecwIA14XxDYcmsJZW06unOheyC7SJ6evYDuSqG2Lg4JuWixQ pQWa5c33r7I2ViEHxtQpqtjXCmsIiw/d9fEyn2/jnt9AFd4TcZdLFXkdzVWMKjI64LYY mKO+SkzJjyzks+RbNyjLQIHhiyrkDLAXrQXKfIUm9wT3Axo1/3Yb08qLfU5vxwwEFn7W 9G3Q== X-Received: by 10.180.212.40 with SMTP id nh8mr25363428wic.86.1427984706286; Thu, 02 Apr 2015 07:25:06 -0700 (PDT) Received: from [192.168.2.2] (2-230-140-245.ip202.fastwebnet.it. [2.230.140.245]) by mx.google.com with ESMTPSA id c3sm7969451wiz.2.2015.04.02.07.25.04 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 02 Apr 2015 07:25:05 -0700 (PDT) Content-Type: multipart/alternative; boundary="Apple-Mail=_8367C05E-918C-4494-A852-4B9DE5B6E29F" Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: Can't get Dell PE T420 (Perc H710) perform better than a MacMini with PostgreSQL From: Pietro Pugni In-Reply-To: <1095510641.1517209.1427977377666.JavaMail.zimbra@desy.de> Date: Thu, 2 Apr 2015 16:25:03 +0200 Cc: ik@postgresql-consulting.com, pgsql-performance Message-Id: References: <732B95A3-FEC8-4623-9AC5-98FD30F00863@gmail.com> <9A77A65B-061D-4712-A21D-83B02DF18C57@gmail.com> <1095510641.1517209.1427977377666.JavaMail.zimbra@desy.de> To: "Mkrtchyan, Tigran" X-Mailer: Apple Mail (2.1878.6) X-Pg-Spam-Score: -2.7 (--) 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 --Apple-Mail=_8367C05E-918C-4494-A852-4B9DE5B6E29F Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Hi Tigran, > The modern CPUs trying to be too smart. >=20 > try to run this code to disable CPUs c-states: >=20 > ----> setcpulatency.c=20 >=20 > #include > #include > #include >=20 > int main(int argc, char **argv) { > int32_t l; > int fd; >=20 > if (argc !=3D 2) { > fprintf(stderr, "Usage: %s \n", argv[0]); > return 2; > } >=20 > l =3D atoi(argv[1]); > printf("setting latency to %d us\n", l); > fd =3D open("/dev/cpu_dma_latency", O_WRONLY); > if (fd < 0) { > perror("open /dev/cpu_dma_latency"); > return 1; > } >=20 > if (write(fd, &l, sizeof(l)) !=3D sizeof(l)) { > perror("write to /dev/cpu_dma_latency"); > return 1; > } >=20 > while (1) pause(); > } >=20 >=20 > =97=97> >=20 your C code should be equivalent to the following: echo 0 > /dev/cpu_dma_latency Right? I executed the above command but time execution increase of about 2 = seconds over 129seconds (I=92ve executed the transaction several times = repeating the procedure of restarting db and redoing transaction). With = setting echo 1 > /dev/cpu_dma_latency it returns to 129seconds. > you can use i7z (https://code.google.com/p/i7z/) to see the percentage = of CPU power to be used. I=92ve installed i7z-GUI but it reports the following and crashes with = segmentation fault (T420 has Intel Xeon, not i-series): i7z DEBUG: i7z version: svn-r77-(20-Nov-2011) i7z DEBUG: Found Intel Processor i7z DEBUG: Stepping 4 i7z DEBUG: Model e i7z DEBUG: Family 6 i7z DEBUG: Processor Type 0 i7z DEBUG: Extended Model 3 i7z DEBUG: msr =3D Model Specific Register i7z DEBUG: detected a newer model of ivy bridge processor i7z DEBUG: my coder doesn't know about it, can you send the following = info to him? i7z DEBUG: model e, extended model 3, proc_family 6 i7z DEBUG: msr device files DONOT exist, trying out a makedev script i7z DEBUG: modprobbing for msr [1]+ Segmentation fault (core dumped) i7z_GUI > Changing CPU from C1 to C0 takes quite some time and for DB workload = not optimal (if you need a=20 > high throughout and any given moment). >=20 > I see ~65% boost when run './setcpulatency 0'. >=20 > Tigran. >=20 With =93takes quite some time=94 you mean that it will take some time to = take effect? Thank you a lot for your help. Best regards, Pietro --Apple-Mail=_8367C05E-918C-4494-A852-4B9DE5B6E29F Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252
Hi Tigran,

The modern CPUs trying to be too smart.

try to run = this code to disable CPUs c-states:

----> setcpulatency.c =

#include <stdio.h>
#include <fcntl.h>
#include = <stdint.h>

int main(int argc, char **argv) {
=   int32_t l;
  int fd;

  if = (argc !=3D 2) {
     fprintf(stderr, = "Usage: %s <latency in us>\n", argv[0]);
=      return 2;
  }

=   l =3D atoi(argv[1]);
  printf("setting latency = to %d us\n", l);
  fd =3D open("/dev/cpu_dma_latency", = O_WRONLY);
  if (fd < 0) {
=      perror("open /dev/cpu_dma_latency");
=      return 1;
  }

=   if (write(fd, &l, sizeof(l)) !=3D sizeof(l)) {
=      perror("write to = /dev/cpu_dma_latency");
     return 1;
=   }

  while (1) = pause();
}


=97=97>

your C code = should be equivalent to the following:
echo 0 > = /dev/cpu_dma_latency
Right?
I executed the above = command but time execution increase of about 2 seconds over 129seconds = (I=92ve executed the transaction several times repeating the procedure = of restarting db and redoing transaction). With setting echo 1 > = /dev/cpu_dma_latency it returns to = 129seconds.

you can use = i7z (https://code.google.com/p/i7z/= ) to see the percentage of CPU power to be = used.

I=92ve installed i7z-GUI but = it reports the following and crashes with segmentation fault (T420 has = Intel Xeon, not i-series):
i7z = DEBUG: i7z version: svn-r77-(20-Nov-2011)
i7z DEBUG: Found Intel Processor
i7z DEBUG:    Stepping = 4
i7z DEBUG:    Model = e
i7z DEBUG:    Family = 6
i7z DEBUG:   =  Processor Type 0
i7z = DEBUG:    Extended Model 3
i7z DEBUG: msr =3D Model Specific = Register
i7z DEBUG: detected a = newer model of ivy bridge processor
i7z DEBUG: my coder doesn't know about it, can you send = the following info to him?
i7z = DEBUG: model e, extended model 3, proc_family 6
i7z DEBUG: msr device files DONOT exist, trying = out a makedev script
i7z DEBUG: modprobbing for = msr
[1]+  Segmentation fault      (core = dumped) = i7z_GUI


Changing CPU from C1 to C0 takes quite some time and for = DB workload not optimal (if you need a
high throughout and any given = moment).

I see ~65% boost when run './setcpulatency = 0'.

Tigran.

With =93takes quite some = time=94 you mean that it will take some time to take = effect?

Thank you a lot for your = help.
Best = regards,
 Pietro

= --Apple-Mail=_8367C05E-918C-4494-A852-4B9DE5B6E29F--