Re: Several optimization options (config/hardware) - Mailing list pgsql-performance

From Martin Grotzke
Subject Re: Several optimization options (config/hardware)
Date
Msg-id 4FA281C4.6040104@googlemail.com
Whole thread Raw
In response to Re: Several optimization options (config/hardware)  ("Albe Laurenz" <laurenz.albe@wien.gv.at>)
Responses Re: Several optimization options (config/hardware)
List pgsql-performance
Hi Laurenz,

On 05/03/2012 09:26 AM, Albe Laurenz wrote:
> Martin Grotzke wrote:
>> we want to see if we can gain better performance with our postgresql
>> database. In the last year the amount of data growed from ~25G to now
>> ~140G and we're currently developing a new feature that needs to get
>> data faster from the database. The system is both read and write
> heavy.
>>
>> At first I want to give you an overview over the hardware, software
> and
>> configuration and the changes that I see we could check out. I'd be
> very
>> happy if you could review and tell if the one or the other is
> nonsense.
>>
>> Hardware:
>> - CPU: 4x4 Cores Intel Xeon L5630  @ 2.13GHz
>> - RAM: 64GB
>> - RAID 1 (1+0) HP Company Smart Array G6 controllers, P410i
>>   (I don't know the actual number of discs)
>> - A single partition for data and wal-files
>>
>> Software
>> - RHEL 6, Kernel 2.6.32-220.4.1.el6.x86_64
>> - postgresql90-server-9.0.6-1PGDG.rhel6.x86_64
>
> You could try different kernel I/O elevators and see if that improves
> something.
>
> I have made good experiences with elevator=deadline and elevator=noop.
Ok, great info.

I'm not sure at which device to look honestly to check the current
configuration.

mount/fstab shows the device /dev/mapper/VG01-www for the relevant
partition. When I check iostat high utilization is reported for the
devices dm-4 and sda (showing nearly the same numbers for util always),
so I suspect that dm-4 is mapped on sda.

This is the current config:
$ cat /sys/block/sda/queue/scheduler
noop anticipatory deadline [cfq]
$ cat /sys/block/dm-4/queue/scheduler
none

Which of them should be changed?
I'll discuss this also with our hosting provider next week, he'll know
what has to be done.

Cheers,
Martin


Attachment

pgsql-performance by date:

Previous
From: Ants Aasma
Date:
Subject: Re: Query got slow from 9.0 to 9.1 upgrade
Next
From: Jonathan
Date:
Subject: Re: Query got slow from 9.0 to 9.1 upgrade