Обсуждение: random_page_cost vs ssd?

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?

--
Jeff Trout <jeff@jefftrout.com>
http://www.stuarthamm.net/
http://www.dellsmartexitin.com/

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

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

2009/3/12 Scott Carey <scott@richrelevance.com>:
> [...snip...].    All tests start with 'cat 3 > /proc/sys/vm/drop_caches', and work on
>  a 32GB data set (40% of the disk).
What's the content of '3' above?

--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.american.edu/econ/notes/htmlmail.htm

2009/3/12 Scott Carey <scott@richrelevance.com>:
> [...snip...].    All tests start with 'cat 3 > /proc/sys/vm/drop_caches', and work on
>  a 32GB data set (40% of the disk).
What's the content of '3' above?

--
Please don't top post, and don't use HTML e-Mail :}  Make your quotes concise.

http://www.american.edu/econ/notes/htmlmail.htm

On Wed, Mar 11, 2009 at 12:28:56PM -0700, Scott Carey wrote:
> Google > “linux drop_caches” first result:
> http://www.linuxinsight.com/proc_sys_vm_drop_caches.html
> To be sure a test is going to disk and not file system cache for everything in linux, run:
> ‘sync; cat 3 > /proc/sys/vm/drop_caches’

well. the url you showed tells to do: echo 3 > ...
cat 3 is "slightly" different.

Best regards,

depesz

--
Linkedin: http://www.linkedin.com/in/depesz  /  blog: http://www.depesz.com/
jid/gtalk: depesz@depesz.com / aim:depeszhdl / skype:depesz_hdl / gg:6749007

Scott Carey <scott@richrelevance.com> wrote:
> On 3/11/09 11:04 AM, "Andrej" <andrej.groups@gmail.com> wrote:
>> 2009/3/12 Scott Carey <scott@richrelevance.com>:

>>> All tests start with 'cat 3 > /proc/sys/vm/drop_caches'

>> What's the content of '3' above?

> Google > *linux drop_caches* first result:
> http://www.linuxinsight.com/proc_sys_vm_drop_caches.html
>
> To be sure a test is going to disk and not file system cache for
> everything in linux, run:
> *sync; cat 3 > /proc/sys/vm/drop_caches*

The cited page recommends "echo 3" -- is that what you used in your
tests, or the "cat 3" you repeated specify?  If the latter, what is in
the "3" file?

>> Please don't top post, and don't use HTML e-Mail :}  Make your
>> quotes concise.
>>
>> http://www.american.edu/econ/notes/htmlmail.htm

Did you miss this part?

-Kevin

Scott Carey <scott@richrelevance.com> wrote:
> On 3/11/09 11:04 AM, "Andrej" <andrej.groups@gmail.com> wrote:
>> 2009/3/12 Scott Carey <scott@richrelevance.com>:

>>> All tests start with 'cat 3 > /proc/sys/vm/drop_caches'

>> What's the content of '3' above?

> Google > *linux drop_caches* first result:
> http://www.linuxinsight.com/proc_sys_vm_drop_caches.html
>
> To be sure a test is going to disk and not file system cache for
> everything in linux, run:
> *sync; cat 3 > /proc/sys/vm/drop_caches*

The cited page recommends "echo 3" -- is that what you used in your
tests, or the "cat 3" you repeated specify?  If the latter, what is in
the "3" file?

>> Please don't top post, and don't use HTML e-Mail :}  Make your
>> quotes concise.
>>
>> http://www.american.edu/econ/notes/htmlmail.htm

Did you miss this part?

-Kevin