From: Andrea Suisani <sickpig@opinioni.net>
To: Claudio Freire <klaussfreire@gmail.com>
Cc: Craig James <cjames@emolecules.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Two identical systems, radically different performance
Date: Mon, 15 Oct 2012 10:27:10 +0200
Message-ID: <507BC8DE.9050109@opinioni.net> (raw)
In-Reply-To: <5076DA4E.80504@opinioni.net>
References: <CAFwQ8rcvw4mSoJ9q+ouONCeB9dg1T9gAUV5J27MpVZrehRHayQ@mail.gmail.com>
<CAFwQ8rfm2AcuoFHDfBLA_hg7ffbsYNsrsaJPDqcOeGqaVW02OQ@mail.gmail.com>
<CAFwQ8rcyCKcoeEn62_QHMRSmJM03ULERtW6_R=3TaO0twOEV9A@mail.gmail.com>
<5076D433.7090605@opinioni.net>
<CAGTBQpYGyq70q_S_dUngSwB7yLbbCxetnfXpaMC9LEr7zL6iWA@mail.gmail.com>
<5076DA4E.80504@opinioni.net>
On 10/11/2012 04:40 PM, Andrea Suisani wrote:
> On 10/11/2012 04:19 PM, Claudio Freire wrote:
>> On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani <sickpig@opinioni.net> wrote:
>>> sorry to come late to the party, but being in a similar condition
>>> I've googled a bit and I've found a way to disable hyperthreading without
>>> the need to reboot the system and entering the bios:
>>>
>>> echo 0 >/sys/devices/system/node/node0/cpuX/online
>>>
>>> where X belongs to 1..(#cores * 2) if hyperthreading is enabled
>>> (cpu0 can't be switched off).
>>>
>>> didn't try myself on live system, but I definitely will
>>> as soon as I have a new machine to test.
>>
>> Question is... will that remove the performance penalty of HyperThreading?
>
> So I've added to my todo list to perform a test to verify this claim :)
done.
in a brief: the box is dell a PowerEdge r720 with 16GB of RAM,
the cpu is a Xeon 5620 with 6 core, the OS is installed on a raid
(sata disk 7.2k rpm) and the PGDATA is on separate RAID 1 array
(sas 15K rpm) and the controller is a PERC H710 (bbwc with a cache
of 512 MB).
Postgres ver 9.2.1 (sorry for not having benchmarked 9.1,
but this what we plan to deploy in production). Both the OS
(Ubuntu 12.04.1) and Postgres had been briefly tuned according
to the usal standards while trying to mimic Craig's configuration
(see specific settings at the bottom).
TPS including connection establishing, pgbench run in a single
thread mode, connection made through unix socket, OS cache dropped
and Postgres restarted for every run.
those are the results:
HT HT SYSFS DIS HT BIOS DISABLE
-c -t r1 r2 r3 r1 r2 r3 r1 r2 r3
5 20K 1641 1831 1496 2020 1974 2033 2005 1988 1967
10 10K 2161 2134 2136 2277 2252 2216 1854 1824 1810
20 5k 2550 2508 2558 2417 2388 2357 1924 1928 1954
30 3333 2216 2272 2250 2333 2493 2496 1993 2009 2008
40 2.5K 2179 2221 2250 2568 2535 2500 2025 2048 2018
50 2K 2217 2213 2213 2487 2449 2604 2112 2016 2023
Despite the fact the results don't match my expectation
(I suspect that there's something wrong with the PERC
because, having the controller cache enabled make no
difference in terms of TPS), it seems strange that disabling
HT from the bios will give lesser TPS that HT disable through
sysfs interface.
OS conf:
vm.swappiness=0
vm.overcommit_memory=2
vm.dirty_ratio=2
vm.dirty_background_ratio=1
kernel.shmmax=3454820352
kernel.shmall=2048341
/sbin/blockdev --setra 8192 /dev/sdb
$PGDATA is on ext4 (rw,noatime)
Linux cloud 3.2.0-32-generic #51-Ubuntu SMP Wed Sep 26 21:33:09 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
sdb scheduler is [cfq]
DB conf:
max_connections = 100
shared_buffers = 3200MB
work_mem = 30MB
maintenance_work_mem = 800MB
synchronous_commit = off
full_page_writes = off
checkpoint_segments = 40
checkpoint_timeout = 5min
checkpoint_completion_target = 0.9
random_page_cost = 3.5
effective_cache_size = 10GB
log_autovacuum_min_duration = 0
autovacuum_naptime = 5min
Andrea
p.s. as last try in the process of increasing TPS
I've change the scheduler from cfq to deadline
and for -c 5 t 20K I've got r1=3007, r2=2930 and r3=2985.
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: sickpig@opinioni.net, klaussfreire@gmail.com, cjames@emolecules.com
Subject: Re: Two identical systems, radically different performance
In-Reply-To: <507BC8DE.9050109@opinioni.net>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox