On Fri, 30 Jan 2009, Scott Carey wrote:
For anyone worried about the X 25–M’s ability to withstand lots of write
cycles ... Calculate how long it would take you to write 800TB to the
drive at a typical rate. For most use cases that’s going to be > 5
years. For the 160GB version, it will take
On Feb 3, 2009, at 1:43 PM, Scott Carey wrote:
I don’t think write caching on the disks is a risk to data integrity
if you are configured correctly.
Furthermore, these drives don’t use the RAM for write cache, they
only use a bit of SRAM on the controller chip for that (and respect
fsync),
On Wed, 4 Feb 2009, Jeff wrote:
On Feb 3, 2009, at 1:43 PM, Scott Carey wrote:
I don?t think write caching on the disks is a risk to data integrity if you
are configured correctly.
Furthermore, these drives don?t use the RAM for write cache, they only use
a bit of SRAM on the controller chip
On Tue, Feb 3, 2009 at 10:54 AM, Jeff wrote:
> Now, moving into reality I compiled 8.3.latest and gave it a whirl. Running
> against a software R1 of the 2 x25-e's I got the following pgbench results:
> (note config tweaks: work_mem=>4mb, shared_buffers=>1gb, should probably
> have tweaked chec
I don't think write caching on the disks is a risk to data integrity if you are
configured correctly.
Furthermore, these drives don't use the RAM for write cache, they only use a
bit of SRAM on the controller chip for that (and respect fsync), so write
caching should be fine.
Confirm that NCQ i
On Tue, Feb 3, 2009 at 9:54 AM, Jeff wrote:
> Scalefactor 50, 10 clients: 900tps
>
> At scalefactor 50 the dataset fits well within memory, so I scaled it up.
>
> Scalefactor 1500: 10 clients: 420tps
>
> While some of us have arrays that can smash those numbers, that is crazy
> impressive for a pl
I somehow managed to convince the powers that be to let me get a
couple X25-E's.
I tossed them in my macpro (8 cores), fired up Ubuntu 8.10 and did
some testing.
Raw numbers are very impressive. I was able to get 3700 random seek
+read's a second. In a R1 config it stayed at 3700, but if I a
On 1/23/09 3:35 AM, "da...@lang.hm" wrote:
http://techreport.com/articles.x/15931/1
one thing that both of these reviews show is that if you are doing a
significant amount of writing the X-25M is no better than a normal hard
drive (and much of the time in the middle to bottom of the pack compa
On Tue, 27 Jan 2009, James Mansion wrote:
Craig Ringer wrote:
These devices would be interesting for a few uses, IMO. One is temp
table space and sort space in Pg. Another is scratch space for apps
(like Photoshop) that do their own VM management. There's also potential
Surely temp tables and
Craig Ringer wrote:
These devices would be interesting for a few uses, IMO. One is temp
table space and sort space in Pg. Another is scratch space for apps
(like Photoshop) that do their own VM management. There's also potential
Surely temp tables and sort space isn't subject to fsync and won'
On Sun, 25 Jan 2009, Gregory Stark wrote:
da...@lang.hm writes:
they currently have it do a backup immediatly on power loss (which is a safe
choice as the contents won't be changing without power), but it then powers off
(which is not good for startup time afterwords)
So if you have a situat
da...@lang.hm writes:
> they currently have it do a backup immediatly on power loss (which is a safe
> choice as the contents won't be changing without power), but it then powers
> off
> (which is not good for startup time afterwords)
So if you have a situation where it's power cycling rapidly e
On Sun, 25 Jan 2009, Greg Smith wrote:
On Fri, 23 Jan 2009, da...@lang.hm wrote:
take a look at this ram based drive, specificly look at the numbers here
http://techreport.com/articles.x/16255/9
they are about as much above the X25-e as the X25-e is above normal drives.
They're so close to h
On Fri, 23 Jan 2009, da...@lang.hm wrote:
take a look at this ram based drive, specificly look at the numbers here
http://techreport.com/articles.x/16255/9
they are about as much above the X25-e as the X25-e is above normal drives.
They're so close to having a killer product with that one. Al
Joshua D. Drake wrote:
> This community is notorious for "optimum". MySQL is notorious for "satisfy".
Within *this* community, MySQL is just plain notorious. Let's face it --
we are *not* dolphin-safe.
>
> Which one would you rather store your financial information in?
The one that had the be
On Fri, 23 Jan 2009, M. Edward (Ed) Borasky wrote:
* large-capacity inexpensive rotating disks,
* a hardware RAID controller containing a battery-backed cache,
* as much RAM as one can afford and the chassis will hold, and
* enough cores to keep the workload from becoming processor-bound
are goo
On Fri, 2009-01-23 at 09:22 -0800, M. Edward (Ed) Borasky wrote:
> I question, however, whether there's much point in seeking an optimum.
> As was noted long ago by Nobel laureate Herbert Simon, in actual fact
> managers / businesses rarely optimize. Instead, they satisfice. They do
> what is "goo
ting option.
>
> David Lang
>
>> - Luke
>>
>> - Original Message -----
>> From: pgsql-performance-ow...@postgresql.org
>>
>> To: Glyn Astill
>> Cc: pgsql-performance@postgresql.org
>> Sent: Fri Jan 23 04:39:07 2009
>> Subject: Re
On Fri, 23 Jan 2009, Merlin Moncure wrote:
On 1/23/09, da...@lang.hm wrote:
the review also includes the Intel X-25E and X-25M drives (along with a
variety of SCSI and SATA drives)
The x25-e is a game changer for database storage. It's still a little
pricey for what it does but who can ar
On 1/23/09, da...@lang.hm wrote:
> the review also includes the Intel X-25E and X-25M drives (along with a
> variety of SCSI and SATA drives)
>
The x25-e is a game changer for database storage. It's still a little
pricey for what it does but who can argue with these numbers?
http://techreport.c
* Craig Ringer:
> I'd be much more confident with something like those devices than I
> would with an OS ramdisk plus startup/shutdown scripts to initialize it
> from a file and write it out to a file. Wouldn't it be a pain if the UPS
> didn't give the OS enough warning to write the RAM disk out b
Luke Lonergan wrote:
> Why not simply plug your server into a UPS and get 10-20x the performance
> using the same approach (with OS IO cache)?
A big reason is that your machine may already have as much RAM as is
currently economical to install. Hardware with LOTS of RAM slots can
cost quite a bit
Hmm - I wonder what OS it runs ;-)
- Luke
- Original Message -
From: da...@lang.hm
To: Luke Lonergan
Cc: glynast...@yahoo.co.uk ;
pgsql-performance@postgresql.org
Sent: Fri Jan 23 04:52:27 2009
Subject: Re: [PERFORM] SSD performance
On Fri, 23 Jan 2009, Luke Lonergan wrote:
>
On Fri, 23 Jan 2009, Luke Lonergan wrote:
Why not simply plug your server into a UPS and get 10-20x the
performance using the same approach (with OS IO cache)?
In fact, with the server it's more robust, as you don't have to transit
several intervening physical devices to get to the RAM.
If y
t: Fri Jan 23 04:39:07 2009
Subject: Re: [PERFORM] SSD performance
On Fri, 23 Jan 2009, Glyn Astill wrote:
I spotted a new interesting SSD review. it's a $379
5.25" drive bay device that holds up to 8 DDR2 DIMMS
(up to 8G per DIMM) and appears to the system as a SATA
drive (or a pair o
a RAMDISK.
Cheaper/faster/improved reliability.
- Luke
- Original Message -
From: pgsql-performance-ow...@postgresql.org
To: Glyn Astill
Cc: pgsql-performance@postgresql.org
Sent: Fri Jan 23 04:39:07 2009
Subject: Re: [PERFORM] SSD performance
On Fri, 23 Jan 2009, Glyn Astill wr
On Fri, 23 Jan 2009, Glyn Astill wrote:
I spotted a new interesting SSD review. it's a $379
5.25" drive bay device that holds up to 8 DDR2 DIMMS
(up to 8G per DIMM) and appears to the system as a SATA
drive (or a pair of SATA drives that you can RAID-0 to get
past the 300MB/s SATA bottleneck)
> I spotted a new interesting SSD review. it's a $379
> 5.25" drive bay device that holds up to 8 DDR2 DIMMS
> (up to 8G per DIMM) and appears to the system as a SATA
> drive (or a pair of SATA drives that you can RAID-0 to get
> past the 300MB/s SATA bottleneck)
>
Sounds very similar to the Giga
I spotted a new interesting SSD review. it's a $379 5.25" drive bay device
that holds up to 8 DDR2 DIMMS (up to 8G per DIMM) and appears to the
system as a SATA drive (or a pair of SATA drives that you can RAID-0 to
get past the 300MB/s SATA bottleneck)
the best review I've seen only ran it on
Scott Marlowe wrote:
On Thu, Jul 31, 2008 at 11:45 AM, Matthew T. O'Connor <[EMAIL PROTECTED]> wrote:
Interesting read...
http://www.linux.com/feature/142658
Wish he had used a dataset larger than 1G...
Wish he had performed a test with the index on a dedicated SATA.
HH
--
On Thu, Jul 31, 2008 at 11:45 AM, Matthew T. O'Connor <[EMAIL PROTECTED]> wrote:
> Interesting read...
>
> http://www.linux.com/feature/142658
Wish he had used a dataset larger than 1G...
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscr
Interesting read...
http://www.linux.com/feature/142658
--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance
32 matches
Mail list logo
