From: | Martin Grotzke <martin(dot)grotzke(at)googlemail(dot)com> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Several optimization options (config/hardware) |
Date: | 2012-05-03 13:01:56 |
Message-ID: | 4FA281C4.6040104@googlemail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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
From | Date | Subject | |
---|---|---|---|
Next Message | Jonathan | 2012-05-03 13:05:29 | Re: Query got slow from 9.0 to 9.1 upgrade |
Previous Message | Ants Aasma | 2012-05-03 12:13:31 | Re: Query got slow from 9.0 to 9.1 upgrade |