From: | Nilson <nilson(dot)brazil(at)gmail(dot)com> |
---|---|
To: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Using Small Size SSDs to improve performance? |
Date: | 2010-08-04 21:09:13 |
Message-ID: | AANLkTiknzwjXNVJe0jsLiakdzCOQFo-tiEO5jkeQPagZ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
The prices of large capacity Solid State Disks (SLCs of course) are still
too high to most of us.
But it´s already possible to find SSDs of small size (8 to 32 GB) today with
affordable prices and good performance (0,1ms access time and at least
150MB/s r/w transfer rate).
So, would it possible to use these Small Size SSDs (S5Ds) as a buffer to
improve postgreSQL's write performance?
For now, I detected two opportunities:
1) usage of a S5D to temporarily store the WAL log files until a deamon
process copy them to the regular HD.
2) usage of a S5D to store instructions to a make a checkpoint. Instead of
write the "dirty" pages directly to database files, postgreSQL could dump to
SSD the dirty pages and the instructions of how update the data files.
Later, a deamon process would update the files following these instructions
and erase the instruction files after that. I guess that MVCC induces the
spread of writes along the file area, requiring lots of seeks to find the
correct disk block. So SSDs will produce a good performance in burst
situation.
I guess these ideas could improve the write performance significantly (3x to
50x) in databases systems that perform writes with SYNC and have many write
bursts or handle large (20MB+) BLOBs (many WAL segments and pages to write
on checkpoint).
Of course, postgreSQL should be patched to handle, not only with the new
behaviours, but to handle a possible SSD full.
One solution to (1) could be a fast/main volume scheme. In case of the fast
volume full condition, postgreSQL should use the main volume.
The (2) solution is more delicate because introduce a new type of file to
hold data. But, if the gain worths, it should be examinated ...
Well, that´s it.
--
Nilson
From | Date | Subject | |
---|---|---|---|
Next Message | Kevin Grittner | 2010-08-04 21:13:21 | Re: ECPG dynamic cursor fix for UPDATE/DELETE ... WHERE CURRENT OF :curname |
Previous Message | Merlin Moncure | 2010-08-04 20:42:30 | Re: Drop one-argument string_agg? (was Re: string_agg delimiter having no effect with order by) |