Re: [Spacewalk-list] Spacewalk - PostgreSQL High I/O

2016-10-11 Thread Allan Moraes
Thank you for the tips, In this case there is available 6GB of memory and the high I/O occur at the postgres disk. Other disks, the I/O is normal. The system not is using swap and there is 3GB of swap. I will separate the postgre and apply your tips. 2016-10-10 21:58 GMT-03:00 Matt Moldvan

Re: [Spacewalk-list] Unable to sync Red Hat errata incorrect metadata

2016-10-11 Thread Morten Middelthon
On 10 Oct 2016, at 17:33, Jan Dobes wrote: > > On 10.10.2016 11:43 Morten A. Middelthon wrote: >> >> Has anyone gone through the trouble of applying the patch on Spacewalk >> 2.2? My Spacewalk server is unfortunately running RHEL 5, which means >> I'm can't upgrade past

Re: [Spacewalk-list] Spacewalk - PostgreSQL High I/O

2016-10-11 Thread Matt Moldvan
Yeah, it was quite a trial to get it to scale to that degree, so I tried a lot of different things. I increased the max_fds in the jabber configs and the ulimits for the jabber user and it's pretty stable now, though even the back end Python code wasn't written for having multiple osa dispatchers

Re: [Spacewalk-list] Spacewalk - PostgreSQL High I/O

2016-10-11 Thread Paul Robert Marino
Matt You may consider using multiple PostgreSQL replica servers in HOT mode servers with pgpool in front of them it may help but a little. but because of te way spacewalk does its queries I doubt it will help much as the safties in pgpool will think just about every query may write and send it to

Re: [Spacewalk-list] Spacewalk - PostgreSQL High I/O

2016-10-11 Thread Matt Moldvan
Well for a smaller number of clients (<500-1,000) separating out the database might be more work than it's worth (though good experience). First step I would say is to take a look at increasing the logging in Postgres to get an idea where the slowness is occurring. Also, something like atop or