Are you running monitoring in spacewalk. If so that may be the culprit its a known issue in spacewalk 1.7 with postgresql. You can use pgpool (connectoin pooling proxy) to consolidate and reuse the connections, but due to an other know bug in 1.7 you would have to change the port postgresql listens on and put pgpool on that postgresqls port instead. You also may want to try doing an analyze if there have been a lot of changes in the database so its planner statistics become more acurate. And as always with postgresql its best to plan to do a full vaccum analyze on a regular basis. While the auto vacuum introduced in the 8 series reduces the need for it, it doesn't completely eliminate it. <div class="gmail_quote">On Aug 17, 2012 9:12 AM, "Jonathan Scott" <<a href="mailto:lists@xistenz.org">lists@xistenz.org</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Good Morning All, I've started having some rather odd issues with my Spacewalk install using postgres. Every night, we do an errata load which typically consists of a handful of RPMs if anything at all, but recently (and for no apparent reason) the database has just started slowing down. This is causing everything on the system to back up; when I checked this morning, there were 542 postgres processes in various states (idle, idle in transmission, UPDATE waiting [which concerns me the most]), and 258 httpd processes. Restarting the database seems to clear the issue up, but I cannot find anything specific in the logs to tell me what is going on here. There are no traceback emails or other forms of alerting coming from the application. Any insight? Thanks! Jonathan _______________________________________________ Spacewalk-list mailing list <a href="mailto:Spacewalk-list@redhat.com">Spacewalk-list@redhat.com</a> <a href="https://www.redhat.com/mailman/listinfo/spacewalk-list" target="_blank">https://www.redhat.com/mailman/listinfo/spacewalk-list</a> </blockquote></div>