On Sat, Apr 30, 2011 at 4:26 AM, Phoenix Kiula wrote:
> I suppose that's what I am going to do on a periodic basis from now
> on. There is a lot of DELETE/UPDATE activity. But I wonder if the
> vacuum stuff really should do something that's similar in function?
> What do the high-end enterprise fo
On Apr 30, 2011, at 9:34 AM, Kenneth Marshall wrote:
>> I suppose that's what I am going to do on a periodic basis from now
>> on. There is a lot of DELETE/UPDATE activity. But I wonder if the
>> vacuum stuff really should do something that's similar in function?
>> What do the high-end enterprise
On Sat, Apr 30, 2011 at 05:26:36PM +0800, Phoenix Kiula wrote:
> On Sat, Apr 30, 2011 at 4:07 PM, Greg Smith wrote:
> > On 04/23/2011 03:44 PM, Robert Haas wrote:
> >>
> >> On Apr 17, 2011, at 11:30 AM, Phoenix Kiula
> >> ?wrote:
> >>
> >>>
> >>> Postgres is 8.2.9.
> >>>
> >>>
> >>
> >> An upgrade
On Sat, Apr 30, 2011 at 4:07 PM, Greg Smith wrote:
> On 04/23/2011 03:44 PM, Robert Haas wrote:
>>
>> On Apr 17, 2011, at 11:30 AM, Phoenix Kiula
>> wrote:
>>
>>>
>>> Postgres is 8.2.9.
>>>
>>>
>>
>> An upgrade would probably help you a lot, and as others have said it
>> sounds like your hardware
On 04/23/2011 03:44 PM, Robert Haas wrote:
On Apr 17, 2011, at 11:30 AM, Phoenix Kiula wrote:
Postgres is 8.2.9.
An upgrade would probably help you a lot, and as others have said it sounds
like your hardware is failing, so you probably want to deal with that first.
I am a bit surp
On Apr 17, 2011, at 11:30 AM, Phoenix Kiula wrote:
> Sorry, rejuvenating a thread that was basically unanswered.
>
> I closed the database for any kinds of access to focus on maintenance
> operations, killed all earlier processes so that my maintenance is the
> only stuff going on.
>
> REINDEX i
> Thanks. But let me do the "top" stuff later. I think I have a bigger
> problem now.
>
> While doing a PG dump, I seem to get this error:
>
> ERROR: invalid memory alloc request size 4294967293
>
> Upon googling, this seems to be a data corruption issue!
>
> One of the older messages suggests
You mean the maintenance instead of mentioning the recovery? If yes
The following types of administration commands are not accepted during
recovery mode:
-
* Data Definition Language (DDL) - e.g. CREATE INDEX*
-
* Privilege and Ownership - GRANT, REVOKE, REASSIGN*
-
* Mainten
On Mon, Apr 18, 2011 at 1:45 AM, Phoenix Kiula wrote:
> On Mon, Apr 18, 2011 at 3:38 PM, Scott Marlowe
> wrote:
>> On Sun, Apr 17, 2011 at 11:19 PM, Phoenix Kiula
>> wrote:
>>> Btw, hardware is not an issue. My db has been working fine for a
>>> while. Smaller poorer systems around the web run
On Mon, Apr 18, 2011 at 3:38 PM, Scott Marlowe wrote:
> On Sun, Apr 17, 2011 at 11:19 PM, Phoenix Kiula
> wrote:
>> Btw, hardware is not an issue. My db has been working fine for a
>> while. Smaller poorer systems around the web run InnoDB databases. I
>> wouldn't touch that with a barge pole.
>
On Sun, Apr 17, 2011 at 11:19 PM, Phoenix Kiula wrote:
> Btw, hardware is not an issue. My db has been working fine for a
> while. Smaller poorer systems around the web run InnoDB databases. I
> wouldn't touch that with a barge pole.
>
> I have a hardware RAID controller, not "fake". It's a good q
On Mon, Apr 18, 2011 at 1:26 AM, Scott Marlowe wrote:
> On Sun, Apr 17, 2011 at 11:19 PM, Phoenix Kiula
> wrote:
>> Btw, hardware is not an issue. My db has been working fine for a
>> while. Smaller poorer systems around the web run InnoDB databases. I
>> wouldn't touch that with a barge pole.
>
On Sun, Apr 17, 2011 at 11:19 PM, Phoenix Kiula wrote:
> Btw, hardware is not an issue. My db has been working fine for a
> while. Smaller poorer systems around the web run InnoDB databases. I
> wouldn't touch that with a barge pole.
Did you or someone in an earlier post say that you didn't have
People are running larger InnoDB databases on poorer hardware. Note
that I wouldn't dream of it because I care about data integrity and
stability, but this discussion is purely about performance and I know
it is possible.
I am sure throwing hardware at it is not the solution. Just trying to
highli
On Mon, Apr 18, 2011 at 8:39 AM, Claudio Freire wrote:
> Aside from a bug, that's the only reason I can think for a pg backend
> to bail out like that. Well, the connection could have been cut off by
> other means (ie: someone tripped on the cable or something), but lets
> not dwell on those optio
On Mon, Apr 18, 2011 at 7:14 AM, Phoenix Kiula wrote:
> # REINDEX INDEX new_idx_userid;
> server closed the connection unexpectedly
> This probably means the server terminated abnormally
> before or while processing the request.
> The connection to the server was lost. Attempting res
Btw, hardware is not an issue. My db has been working fine for a
while. Smaller poorer systems around the web run InnoDB databases. I
wouldn't touch that with a barge pole.
I have a hardware RAID controller, not "fake". It's a good quality
battery-backed 3Ware:
http://192.19.193.26/products/serial
Thanks for these suggestions.
I am beginning to wonder if the issue is deeper.
I set autovacuum to off, then turned off all the connections to the
database, and did a manual vacuum just to see how long it takes.
This was last night my time. I woke up this morning and it has still
not finished.
On Sun, Apr 17, 2011 at 10:59 AM, Phoenix wrote:
> TOP does not show much beyond "postmaster". How should I use TOP and
> what info can I give you? This is what it looks like:
We're basically looking to see if the postmaster process doing the
vacuuming or reindexing is stuck in a D state, which m
On April 17, 2011, Phoenix wrote:
> >> Surely this is not tenable for enterprise environments? I am on a
> >> 64bit RedHat server with dual CPU Intel Woodcrest or whatever that was
> >> called. Postgres is 8.2.9.
> >>
.. and you have essentially 1 disk drive. Your hardware is not sized for a
da
Thanks Scott.
I have shared huge amounts of info in my emails to Merlin and you.
Intentionally not shared in public. Apologies if you are feeling
tired.
The reason I need to REINDEX is because a simple SELECT query based on
the index column is taking ages. It used to take less than a second. I
wa
On Sun, Apr 17, 2011 at 9:44 AM, Scott Marlowe wrote:
> On Sun, Apr 17, 2011 at 9:30 AM, Phoenix Kiula
> wrote:
>> Sorry, rejuvenating a thread that was basically unanswered.
>>
>> I closed the database for any kinds of access to focus on maintenance
>> operations, killed all earlier processes s
>
>
> How do DB folks do this with small maintenance windows? This is for a
> very high traffic website so it's beginning to get embarrassing.
Normally there is no need to issue reindex. What's your reason for the need?
Jesper
>
On Sun, Apr 17, 2011 at 9:30 AM, Phoenix Kiula wrote:
> Sorry, rejuvenating a thread that was basically unanswered.
>
> I closed the database for any kinds of access to focus on maintenance
> operations, killed all earlier processes so that my maintenance is the
> only stuff going on.
>
> REINDEX
Sorry, rejuvenating a thread that was basically unanswered.
I closed the database for any kinds of access to focus on maintenance
operations, killed all earlier processes so that my maintenance is the
only stuff going on.
REINDEX is still taking 3 hours -- and it is still not finished!
Similarly
On Mon, Mar 21, 2011 at 8:14 PM, Phoenix Kiula wrote:
> Thanks Merlin, Scott.
>
> First, yes, I can increase maintenance_work_memory. I have 8GB RAM in
> total, and sure, I can dedicate 1GB of it to PG. Currently PG is the
> most intensive software here.
If we're talking maintenance work mem, the
On Fri, Mar 18, 2011 at 10:07 PM, Phoenix Kiula wrote:
> I have a large table but not as large as the kind of numbers that get
> discussed on this list. It has 125 million rows.
>
> REINDEXing the table takes half a day, and it's still not finished.
>
> To write this post I did "SELECT COUNT(*)",
Thanks Scott.
> What is the output of running vacuum verbose as a superuser (you can
> run it on the postgres database so it returns fast.)
Here's the output for postgres DB:
INFO: free space map contains 110614 pages in 33 relations
DETAIL: A total of 110464 page slots are in use (in
On Fri, Mar 18, 2011 at 9:07 PM, Phoenix Kiula wrote:
> autovacuum = on
> autovacuum_vacuum_cost_delay = 20
>
> vacuum_cost_delay = 20
> vacuum_cost_limit = 600
>
> autovacuum_naptime = 10
also, if vacuum can't keep up you can increase the vacuum
On Fri, Mar 18, 2011 at 9:07 PM, Phoenix Kiula wrote:
> I have a large table but not as large as the kind of numbers that get
> discussed on this list. It has 125 million rows.
>
> REINDEXing the table takes half a day, and it's still not finished.
>
> To write this post I did "SELECT COUNT(*)", a
I have a large table but not as large as the kind of numbers that get
discussed on this list. It has 125 million rows.
REINDEXing the table takes half a day, and it's still not finished.
To write this post I did "SELECT COUNT(*)", and here's the output -- so long!
select count(*) from links;
31 matches
Mail list logo
