Re: Two identical systems, radically different performance

On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani <sickpig(at)opinioni(dot)net> wrote:
> 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(at)opinioni(dot)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

You have a RAID1 with 15K SAS disks. I have a RAID10 with 8 7200 SATA
disks plus another RAID1 for the XLOG file system. Ten 7K SATA disks
on two file systems should be quite a bit faster than two 15K SAS
disks, right?

> (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.

Well, all I can say is that I like my 3WARE controllers, and it's the
secondary reason why I moved away from Dell (the primary reason is
price).

Craig

>
> 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.
>
>
>