Unix Technical Forum

Vacuum full is slow

This is a discussion on Vacuum full is slow within the Pgsql Performance forums, part of the PostgreSQL category; --> At 02:08 PM 3/20/2007, Dave Cramer wrote: >On 20-Mar-07, at 1:53 PM, Benjamin Arai wrote: > >>This is a ...


Go Back   Unix Technical Forum > Database Server Software > PostgreSQL > Pgsql Performance

FAQ Members List Calendar Search Today's Posts Mark Forums Read
  #11 (permalink)  
Old 04-19-2008, 10:24 AM
Ron
 
Posts: n/a
Default Re: SATA RAID: Promise vs. 3ware

At 02:08 PM 3/20/2007, Dave Cramer wrote:

>On 20-Mar-07, at 1:53 PM, Benjamin Arai wrote:
>
>>This is a little biased but I would stay away from areca only
>>because they have fans on the card. At some point down the line
>>that card is going to die. When it does there is really no telling
>>what it will do to your data.


Ummm ?what? fan? The Intel IOP341 (AKA 81341) based ARC-12xx cards
are what people are most likely going to want to buy at this point,
and they are fanless:
http://www.areca.us/support/photo_gallery.htm

The "lore" is that
+3ware is best at random IO and Areca is best at streaming IO. OLTP
=> 3ware. OLAP => Areca.
- stay away from Adaptec or Promise for any mission critical role.
= LSI is a mixed bag.


>Well, they are also the only one of the bunch that I am aware of
>that will sell you 1G of cache.


Actually, it's up to 2GB of BB cache... 2GB DDR2 SDRAMs are cheap
and easy to get now. I've actually been agitating for Areca to
support 4GB of RAM.


>Plus if you use battery backup sooner or later you have to replace
>the batteries. I use areca all the time and I've never had a fan
>die, but I admit it is a point of failure.


I've had the whole card die (massive cooling failure in NOC led to
....), but never any component on the card. OTOH, I'm conservative
about how much heat per unit area I'm willing to allow to occur in or
near my DB servers.

Cheers,
Ron


---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
  #12 (permalink)  
Old 04-19-2008, 10:26 AM
Scott Marlowe
 
Posts: n/a
Default Re: Vacuum full is slow

On Mon, 2007-03-19 at 06:02, Ruben Rubio wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi,
>
> Vacuum full is very slow for me . I dont know how to speed it up. It
> takes between 60 and 90 minutes.
>
> I have set up autovacuum but I also run vacuum full once per week.


Note two things.

1: you need to update your pgsql version. 8.1.3 is a bit old.

2: You shouldn't normally need to run vacuum full. Vacuum full is
there to get you out of problems created when regular vacuum falls
behind. It contributes to index bloat as well. If routine vacuuming
isn't working, regular vacuum full is not the answer (well, 99% of the
time it's not). Fixing routing vacuuming is the answer.

If you don't have an actual problem with routine vacuuming, you would be
better off writing a monitoring script to keep track of bloat in tables
and send you an email than running vacuum full all the time.

---------------------------(end of broadcast)---------------------------
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to majordomo@postgresql.org so that your
message can get through to the mailing list cleanly

Digg this Post!Add Post to del.icio.usBookmark Post in TechnoratiFurl this Post!
Reply With Quote
Reply


Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On
Forum Jump


All times are GMT. The time now is 05:12 AM.


Powered by vBulletin® Version 3.6.5
Copyright ©2000 - 2008, Jelsoft Enterprises Ltd.
Search Engine Optimization by vBSEO 3.2.0
www.UnixAdminTalk.com