The primary question is to figure out, what resources are running out. Candidates
- cpu
- amount of memory
- memory bandwidth
- i/o
and who is causing it
- aolserver (e.g. lock-contention)
- postgres (e.g. checkpoint handling, vacuuming,
some complex queries...)
is the whole machine in a bad state (e.g.
load etc. how does it react on the console)
or just the aolserver or the database?
how many cpus do you have on your system
(fgrep processor /proc/cpuinfo)?
In respone to your questions:
- i have never seen thread destroy as a
performance problem, but under "normal
conditions", not all threads end
at more or less the same time.
Normally, the problem with the thread
destroys is just that they might be
created quite soon later, thread
creation is slow, when the blueprint
is large (when you have many packages
installed). However, if one has a large
blueprint, the thread cleanup has to
free all of the contents, which
might be a couple of million individual
free operations. This might entail
as well quite a large number of
memory locks.
- there are as well many reasons
for possible waiting operations.
Do you see error message concerning
DEADLOCKS in you database? OpenACS
5.4 uses less locks (which were introduced
to overcome some problems in PostgreSQL
8.0 and 8.1).
-gustaf neumann
