Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-29 Thread Claus Guttesen
 I missed the initial post in this thread, but I haven't seen any 15K rpm
 2.5 drives, so if you compare 10K rpm 2.5 drives with 15K rpm 3.5
 drives you will see differences (depending on your workload and controller
 cache)

I have some 15K rpm 2.5 sas-drives from HP. Other vendors have them as well.

-- 
regards
Claus

When lenity and cruelty play for a kingdom,
the gentlest gamester is the soonest winner.

Shakespeare

---(end of broadcast)---
TIP 7: You can help support the PostgreSQL project by donating at

http://www.postgresql.org/about/donate


Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-29 Thread Mike Smith
You don't mention the capacity of the disks you are looking at. Here is
something you might want to consider. 

 

I've seen a few performance posts on using different hardware
technologies to gain improvements. Most of those comments are on raid,
interface and rotation speed.   One area that doesn't seem to have  been
mentioned  is to  run your disks empty.

 

One of the key roadblocks in disk performance is the time for the disk
heads to seek, settle and find the start of the data. Another is the
time to transfer from disk to interface.  Everyone may instinctively
know this but its often ignored.

 

Hard disks are CRV ( constant rotational velocity) = they spin at the
same speed all the time

Hard disk  drives use a technology called ZBR  = Zone Bit Recording =  a
lot more data on the outside tracks than the inner ones.

Hard disk fill up from outside track to inside track  generally unless
you've done some weird partitioning.

 

On the outside of the disk you get a lot more data per seek than on the
inside. Double whammy you get it faster.

Performance  can vary more than  100% between the outer and inner tracks
of the disk.   So running a slower disk twice as big may give you more
benefit than running a small capacity 15K disk full.  The slower disks
are also generally more reliable and mostly much cheaper. 

 

The other issue for full disks especially with lots of random small
transactions is the heads are seeking and settling  across the whole
disk but  typically with most of those seeks being on the latest
transactions which are placed nicely towards the middle of the disk.

 

I know of a major bank that has a  rule of thumb 25% of the disk
partioned  as  a target maximum for high performance disk systems in a
key application. They also only pay for used capacity from their disk
vendor.   

 

This is not very green as you need to buy more disks for the same amount
of data and its liable to upset your purchasing department who won't
understand why you don't want to fill your disks up.

 

Mike 

 



Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-29 Thread Arjen van der Meijden
There are several suppliers who offer Seagate's 2.5 15k rpm disks, I 
know HP, Dell are amongst those. So I was actually refering to those, 
rather than to the 10k one's.


Best regards,

Arjen

[EMAIL PROTECTED] wrote:

On Mon, 28 Jan 2008, Arjen van der Meijden wrote:


On 28-1-2008 20:25 Christian Nicolaisen wrote:
So, my question is: should I go for the 2.5 disk setup or 3.5 disk 
setup, and does the raid setup in either case look correct?


Afaik they are about equal in speed. With the smaller ones being a bit 
faster in random access and the larger ones a bit faster for 
sequential reads/writes.


I missed the initial post in this thread, but I haven't seen any 15K rpm 
2.5 drives, so if you compare 10K rpm 2.5 drives with 15K rpm 3.5 
drives you will see differences (depending on your workload and 
controller cache)


David Lang


---(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



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


Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-29 Thread Craig James

Mike Smith wrote:
I’ve seen a few performance posts on using different hardware 
technologies to gain improvements. Most of those comments are on raid, 
 interface and rotation speed.   One area that doesn’t seem to have 
 been mentioned  is to  run your disks empty.

...
On the outside of the disk you get a lot more data per seek than on the 
inside. Double whammy you get it faster.


Performance  can vary more than  100% between the outer and inner tracks 
of the disk.   So running a slower disk twice as big may give you more 
benefit than running a small capacity 15K disk full.  The slower disks 
are also generally more reliable and mostly much cheaper.

...
This is not very green as you need to buy more disks for the same amount 
of data and its liable to upset your purchasing department who won’t 
understand why you don’t want to fill your disks up.


So presumably the empty-disk effect could also be achieved by partitioning, say 25% of 
the drive for the database, and 75% empty partition.  But in fact, you could use that 
low performance 75% for rarely-used or static data, such as the output from 
pg_dump, that is written during non-peak times.

Pretty cool.

Craig

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


Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-29 Thread Mike Smith
[presumably the empty-disk effect could also be achieved by partitioning, say 
25% of the drive for the database, and 75% empty partition.  But in fact, you 
could use that low performance 75% for rarely-used or static data, such as 
the output from pg_dump, that is written during non-peak times] 
 
Larry Ellison financed a  company called Pillar Data Systems which was founded 
on the principle that you can tier the disk according to the value and 
performance requirements of the data. They planned to put  the most valuable in 
performance terms on the outside of  SATA disks  and use the empty space in the 
middle for  slower stuff..
(This is not an advert. I like the idea but I dont know if it works well and I 
dont have anything to do with Pillar  other than EnterpriseDB compete against 
Larry's other little company).   
Probably the way to go is flash drives for primary performance data . EMC and 
others have announced   Enterprise Flash Drives  (they claim 30 times 
performance of 15K disks  although at 30 times the cost of standard disk today 
). Flash should also have pretty much consistent high performance across the 
whole capacity.
Within a couple of years EFD  should be affordable for mainstream use.


Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-28 Thread Arjen van der Meijden

On 28-1-2008 20:25 Christian Nicolaisen wrote:
So, my question is: should I go for the 2.5 disk setup or 3.5 disk 
setup, and does the raid setup in either case look correct?


Afaik they are about equal in speed. With the smaller ones being a bit 
faster in random access and the larger ones a bit faster for sequential 
reads/writes.


My guess is that the 8x 2.5 configuration will be faster than the 6x 
3.5, even if the 3.5-drives happen to be faster they probably aren't 
50% faster... So since you don't need the larger storage capacities that 
3.5 offer, I'd go with the 8x 2.5-setup.


Best regards,

Arjen

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [PERFORM] 8x2.5 or 6x3.5 disks

2008-01-28 Thread david

On Mon, 28 Jan 2008, Arjen van der Meijden wrote:


On 28-1-2008 20:25 Christian Nicolaisen wrote:
So, my question is: should I go for the 2.5 disk setup or 3.5 disk setup, 
and does the raid setup in either case look correct?


Afaik they are about equal in speed. With the smaller ones being a bit faster 
in random access and the larger ones a bit faster for sequential 
reads/writes.


I missed the initial post in this thread, but I haven't seen any 15K rpm 
2.5 drives, so if you compare 10K rpm 2.5 drives with 15K rpm 3.5 
drives you will see differences (depending on your workload and controller 
cache)


David Lang


---(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