Hello,
I'm about to buy SSD drive(s) for a database. For decision making, I
used this tech report:
http://techreport.com/articles.x/16255/9
http://techreport.com/articles.x/16255/10
Here are my concerns:
* I need at least 32GB disk space. So DRAM based SSD is not a real
option. I
Note that some RAID controllers (3Ware in particular) refuse to
recognize the MLC drives, in particular, they act as if the OCZ Vertex
series do not exist when connected.
I don't know what they're looking for (perhaps some indication that
actual rotation is happening?) but this is a potential
This is very fast.
On IT Toolbox there are many whitepapers about it.
On the ERP and DataCenter sections specifically.
We need that all tests that we do, we can share it on the
Project Wiki.
Regards
On Nov 13, 2009, at 7:02 AM, Karl Denninger wrote:
Laszlo Nagy wrote:
Hello,
I'm about to
2009/11/13 Laszlo Nagy gand...@shopzeus.com:
Hello,
I'm about to buy SSD drive(s) for a database. For decision making, I used
this tech report:
http://techreport.com/articles.x/16255/9
http://techreport.com/articles.x/16255/10
Here are my concerns:
* I need at least 32GB disk space.
On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe scott.marl...@gmail.com wrote:
I think RAID6 is gonna reduce the throughput due to overhead to
something far less than what a software RAID-10 would achieve.
I was wondering about this. I think raid 5/6 might be a better fit
for SSD than
Laszlo Nagy wrote:
* I need at least 32GB disk space. So DRAM based SSD is not a real
option. I would have to buy 8x4GB memory, costs a fortune. And
then it would still not have redundancy.
At 32GB database size, I'd seriously consider just buying a server with
a regular hard
2009/11/13 Heikki Linnakangas heikki.linnakan...@enterprisedb.com:
Laszlo Nagy wrote:
* I need at least 32GB disk space. So DRAM based SSD is not a real
option. I would have to buy 8x4GB memory, costs a fortune. And
then it would still not have redundancy.
At 32GB database size,
On 11/13/09 7:29 AM, Merlin Moncure mmonc...@gmail.com wrote:
On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe scott.marl...@gmail.com
wrote:
I think RAID6 is gonna reduce the throughput due to overhead to
something far less than what a software RAID-10 would achieve.
I was wondering
Greg Smith wrote:
In order for a drive to work reliably for database use such as for
PostgreSQL, it cannot have a volatile write cache. You either need a
write cache with a battery backup (and a UPS doesn't count), or to
turn the cache off. The SSD performance figures you've been looking
Karl Denninger wrote:
If power is unexpectedly removed from the system, this is true. But
the caches on the SSD controllers are BUFFERS. An operating system
crash does not disrupt the data in them or cause corruption. An
unexpected disconnection of the power source from the drive (due to
Greg Smith wrote:
Karl Denninger wrote:
If power is unexpectedly removed from the system, this is true. But
the caches on the SSD controllers are BUFFERS. An operating system
crash does not disrupt the data in them or cause corruption. An
unexpected disconnection of the power source from
On Fri, Nov 13, 2009 at 12:22 PM, Scott Carey
sc...@richrelevance.com On 11/13/09 7:29 AM, Merlin Moncure
mmonc...@gmail.com wrote:
On Fri, Nov 13, 2009 at 9:48 AM, Scott Marlowe scott.marl...@gmail.com
wrote:
I think RAID6 is gonna reduce the throughput due to overhead to
something far less
2009/11/13 Greg Smith g...@2ndquadrant.com:
In order for a drive to work reliably for database use such as for
PostgreSQL, it cannot have a volatile write cache. You either need a write
cache with a battery backup (and a UPS doesn't count), or to turn the cache
off. The SSD performance
Greg Smith wrote:
Karl Denninger wrote:
With the write cache off on these disks they still are huge wins for
very-heavy-read applications, which many are.
Very read-heavy applications would do better to buy a ton of RAM
instead and just make sure they populate from permanent media (say by
Itching to jump in here :-)
There are a lot of things to trade off when choosing storage for a
database: performance for different parts of the workload,
reliability, performance in degraded mode (when a disk dies), backup
methodologies, etc. ... the mistake many people make is to overlook
the
-Mensaje original-
Laszlo Nagy
My question is about the last option. Are there any good RAID
cards that are optimized (or can be optimized) for SSD
drives? Do any of you have experience in using many cheaper
SSD drives? Is it a bad idea?
Thank you,
Laszlo
Never
[ removing -jobs from cc list as it is not appropriate for this posting ]
On Thu, Nov 12, 2009 at 3:18 AM, Brahma Prakash Tiwari
brahma.tiw...@inventum.cc wrote:
Hi all
Why age (datfrozenxid) in postgres becomes 1073742202 not zero after vacuum
of database.
Thanks in advance
I think you're
Brad Nicholson wrote:
Out of curiosity, what are those narrow use cases where you think
SSD's are the correct technology?
Dave Crooke did a good summary already, I see things like this:
* You need to have a read-heavy app that's bigger than RAM, but not too
big so it can still fit on SSD
*
2009/11/13 Greg Smith g...@2ndquadrant.com:
As far as what real-world apps have that profile, I like SSDs for small to
medium web applications that have to be responsive, where the user shows up
and wants their randomly distributed and uncached data with minimal latency.
SSDs can also be used
Fernando Hevia wrote:
Shouldn't their write performance be more than a trade-off for fsync?
Not if you have sequential writes that are regularly fsync'd--which is
exactly how the WAL writes things out in PostgreSQL. I think there's a
potential for SSD to reach a point where they can give
The FusionIO products are a little different. They are card based vs trying to
emulate a traditional disk. In terms of volatility, they have an on-board
capacitor that allows power to be supplied until all writes drain. They do not
have a cache in front of them like a disk-type SSD might.
On 13/11/2009 2:29 PM, Dave Crooke wrote:
Beware that VACUUM FULL locks an entire table at a time :-)
... and often bloats its indexes horribly. Use CLUSTER instead if you
need to chop a table that's massively bloated down to size; it'll be
much faster, and shouldn't leave the indexes in a
On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
cr...@postnewspapers.com.au wrote:
On 13/11/2009 2:29 PM, Dave Crooke wrote:
Beware that VACUUM FULL locks an entire table at a time :-)
... and often bloats its indexes horribly. Use CLUSTER instead if you
need to chop a table that's massively
On 14/11/2009 11:55 AM, Scott Marlowe wrote:
On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
cr...@postnewspapers.com.au wrote:
On 13/11/2009 2:29 PM, Dave Crooke wrote:
Beware that VACUUM FULL locks an entire table at a time :-)
... and often bloats its indexes horribly. Use CLUSTER instead
On Fri, Nov 13, 2009 at 9:45 PM, Craig Ringer
cr...@postnewspapers.com.au wrote:
On 14/11/2009 11:55 AM, Scott Marlowe wrote:
On Fri, Nov 13, 2009 at 8:31 PM, Craig Ringer
cr...@postnewspapers.com.au wrote:
On 13/11/2009 2:29 PM, Dave Crooke wrote:
Beware that VACUUM FULL locks an entire
25 matches
Mail list logo
