On Tue, Jan 27, 2009 at 7:03 AM, M. Edward (Ed) Borasky
wrote:
> M. Edward (Ed) Borasky wrote:
>> Given large amounts of RAM and only PostgreSQL running in the server,
>> the interesting trade-offs become
>>
>> a. How little memory can you buy without putting your service level
>> agreements at ri
On Tue, Jan 27, 2009 at 1:20 AM, A B wrote:
> While browsing the net I found a server with a raid controller
>HP Smart Array P400/512MB BBWC Controller
> How does one know what this is, if it is any good or so? I guess they
> just stuck their "HP" label onto some other raid controller?
> I
da...@lang.hm wrote:
> that's not quite the opposite of the statement that I was trying to make.
>
> assuming that you are not running anything else on the system, how much
> data can you put on the system and run entirely out of ram.
>
> the database has it's overhead (sort buffers, indexes, per
On Tue, 27 Jan 2009, M. Edward (Ed) Borasky wrote:
da...@lang.hm wrote:
On Mon, 26 Jan 2009, David Rees wrote:
And yes, the more memory you can squeeze into the machine, the better,
though you'll find that after a certain point, price starts going up
steeply. Of course, if you only have a 15
M. Edward (Ed) Borasky wrote:
> Given large amounts of RAM and only PostgreSQL running in the server,
> the interesting trade-offs become
>
> a. How little memory can you buy without putting your service level
> agreements at risk?
>
> b. How do you allocate the PostgreSQL-specific memory buffers
da...@lang.hm wrote:
> On Mon, 26 Jan 2009, David Rees wrote:
>
>> And yes, the more memory you can squeeze into the machine, the better,
>> though you'll find that after a certain point, price starts going up
>> steeply. Of course, if you only have a 15GB database, once you reach
>> 16GB of memo
>> 4) Use software raid unless you have the money to buy a raid
>> controller, in which case here is the ranking of them
>>
>
> Areca and 3ware/Escalade are the two best controllers for the money
> out right now. They tend to take turns being the absolute best as
> they release new cards. N
On Mon, 26 Jan 2009, David Rees wrote:
And yes, the more memory you can squeeze into the machine, the better,
though you'll find that after a certain point, price starts going up
steeply. Of course, if you only have a 15GB database, once you reach
16GB of memory you've pretty much hit the point
On Mon, 26 Jan 2009, Matthew Wakeling wrote:
On Sun, 25 Jan 2009, Scott Marlowe wrote:
RAID-10 is almost always the right choice.
Agreed. Unless you don't care about the data and need the space, where RAID 0
might be useful, or if you really don't need the space, where RAID 1 might be
okay.
Jeff wrote:
If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to untar / whatever it into
place. Our backup script basically does:
archive backup directory
pg_start_backup
rsync
pg_stop_backup
voila. I have 2 full copies of the d
On Mon, Jan 26, 2009 at 12:27 PM, Jeff wrote:
> I'm quite excited about the feature. I'm still on 8.2 mostly because of the
> downtime of the dump & restore. I wrote up some plans a while back on doing
> the poor-mans parallel restore, but I haven't had the time to actually do
> it.
We use slon
On Jan 26, 2009, at 3:00 PM, Joshua D. Drake wrote:
On Mon, 2009-01-26 at 14:58 -0500, Jeff wrote:
voila. I have 2 full copies of the db. You could even expand it a
bit
and after the rsync & friends have it fire up the instance and run
pg_dump against it for a pg_restore compatible dump "j
On Mon, Jan 26, 2009 at 11:58 AM, Jeff wrote:
> On Jan 26, 2009, at 2:42 PM, David Rees wrote:
>> Lots of people have databases much, much, bigger - I'd hate to imagine
>> have to restore from backup from one of those monsters.
>
> If you use PITR + rsync you can create a binary snapshot of the db
The technique Jeff is speaking of below is exactly how we do it,
except we use file-system snapshots vs rsync.
The problem is how slow log application is when recovering since it's
a single process, and very slow at that.
-kg
On Jan 26, 2009, at 11:58 AM, Jeff wrote:
On Jan 26, 2009, at
On Mon, 2009-01-26 at 14:58 -0500, Jeff wrote:
> voila. I have 2 full copies of the db. You could even expand it a bit
> and after the rsync & friends have it fire up the instance and run
> pg_dump against it for a pg_restore compatible dump "just in case".
>
> It takes a long time to restor
On Jan 26, 2009, at 2:42 PM, David Rees wrote:
Lots of people have databases much, much, bigger - I'd hate to imagine
have to restore from backup from one of those monsters.
If you use PITR + rsync you can create a binary snapshot of the db, so
restore time is simply how long it takes to u
On Mon, Jan 26, 2009 at 4:09 AM, Matthew Wakeling wrote:
> On Sun, 25 Jan 2009, Scott Marlowe wrote:
>>
>> More cores is more important than faster but fewer
>>
>> Again, more slower disks > fewer slower ones.
>
> Not necessarily. It depends what you are doing. If you're going to be
> running only
On Sun, 25 Jan 2009, Scott Marlowe wrote:
More cores is more important than faster but fewer
Again, more slower disks > fewer slower ones.
Not necessarily. It depends what you are doing. If you're going to be
running only one database connection at a time, doing really big complex
queries, t
On Sun, Jan 25, 2009 at 2:21 PM, A B wrote:
> So, the eternal problem with what hardware to buy. I really miss a
> hardware buying guide for database servers now that I'm about to buy
> one..
> Some general guidelines mixed with ranked lists of what hardware that
> is best, shouldn't that be on t
So, the eternal problem with what hardware to buy. I really miss a
hardware buying guide for database servers now that I'm about to buy
one..
Some general guidelines mixed with ranked lists of what hardware that
is best, shouldn't that be on the wiki?.
THis is of course very difficult to advice a
20 matches
Mail list logo
