Thanks! You were right. The database needed some tuning. I used pgtune
and applied the suggested changes. Now the DELETE only takes 27s instead
of 8h. The plan also looks very different. Now it's actually using the
rhn_pkg_clr_cld_uq index unlike before:
spacewalk=# explain analyze verbose
Well I'm running PostgreSQL 9.x on all of my database servers so my
plan looks way different than your for instance my servers don't need
to do all of those sorts, so its not a viable comparison. that said
the numbers are nothing like yours my servers chomp through that query
reasonably quickly.
vacuum analyze is the first thing I do when I see problems on a
postgresql database...
The database is running on the spacewalk server but it doesn't show too
much load at any time nor is it slow on the disks.
The estimate of explain verbose don't look too promising to me.
What do you get for
looks like your database isn't tuned correctly or you desperately need
to run a vacuum analyze on it.
check your disks too.
This is most likely a problem with your database servers,
configuration, maintenance, or hardware.
On Mon, Jun 8, 2015 at 11:07 AM, Gerald Vogt v...@spamcop.net wrote:
Does anyone have an idea what I could do about this?
Does anyone see something similar?
Thanks,
Gerald
On 28.05.15 06:57, Gerald Vogt wrote:
Eventually cleanup-data-bunch finished after 8:40 h. Definitively not
suitable to run daily.
I don't quite understand why the query runs with two
Hi!
It seems cleanup-data-bunch takes a very long time.
I have noticed that it was in state INTERRUPTED and did not run for a
couple of months. I have applied the changes as suggested in
https://www.redhat.com/archives/spacewalk-list/2015-May/msg00091.html
and now cleanup-data-bunch does run
Eventually cleanup-data-bunch finished after 8:40 h. Definitively not
suitable to run daily.
I don't quite understand why the query runs with two sequential scans
and does not use the indexes.
Does anyone have an idea how to optimize that? Is that always taking so
long? I am using CentOS 6.6,
