Hi all,

I installed OpenACS 4.6.1 final on a RedHat 8.0 and Postgresql 7.2.3 following the directives of the installation instructions.

All is running fine except the groups management programs wich are very very slow. Particularly bad are /admin/group-types/one?group_type=group and /admin/relations-add

The relations-add program is so slow, both adding composition and membership relations, that I can't even complete its execution remotely because it times out.

I am under big pressure because I should setup a working server with a dozen of groups and about 150 members by next Friday and so any advice is very welcome.

TIA

Thank you Jeff, now it works!

This is my first installation with postgres 7.2.3 and I never observed a similar difference in performance with 7.1 : do you suggest running vacuumdb dayly?

As a side note this is also my first installation from source (I always used Jonathan's RPM) and another oddity is that when doing

ps -ef | grep nsd

I was used to see several threads, while now I see only one nsd process. Is this normal?

Thank You again,
Claudio

Claudio,

VACUUMing your database is *crucial* to performance. It needs to be done at least once daily, and several times a day if your database receives lots of updates, inserts or deletes.

Please read the PostgreSQL Administrator's Guide and famialirize yourself with what it takes to maintain a PostgreSQL server.

Also, you're probably running with PostgreSQL defaults, which are very conservative. If you have a more modern machine, you could up those defaults and get much better performance. Search google for "postgresql performance".

-Roberto

Thank You all for your advice.

You bet I learned the vacuum lesson, but the fact is that I'm running several servers (with postgresql 7.1 and oacs 3.x) wich perform at lightning speed even if I run vacuum analyze only when I remember to do so.

One argument I have always used in favor of PostgreSQL against Oracle was that it didn't require me to spend more than one hour per year in DB tuning: it seems that combining oacs.4.x with PostgreSQL 7.2.x will require more, but oacs.4.x is so rewarding to fully justify these complications.