Re: Two identical systems, radically different performance - Mailing list pgsql-performance
From | Andrea Suisani |
---|---|
Subject | Re: Two identical systems, radically different performance |
Date | |
Msg-id | 507BC8DE.9050109@opinioni.net Whole thread Raw |
In response to | Re: Two identical systems, radically different performance (Andrea Suisani <sickpig@opinioni.net>) |
Responses |
Re: Two identical systems, radically different performance
(Craig James <cjames@emolecules.com>)
Re: Two identical systems, radically different performance (Claudio Freire <klaussfreire@gmail.com>) xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance] (Andrea Suisani <sickpig@opinioni.net>) |
List | pgsql-performance |
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.
pgsql-performance by date: