On Mon, Oct 15, 2012 at 1:27 AM, Andrea Suisani <sickpig@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> >>> 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. > > > -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
