Josh Berkus wrote:
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
--
Command Prompt, Inc., home of Mammoth PostgreSQL - S/ODBC and S/JDBC
Postgresql support, programming
"[EMAIL PROTECTED]" <[EMAIL PROTECTED]> writes:
> in March there was an interesting discussion on the list with the
> subject "postgres eating CPU on HP9000".
>http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
Reviewing that, the problem is most likely that (a) they didn't
> >>in March there was an interesting discussion on the list with the
> >>subject "postgres eating CPU on HP9000".
Aha, this one. Yeah, I believe that they upgraded to 7.4 inorder to deal
with REINDEX issues.
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
Josh Berkus wrote:
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
Link, please?
http://archives.postgresql.org/pgsql-performance/2004-03/msg00380.php
---(end of broadcast)---
TIP
> in March there was an interesting discussion on the list with the
> subject "postgres eating CPU on HP9000".
Link, please?
--
--Josh
Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 6: Have you searched our list
Hi,
in March there was an interesting discussion on the list with the
subject "postgres eating CPU on HP9000".
Now I'm the same problem on a Dell dual processor machine.
Anybody know if there was a solution?
Thanks
Piergiorgio
---(end of broadcast)-
Fabio,
> The Vacuum's don't take too long, 10 minutes at most. I can tell from ps
> -ef | grep and top that its the selects/inserts/updates from the postgres
> related to our app that take all that time up. If we rerun initdb and
> reload the data, it works great for about two days, then goes ba
The Vacuum's don't take too long, 10 minutes at most. I can tell from ps
-ef | grep and top that its the selects/inserts/updates from the postgres
related to our app that take all that time up. If we rerun initdb and
reload the data, it works great for about two days, then goes bad again.
We a
Fabio,
> We run VACUUM ANALYZE after we remove about 1000 rows every hour on the
> halh hour. Our max_fsm_pages is set to 1
Have you checked how long these vacuums take? If they are starting to
overlap, that would explain your high CPU usage and poor performance.You
might want to con
On Mon, Mar 29, 2004 at 12:00:16 -0500,
Fabio Esposito <[EMAIL PROTECTED]> wrote:
>
> I'm sorry all, when you say regular user as opposed to superuser are you
> talking about the user that postgres is installed and running as? Should
> this be done as the os's root?
The os user used for creati
On Mar 29, 2004, at 9:36 AM, Tom Lane wrote:
"Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
Also do you run VACUUM ANALYZE as a superuser, or as a regular user?
As a regular user (database owner). Is thery any difference when
vacuuming
as a super user?
That's your problem. A regular u
I'm sorry all, when you say regular user as opposed to superuser are you
talking about the user that postgres is installed and running as? Should
this be done as the os's root?
Fabio
On Mon, 29 Mar 2004, Tom Lane wrote:
> "Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
> >> Also do yo
"Marcus Andree S. Magalhaes" <[EMAIL PROTECTED]> writes:
>> Also do you run VACUUM ANALYZE as a superuser, or as a regular user?
> As a regular user (database owner). Is thery any difference when vacuuming
> as a super user?
That's your problem. A regular user won't have permissions to vacuum
an
On Fri, 26 Mar 2004, Josh Berkus wrote:
> Fabio,
>
> > Recently it started eating up the cpu, and cannot keepup with the system
> > like it used to. The interesting thing here is that it still runs great
> > on an older system with less ram, one slower cpu, and an older disk.
>
> This really p
> Marcus,
>
>> We are experiencing exactly the same problem here, and we use 7.4 on
>> Linux/i386 SMP (2 processors). Our databases does even more access:
>> about 30k selects per hour, 10k updates and inserts per hour
>>
>> Vacuum analyze is done daily.
>
> What is your max_fsm_pages setting?
Marcus,
> We are experiencing exactly the same problem here, and we use 7.4 on
> Linux/i386 SMP (2 processors). Our databases does even more access:
> about 30k selects per hour, 10k updates and inserts per hour
>
> Vacuum analyze is done daily.
What is your max_fsm_pages setting? If you are
We are experiencing exactly the same problem here, and we use 7.4 on
Linux/i386 SMP (2 processors). Our databases does even more access:
about 30k selects per hour, 10k updates and inserts per hour
Vacuum analyze is done daily.
We migrated our database to a new server. Initially, everything was
Fabio Esposito <[EMAIL PROTECTED]> writes:
> We've recently integrated postgres into an existing mature app. Its a
> time sensitive 24x7 system. It runs on HP9000, a K370 Dual Processor
> system. Postgres is version 7.3.2. Its spawned as a child from a parent
> supervisory process, and they com
Fabio Esposito <[EMAIL PROTECTED]> writes:
>> Did you start from a fresh initdb, or just drop and recreate user
>> tables? I'm wondering about index bloat on the system tables ...
> I don't think I re initdb it, just dropped. We did try a reindex command
> in the interactive editor, with no succ
On Tue, 23 Mar 2004, Fabio Esposito wrote:
>
> Hello fellow PostgreSQL users.
>
> We've been working on this interesting issue for some time now, and we're
> hoping that someone can help.
>
> We've recently integrated postgres into an existing mature app. Its a
> time sensitive 24x7 system. I
Fabio,
> I'll have to get back to you on that, but I'm 90% sure its the default out
> of the box.
Raise it, a lot. Perhaps to 30,000 or 50,000. VACUUM VERBOSE ANALYZE
should show you how many data pages are being reclaimed between vacuums.
Because of your very high rate of updates and delet
On Fri, 26 Mar 2004, Fabio Esposito wrote:
>
> On Fri, 26 Mar 2004, scott.marlowe wrote:
>
> > > It maintains 48hours of data, so its not a large database; roughly
> > > <600mbs. We do this by running a housekeeping program in a cron job.
> > > It deletes all data older then 48hours, then vaccu
Fabio,
> Postgres initially worked wonderfully, fast and solid. It
> preformed complex joins in 0.01secs, and was able to keep up with our
> message queue. It stayed this way for almost a year during our
> development.
>
> Recently it started eating up the cpu, and cannot keepup with the system
Hello fellow PostgreSQL users.
We've been working on this interesting issue for some time now, and we're
hoping that someone can help.
We've recently integrated postgres into an existing mature app. Its a
time sensitive 24x7 system. It runs on HP9000, a K370 Dual Processor
system. Postgres is
24 matches
Mail list logo
