On 11-Jul-07, at 2:35 PM, Greg Smith wrote:
On Wed, 11 Jul 2007, Jim Nasby wrote:
I suppose an entirely in-memory database might be able to swamp a
2 drive WAL as well.
You can really generate a whole lot of WAL volume on an EMC SAN if
you're doing UPDATEs fast enough on data that is mos
On Wed, 11 Jul 2007, Jim Nasby wrote:
I suppose an entirely in-memory database might be able to swamp a 2
drive WAL as well.
You can really generate a whole lot of WAL volume on an EMC SAN if you're
doing UPDATEs fast enough on data that is mostly in-memory. Takes a
fairly specific type of
On Wed, Jul 11, 2007 at 01:39:39PM -0400, Chris Browne wrote:
> load causes. A fallout of this is that those disks are likely to be
> worked harder than the disk used for storing "plain old data," with
> the result that if you devote disk to WAL, you'll likely burn thru
> replacement drives faster
On Jul 11, 2007, at 12:39 PM, Chris Browne wrote:
- Split off a set (6?) for WAL
In my limited testing, 6 drives for WAL would be complete overkill in
almost any case. The only example I've ever seen where WAL was able
to swamp 2 drives was the DBT testing that Mark Wong was doing at
OSD
[EMAIL PROTECTED] (Dave Cramer) writes:
> On 11-Jul-07, at 10:05 AM, Gregory Stark wrote:
>
>> "Dave Cramer" <[EMAIL PROTECTED]> writes:
>>
>>> Assuming we have 24 73G drives is it better to make one big
>>> metalun and carve
>>> it up and let the SAN manage the where everything is, or is it
>>> b
On Wed, Jul 11, 2007 at 09:03:27AM -0400, Dave Cramer wrote:
> Problem with dedicating the spindles to each array is that we end up
> wasting space. Are the SAN's smart enough to do a better job if I
> create one large metalun and cut it up ?
In my experience, this largely depends on your SAN
In my sporadic benchmark testing, the only consistent 'trick' I found
was that the best thing I could do for performance sequential
performance was allocating a bunch of mirrored pair LUNs and stripe
them with software raid. This made a huge difference (~2X) in sequential
performance, and a littl
On 11-Jul-07, at 10:05 AM, Gregory Stark wrote:
"Dave Cramer" <[EMAIL PROTECTED]> writes:
Assuming we have 24 73G drives is it better to make one big
metalun and carve
it up and let the SAN manage the where everything is, or is it
better to
specify which spindles are where.
This is qui
"Dave Cramer" <[EMAIL PROTECTED]> writes:
> Assuming we have 24 73G drives is it better to make one big metalun and carve
> it up and let the SAN manage the where everything is, or is it better to
> specify which spindles are where.
This is quite a controversial question with proponents of both
We do something similar here. We use Netapp and I carve one aggregate
per data volume. I generally keep the pg_xlog on the same "data" LUN,
but I don't mix other databases on the same aggregate.
In the NetApp world because they use RAID DP (dual parity) you have a
higher wastage of drives,
Assuming we have 24 73G drives is it better to make one big metalun
and carve it up and let the SAN manage the where everything is, or is
it better to specify which spindles are where.
Currently we would require 3 separate disk arrays.
one for the main database, second one for WAL logs, thir
11 matches
Mail list logo
