SEO

Hi,
after doing the "dd" tests for a server we have at work I obtained:
Read: 47.20 Mb/s
Write: 39.82 Mb/s
Some days ago read performance was around 20Mb/s due to no readahead in md0
so I modified it using hdparm. However, it seems to me that being it a RAID1
read speed could be much better. These are SATA disks with 3Gb of RAM so I
did 'time bash -c "dd if=/dev/zero of=bigfile bs=8k count=786432 && sync"'.
File system is ext3 (if read many times in the list that XFS is faster), but
I don't want to change the file system right now. Modifing the readahead from
the current 1024k to 2048k doesn't make any difference. Are there any other
tweaks I can make?


---------------------------(end of broadcast)---------------------------
TIP 4: Have you searched our list archives?

http://archives.postgresql.org

This sounds like a bad RAID controller - are you using a built-in hardware
RAID? If so, you will likely want to use Linux software RAID instead.

Also - you might want to try a 512KB readahead - I've found that is optimal
for RAID1 on some RAID controllers.

- Luke


On 5/30/07 2:35 AM, "Albert Cervera Areny" <albert@sedifa.com> wrote:

> Hi,
> after doing the "dd" tests for a server we have at work I obtained:
> Read: 47.20 Mb/s
> Write: 39.82 Mb/s
> Some days ago read performance was around 20Mb/s due to no readahead in md0
> so I modified it using hdparm. However, it seems to me that being it a RAID1
> read speed could be much better. These are SATA disks with 3Gb of RAM so I
> did 'time bash -c "dd if=/dev/zero of=bigfile bs=8k count=786432 && sync"'.
> File system is ext3 (if read many times in the list that XFS is faster), but
> I don't want to change the file system right now. Modifing the readahead from
> the current 1024k to 2048k doesn't make any difference. Are there any other
> tweaks I can make?
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 4: Have you searched our list archives?
>
> http://archives.postgresql.org
>



---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend

Hardware isn't very good I believe, and it's about 2-3 years old, but the RAID
is Linux software, and though not very good the difference between reading
and writing should probably be greater... (?)

Would you set 512Kb readahead on both drives and RAID? I tried various
configurations and none seemed to make a big difference. It seemed correct to
me to set 512kb per drive and 1024kb for md0.

A Dimecres 30 Maig 2007 16:09, Luke Lonergan va escriure:
> This sounds like a bad RAID controller - are you using a built-in hardware
> RAID? If so, you will likely want to use Linux software RAID instead.
>
> Also - you might want to try a 512KB readahead - I've found that is optimal
> for RAID1 on some RAID controllers.
>
> - Luke
>
> On 5/30/07 2:35 AM, "Albert Cervera Areny" <albert@sedifa.com> wrote:
> > Hi,
> > after doing the "dd" tests for a server we have at work I obtained:
> > Read: 47.20 Mb/s
> > Write: 39.82 Mb/s
> > Some days ago read performance was around 20Mb/s due to no readahead in
> > md0 so I modified it using hdparm. However, it seems to me that being it
> > a RAID1 read speed could be much better. These are SATA disks with 3Gb of
> > RAM so I did 'time bash -c "dd if=/dev/zero of=bigfile bs=8k count=786432
> > && sync"'. File system is ext3 (if read many times in the list that XFS
> > is faster), but I don't want to change the file system right now.
> > Modifing the readahead from the current 1024k to 2048k doesn't make any
> > difference. Are there any other tweaks I can make?
> >
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 4: Have you searched our list archives?
> >
> > http://archives.postgresql.org
>
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

--
Albert Cervera Areny
Dept. Informàtica Sedifa, S.L.

Av. Can Bordoll, 149
08202 - Sabadell (Barcelona)
Tel. 93 715 51 11
Fax. 93 715 51 12

================================================== ==================
......................... AVISO LEGAL ............................
La presente comunicación y sus anexos tiene como destinatario la
persona a la que va dirigida, por lo que si usted lo recibe
por error debe notificarlo al remitente y eliminarlo de su
sistema, no pudiendo utilizarlo, total o parcialmente, para
ningún fin. Su contenido puede tener información confidencial o
protegida legalmente y únicamente expresa la opinión del
remitente. El uso del correo electrónico vía Internet no
permite asegurar ni la confidencialidad de los mensajes
ni su correcta recepción. En el caso de que el
destinatario no consintiera la utilización del correo electrónico,
deberá ponerlo en nuestro conocimiento inmediatamente.
================================================== ==================
............................ DISCLAIMER .............................
This message and its attachments are intended exclusively for the
named addressee. If you receive this message in error, please
immediately delete it from your system and notify the sender. You
may not use this message or any part of it for any purpose.
The message may contain information that is confidential or
protected by law, and any opinions expressed are those of the
individual sender. Internet e-mail guarantees neither the
confidentiality nor the proper receipt of the message sent.
If the addressee of this message does not consent to the use
of internet e-mail, please inform us inmmediately.
================================================== ==================




---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

As there is no 'continuous space' option on ext3/ext2 (or probably "-f
fragment_size" may do a trick?) - I think after some filesystem
activity you simply loose continuous space allocation and rather
expected sequential reading may be transformed into random seeking of
'logically' sequentual blocks...

Rgds,
-Dimitri

On 5/30/07, Albert Cervera Areny <albert@sedifa.com> wrote:
> Hardware isn't very good I believe, and it's about 2-3 years old, but the
> RAID
> is Linux software, and though not very good the difference between reading
> and writing should probably be greater... (?)
>
> Would you set 512Kb readahead on both drives and RAID? I tried various
> configurations and none seemed to make a big difference. It seemed correct
> to
> me to set 512kb per drive and 1024kb for md0.
>
> A Dimecres 30 Maig 2007 16:09, Luke Lonergan va escriure:
> > This sounds like a bad RAID controller - are you using a built-in hardware
> > RAID? If so, you will likely want to use Linux software RAID instead.
> >
> > Also - you might want to try a 512KB readahead - I've found that is
> optimal
> > for RAID1 on some RAID controllers.
> >
> > - Luke
> >
> > On 5/30/07 2:35 AM, "Albert Cervera Areny" <albert@sedifa.com> wrote:
> > > Hi,
> > > after doing the "dd" tests for a server we have at work I obtained:
> > > Read: 47.20 Mb/s
> > > Write: 39.82 Mb/s
> > > Some days ago read performance was around 20Mb/s due to no readahead in
> > > md0 so I modified it using hdparm. However, it seems to me that being it
> > > a RAID1 read speed could be much better. These are SATA disks with 3Gb
> of
> > > RAM so I did 'time bash -c "dd if=/dev/zero of=bigfile bs=8k
> count=786432
> > > && sync"'. File system is ext3 (if read many times in the list that XFS
> > > is faster), but I don't want to change the file system right now.
> > > Modifing the readahead from the current 1024k to 2048k doesn't make any
> > > difference. Are there any other tweaks I can make?
> > >
> > >
> > > ---------------------------(end of broadcast)---------------------------
> > > TIP 4: Have you searched our list archives?
> > >
> > > http://archives.postgresql.org
> >
> > ---------------------------(end of broadcast)---------------------------
> > TIP 6: explain analyze is your friend
>
> --
> Albert Cervera Areny
> Dept. Informàtica Sedifa, S.L.
>
> Av. Can Bordoll, 149
> 08202 - Sabadell (Barcelona)
> Tel. 93 715 51 11
> Fax. 93 715 51 12
>
> ================================================== ==================
> ........................ AVISO LEGAL ............................
> La presente comunicación y sus anexos tiene como destinatario la
> persona a la que va dirigida, por lo que si usted lo recibe
> por error debe notificarlo al remitente y eliminarlo de su
> sistema, no pudiendo utilizarlo, total o parcialmente, para
> ningún fin. Su contenido puede tener información confidencial o
> protegida legalmente y únicamente expresa la opinión del
> remitente. El uso del correo electrónico vía Internet no
> permite asegurar ni la confidencialidad de los mensajes
> ni su correcta recepción. En el caso de que el
> destinatario no consintiera la utilización del correo electrónico,
> deberá ponerlo en nuestro conocimiento inmediatamente.
> ================================================== ==================
> ........................... DISCLAIMER .............................
> This message and its attachments are intended exclusively for the
> named addressee. If you receive this message in error, please
> immediately delete it from your system and notify the sender. You
> may not use this message or any part of it for any purpose.
> The message may contain information that is confidential or
> protected by law, and any opinions expressed are those of the
> individual sender. Internet e-mail guarantees neither the
> confidentiality nor the proper receipt of the message sent.
> If the addressee of this message does not consent to the use
> of internet e-mail, please inform us inmmediately.
> ================================================== ==================
>
>
>
>
> ---------------------------(end of broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org so that your
> message can get through to the mailing list cleanly
>

---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match

Albert,

On 5/30/07 8:00 AM, "Albert Cervera Areny" <albert@sedifa.com> wrote:

> Hardware isn't very good I believe, and it's about 2-3 years old, but the RAID
> is Linux software, and though not very good the difference between reading
> and writing should probably be greater... (?)

Not for one thread/process of I/O. Mirror sets can nearly double the read
performance on most RAID adapters or SW RAID when using two or more
thread/processes, but a single thread will get one drive worth of
performance.

You should try running two simultaneous processes during reading and see
what you get.

> Would you set 512Kb readahead on both drives and RAID? I tried various
> configurations and none seemed to make a big difference. It seemed correct to
> me to set 512kb per drive and 1024kb for md0.

Shouldn't matter that much, but yes, each drive getting half the readahead
is a good strategy. Try 256+256 and 512.

The problem you have is likely not related to the readahead though - I
suggest you try read/write to a single disk and see what you get. You
should get around 60 MB/s if the drive is a modern 7200 RPM SATA disk. If
you aren't getting that on a single drive, there's something wrong with the
SATA driver or the drive(s).

- Luke
> A Dimecres 30 Maig 2007 16:09, Luke Lonergan va escriure:
>> This sounds like a bad RAID controller - are you using a built-in hardware
>> RAID? If so, you will likely want to use Linux software RAID instead.
>>
>> Also - you might want to try a 512KB readahead - I've found that is optimal
>> for RAID1 on some RAID controllers.
>>
>> - Luke
>>
>> On 5/30/07 2:35 AM, "Albert Cervera Areny" <albert@sedifa.com> wrote:
>>> Hi,
>>> after doing the "dd" tests for a server we have at work I obtained:
>>> Read: 47.20 Mb/s
>>> Write: 39.82 Mb/s
>>> Some days ago read performance was around 20Mb/s due to no readahead in
>>> md0 so I modified it using hdparm. However, it seems to me that being it
>>> a RAID1 read speed could be much better. These are SATA disks with 3Gb of
>>> RAM so I did 'time bash -c "dd if=/dev/zero of=bigfile bs=8k count=786432
>>> && sync"'. File system is ext3 (if read many times in the list that XFS
>>> is faster), but I don't want to change the file system right now.
>>> Modifing the readahead from the current 1024k to 2048k doesn't make any
>>> difference. Are there any other tweaks I can make?
>>>
>>>
>>> ---------------------------(end of broadcast)---------------------------
>>> TIP 4: Have you searched our list archives?
>>>
>>> http://archives.postgresql.org
>>
>> ---------------------------(end of broadcast)---------------------------
>> TIP 6: explain analyze is your friend



---------------------------(end of broadcast)---------------------------
TIP 5: don't forget to increase your free space map settings

As you suggested with two threads I get 42.39 Mb/s in one and 40.70 Mb/s in
the other one, so that's more than 80Mb/s. That's what I expected with a
single thread, so thanks for the information. It seems I will have to buy
better hard drives if I want increased performance...

A Dimecres 30 Maig 2007 22:13, Luke Lonergan va escriure:
> Not for one thread/process of I/O. *Mirror sets can nearly double the read
> performance on most RAID adapters or SW RAID when using two or more
> thread/processes, but a single thread will get one drive worth of
> performance.
>
> You should try running two simultaneous processes during reading and see
> what you get.



---------------------------(end of broadcast)---------------------------
TIP 2: Don't 'kill -9' the postmaster