At 8k block size, you can do more iops sequential than random.
A X25-M I was just playing with will do about 16K iops reads at 8k block size with 32 concurrent threads.
That is about 128MB/sec. Sequential reads will do 250MB/sec. At 16k block size it does about 220MB/sec and at 32k
blocksize there is no penalty for random access. All tests start with 'cat 3 > /proc/sys/vm/drop_caches', and work
ona 32GB data set (40% of the disk).
Also, over time the actual location of the physical blocks will not map to the LBAs requested. This means that
internallya sequential read is actually a random read, and that a random write is actually a sequential write. That is
howthe SSD's with good write performance are doing it, with advanced LBA to physical dynamic mapping.
As for the random_page_cost I'd make sure to set it virtually the same as the sequential cost. Perhaps 1 for
sequentialand 1.1 for random. One may also want to lower both of those values equally to be somewhat closer to the cpu
costs. You want the planner to generally conserve total block access count and not favor streaming reads too much over
randomreads.
________________________________________
From: pgsql-performance-owner@postgresql.org [pgsql-performance-owner@postgresql.org] On Behalf Of Grzegorz Jaśkiewicz
[gryzman@gmail.com]
Sent: Wednesday, March 11, 2009 8:37 AM
On Wed, Mar 11, 2009 at 1:46 PM, Jeff <threshar@torgo.978.org> wrote:
> I've got a couple x25-e's in production now and they are working like a
> champ. (In fact, I've got another box being built with all x25s in it. its
> going to smoke!)
>
> Anyway, I was just reading another thread on here and that made me wonder
> about random_page_cost in the world of an ssd where a seek is basically
> free. I haven't tested this yet (I can do that next week), but logically,
> in this scenario wouldn't lowering random_page_cost be ideal or would it not
> really matter in the grand scheme of things?
Just on a side note, random access on SSD is still more expensive than
sequential, because it is designed in banks.
If you don believe me, turn off any software/OS cache , and try random
access timing against seq reads.
This gap is just much much narrower.
--
GJ
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
