Re: [PERFORM] Tuning the configuration

2014-12-11 Thread Andrea Suisani
On 12/10/2014 11:44 AM, Maila Fatticcioni wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hello. I need to tune a postgres installation I've just made to get a better performance. I use two identical servers with a hot replication configuration. The two servers have the following hardware:

Re: [PERFORM] Tuning the configuration

2014-12-11 Thread Andrea Suisani
Would you mind to explain me better why you do suggest me to use the sas raid for wal please? SSDs are known to shine when they have to deal with random access pattern rather than sequential, on the other hand 10/15K rpm SAS disk is known to be better for sequential io workloads (in general

Re: [PERFORM] Tuning the configuration

2014-12-11 Thread Andrea Suisani
On 12/11/2014 01:11 PM, Evgeniy Shishkin wrote: On 11 Dec 2014, at 15:02, Andrea Suisani sick...@opinioni.net wrote: On 12/10/2014 11:44 AM, Maila Fatticcioni wrote: 2- I would like to use the two SDD to store the wal file. Do you think it is useful or how should I use them? I definitely

[PERFORM] [OT] A flash filesystem tuning guide

2013-07-03 Thread Andrea Suisani
Hi all just wanna share a link I've stumbled across today. https://lwn.net/Articles/557220/ quoting the relevant part of the announcement: This is the culmination of several months of effort, to determine the results of using different tuning options in the Linux kernel, with different

Re: [PERFORM] Reliability with RAID 10 SSD and Streaming Replication

2013-05-23 Thread Andrea Suisani
On 05/22/2013 03:30 PM, Merlin Moncure wrote: On Tue, May 21, 2013 at 7:19 PM, Greg Smith g...@2ndquadrant.com wrote: On 5/20/13 6:32 PM, Merlin Moncure wrote: [cut] The only really huge gain to be had using SSD is commit rate at a low client count. There you can easily do 5,000/second

Re: [PERFORM] Reliability with RAID 10 SSD and Streaming Replication

2013-05-23 Thread Andrea Suisani
On 05/23/2013 03:47 PM, Merlin Moncure wrote: [cut] quote [..] There are two components to the Swingbench test we're running here: the database itself, and the redo log. The redo log stores all changes that are made to the database, which allows the database to be reconstructed in the event

Re: [PERFORM] [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability

2013-05-16 Thread Andrea Suisani
Hi all, On 03/26/2013 07:59 PM, Shaun Thomas wrote: On 03/26/2013 08:04 AM, Andrea Suisani wrote: TPS: 100 users: 1257.21 (vanilla)2805.06 (v3 patchset) 400 users: 1437.57 (vanilla)2664.67 (v3 patchset) 800 users: 1236.89 (vanilla)2750.73 (v3 patchset) Wow, I like the look

Re: [PERFORM] [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability

2013-03-29 Thread Andrea Suisani
Hi On 03/26/2013 07:59 PM, Shaun Thomas wrote: On 03/26/2013 08:04 AM, Andrea Suisani wrote: TPS: 100 users: 1257.21 (vanilla)2805.06 (v3 patchset) 400 users: 1437.57 (vanilla)2664.67 (v3 patchset) 800 users: 1236.89 (vanilla)2750.73 (v3 patchset) Wow, I like the look

[PERFORM] [OT] linux 3.10 kernel will improve ipc,sysv semaphore scalability

2013-03-26 Thread Andrea Suisani
Hi all, Just to let the community know that probably Linux kernel 3.10 will include some work to make sysv semaphore code more scalable. Since Postgres use this kernel features I've thought to post it here just for the sake of sharing a good news: The thread where Rik van Riel posts the v3

Re: [PERFORM] Two Necessary Kernel Tweaks for Linux Systems

2013-01-08 Thread Andrea Suisani
On 01/02/2013 10:46 PM, Shaun Thomas wrote: Hey everyone! After much testing and hair-pulling, we've confirmed two kernel settings that should always be modified in production Linux systems. Especially new ones with the completely fair scheduler (CFS) as opposed to the O(1) scheduler.

Re: [PERFORM] Two Necessary Kernel Tweaks for Linux Systems

2013-01-08 Thread Andrea Suisani
On 01/08/2013 09:29 AM, Andrea Suisani wrote: On 01/02/2013 10:46 PM, Shaun Thomas wrote: Hey everyone! After much testing and hair-pulling, we've confirmed two kernel settings that should always be modified in production Linux systems. Especially new ones with the completely fair

[PERFORM] Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]

2012-12-06 Thread Andrea Suisani
Hi John, On 12/06/2012 09:29 AM, John Lister wrote: on this box: 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

[PERFORM] Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]

2012-12-06 Thread Andrea Suisani
they are of the same typeShaun Thomas is having problem with here: http://archives.postgresql.org/pgsql-performance/2012-12/msg00030.php Andrea john On 06/12/2012 08:44, Andrea Suisani wrote: Hi John, On 12/06/2012 09:29 AM, John Lister wrote: on this box: in a brief: the box is dell

Re: [PERFORM] Re: xfs perform a lot better than ext4 [WAS: Re: Two identical systems, radically different performance]

2012-12-06 Thread Andrea Suisani
On 12/06/2012 12:37 PM, John Lister wrote: On 06/12/2012 09:33, Andrea Suisani wrote: which kind of ssd disks do you have ? maybe they are of the same typeShaun Thomas is having problem with here: http://archives.postgresql.org/pgsql-performance/2012-12/msg00030.php Yeah i saw that post, I'm

xfs perform a lot better than ext4 [WAS: Re: [PERFORM] Two identical systems, radically different performance]

2012-12-05 Thread Andrea Suisani
[sorry for resuming an old thread] [cut] 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. on this box: in a brief: the box is dell a PowerEdge r720 with 16GB of RAM, the cpu is a

Re: [PERFORM] Two identical systems, radically different performance

2012-10-18 Thread Andrea Suisani
On 10/17/2012 06:35 PM, Scott Marlowe wrote: On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani sick...@opinioni.net wrote: On 10/15/2012 05:34 PM, Scott Marlowe wrote: I'd recommend more synthetic benchmarks when trying to compare systems like this. bonnie++, you were right. bonnie++ (-f -n

Re: [PERFORM] Two identical systems, radically different performance

2012-10-17 Thread Andrea Suisani
On 10/15/2012 05:34 PM, Scott Marlowe wrote: On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire klaussfre...@gmail.com wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani sick...@opinioni.net wrote: sure you're right. It's just that my bet was on a higher throughput when HT was isabled from

Re: [PERFORM] Two identical systems, radically different performance

2012-10-15 Thread Andrea Suisani
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 sick...@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

Re: [PERFORM] Two identical systems, radically different performance

2012-10-15 Thread Andrea Suisani
On 10/15/2012 05:01 PM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani sick...@opinioni.net wrote: it seems strange that disabling HT from the bios will give lesser TPS that HT disable through sysfs interface. It does prove they're not equivalent though. sure you're

Re: [PERFORM] Two identical systems, radically different performance

2012-10-15 Thread Andrea Suisani
[cut] 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: HTHT SYSFS DISHT BIOS DISABLE -c -t r1 r2 r3r1 r2

Re: [PERFORM] Two identical systems, radically different performance

2012-10-15 Thread Andrea Suisani
On 10/15/2012 05:28 PM, Claudio Freire wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani sick...@opinioni.net wrote: It does prove they're not equivalent though. sure you're right. It's just that my bet was on a higher throughput when HT was isabled from the BIOS (as you stated

Re: [PERFORM] Two identical systems, radically different performance

2012-10-15 Thread Andrea Suisani
On 10/15/2012 05:34 PM, Scott Marlowe wrote: On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire klaussfre...@gmail.com wrote: On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani sick...@opinioni.net wrote: sure you're right. It's just that my bet was on a higher throughput when HT was isabled from

Re: [PERFORM] Two identical systems, radically different performance

2012-10-11 Thread Andrea Suisani
On 10/09/2012 01:40 AM, Craig James wrote: Nobody has commented on the hyperthreading question yet ... does it really matter? The old (fast) server has hyperthreading disabled, and the new (slower) server has hyperthreads enabled. If hyperthreading is definitely NOT an issue, it will save me

Re: [PERFORM] Two identical systems, radically different performance

2012-10-11 Thread Andrea Suisani
On 10/11/2012 04:19 PM, Claudio Freire wrote: On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani sick...@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

Re: [PERFORM] 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets

2012-10-03 Thread Andrea Suisani
Hi On 09/18/2012 09:44 AM, Andrea Suisani wrote: On 09/14/2012 10:45 AM, Daniel Farina wrote: On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky lys...@gmail.com wrote: Hi I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got the 15-20% performance drop of PostgreSQL 9.2

Re: [PERFORM] 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets

2012-09-18 Thread Andrea Suisani
On 09/14/2012 10:45 AM, Daniel Farina wrote: On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky lys...@gmail.com wrote: Hi I compiled the 3.6-rc5 kernel with the same config from 3.5.3 and got the 15-20% performance drop of PostgreSQL 9.2 on AMD chipsets (880G, 990X). [cut] Kernel config

Re: [PERFORM] 20% performance drop on PostgreSQL 9.2 from kernel 3.5.3 to 3.6-rc5 on AMD chipsets

2012-09-18 Thread Andrea Suisani
[cut] Kernel config - http://pastebin.com/cFpg5JSJ Any ideas? Did you tell LKML? It seems like a kind of change that could be found using git bisect of Linux, albiet laboriously. just a pointer to LKML thread: https://lkml.org/lkml/2012/9/14/99 There's some interesting discussion of

Re: [PERFORM] SSD and RAID

2012-03-07 Thread Andrea Suisani
On 03/06/2012 09:17 AM, Yeb Havinga wrote: On 2012-03-05 23:37, Mark Kirkwood wrote: Which brings up the question of should it be a pair in RAID 1 or just a singe drive? Traditionally this would have been a no brainer Of course you want RAID 1 or RAID 10! However our experience with SSD

Re: [PERFORM] SSD and RAID

2012-03-07 Thread Andrea Suisani
On 03/06/2012 10:34 AM, Yeb Havinga wrote: On 2012-03-06 09:34, Andrea Suisani wrote: On 03/06/2012 09:17 AM, Yeb Havinga wrote: PS: we applied the same philosophy (different brands) also to motherboards, io controllers and memory, but after testing, we liked one IO controllers software so

Re: [PERFORM] Why we don't want hints Was: Slow count(*) again...

2011-02-11 Thread Andrea Suisani
On 02/11/2011 12:26 PM, Tobias Brox wrote: 2011/2/11 Vitalii Tymchyshyntiv...@gmail.com: My idea as well, though it looks ugly and it would be a maintenance head-ache (upgrading the index as new transaction types are added would mean costly write locks on the table, Create new one