Greg Smith wrote:
Note that not all of the Sandforce drives include a capacitor; I hope
you got one that does! I wasn't aware any of the SF drives with a
capacitor on them were even shipping yet, all of the ones I'd seen
were the chipset that doesn't include one still. Haven't checked in a
few weeks though.
I think I did, it was expensive enough, though while ordering its very
easy to order the wrong one, all names on the product category page look
the same. (OCZ Vertex 2 Pro)
* How to test for power failure?
I've had good results using one of the early programs used to
investigate this class of problems:
http://brad.livejournal.com/2116715.html?page=2
A great tool, thanks for the link!
diskchecker: running 34 sec, 4.10% coverage of 500 MB (1342 writes; 39/s)
diskchecker: running 35 sec, 4.24% coverage of 500 MB (1390 writes; 39/s)
diskchecker: running 36 sec, 4.35% coverage of 500 MB (1427 writes; 39/s)
diskchecker: running 37 sec, 4.47% coverage of 500 MB (1468 writes; 39/s)
didn't get 'ok' from server (11387 316950), msg=[] = Connection reset by
peer at ./diskchecker.pl line 132.
here's where I removed the power and left it off for about a minute.
Then started again then did the verify
yeb@a:~$ ./diskchecker.pl -s client45.eemnes verify test_file
verifying: 0.00%
Total errors: 0
:-)
this was on ext2
* What filesystem to use on the SSD? To minimize writes and maximize
chance for seeing errors I'd choose ext2 here.
I don't consider there to be any reason to deploy any part of a
PostgreSQL database on ext2. The potential for downtime if the fsck
doesn't happen automatically far outweighs the minimal performance
advantage you'll actually see in real applications.
Hmm.. wouldn't that apply for other filesystems as well? I know that JFS
also won't mount if booted unclean, it somehow needs a marker from the
fsck. Don't know for ext3, xfs etc.
All of the benchmarks showing large gains for ext2 over ext3 I have
seen been synthetic, not real database performance; the internal ones
I've run using things like pgbench do not show a significant
improvement. (Yes, I'm already working on finding time to publicly
release those findings)
The reason I'd choose ext2 on the SSD was mainly to decrease the number
of writes, not for performance. Maybe I should ultimately do tests for
both journalled and ext2 filesystems and compare the amount of data per
x pgbench transactions.
Put it on ext3, toggle on noatime, and move on to testing. The
overhead of the metadata writes is the least of the problems when
doing write-heavy stuff on Linux.
Will surely do and post the results.
thanks,
Yeb Havinga
--
Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
