On 12/11/2014 01:11 PM, Evgeniy Shishkin wrote:
On 11 Dec 2014, at 15:02, Andrea Suisani 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 would give it a try
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 "r
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:
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
files
On 05/23/2013 03:47 PM, Merlin Moncure wrote:
[cut]
[..] 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 of a fa
On 05/22/2013 03:30 PM, Merlin Moncure wrote:
On Tue, May 21, 2013 at 7:19 PM, Greg Smith 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 instead of a spinning di
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 of
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 of that
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 patch
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 complet
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.
[cu
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&#
ou have ?
maybe 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: th
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 i
[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 Xeon
On 10/17/2012 06:35 PM, Scott Marlowe wrote:
On Wed, Oct 17, 2012 at 9:45 AM, Andrea Suisani 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 0 -c 4) show
On 10/15/2012 05:34 PM, Scott Marlowe wrote:
On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
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
previous
On 10/15/2012 05:34 PM, Scott Marlowe wrote:
On Mon, Oct 15, 2012 at 9:28 AM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani wrote:
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
previous
On 10/15/2012 05:28 PM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 12:24 PM, Andrea Suisani 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
previously
[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 r3
On 10/15/2012 05:01 PM, Claudio Freire wrote:
On Mon, Oct 15, 2012 at 5:27 AM, Andrea Suisani 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 right.
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 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 w
On 10/11/2012 04:19 PM, Claudio Freire wrote:
On Thu, Oct 11, 2012 at 11:14 AM, Andrea Suisani 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 enterin
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 a
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 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
[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 pos
On 09/14/2012 10:45 AM, Daniel Farina wrote:
On Fri, Sep 14, 2012 at 12:40 AM, Nikolay Ulyanitsky 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 - http://pastebin
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
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 fail
On 02/11/2011 12:26 PM, Tobias Brox wrote:
2011/2/11 Vitalii Tymchyshyn:
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 concurrently.
Concurrent
30 matches
Mail list logo
