We have about 6,000 systems to manage and it was unusable otherwise... I had way too much trouble trying to get OSAD to work through proxies and F5 load balancers, so I had to end up pointing them all to two masters that are still using the same Postgres database VM. I was also toying with having the database be the back end for OSAD, so with that in mind the number of concurrent clients would often reach higher than usual numbers... I tried a lot of different things to get Spacewalk stable, usable, and have proper failover, so I don't know that any of my recommendations or environment specific settings might be a silver bullet for anyone else, but it can't hurt to try, and learn in the process.
On Mon, Oct 10, 2016 at 6:23 PM Paul Robert Marino <prmari...@gmail.com> wrote: > tuning for 5000 clients is nuts that would hurt your performance > try running pgtune for about 50 to maybe 500 clients max, but I try > the lower setting first. > Now lets talk about the high IO that usually happens when you don't > have enough working memory in PostgreSQL's configuration. When that > happens PostgreSQL creates temp files that are slow and do a lot of > write IO during read operations because it will have to swap the data > out to the temp files, note setting the number of connections too high > would exacerbate that issue f its the root cause. > By the way I managed up to 400 with spacewalk and never had to disable > the snapshots. > > > On Mon, Oct 10, 2016 at 4:48 PM, Matt Moldvan <m...@moldvan.com> wrote: > > I had similar issues and ended up first breaking out the database to it's > > own VM, then increasing the Postgres debug logs. I saw that there were a > > large number of operations running against the snapshot tables, with > locks > > and so on being set for a long period of time. In /etc/rhn/rhn.conf, try > > disabling snapshots with: > > > > enable_snapshots = 0 > > > > I also did quite a bit of Postgres tuning using pgtune, for 5,000 > clients or > > so: > > pgtune -i data/postgresql.conf -o ./data/postgresql.conf.new -c 5000 > > > > Another thing that may help is installing pgbadger to analyze your > Postgres > > logs... it has some nice visualizations of the types of queries and > tables > > involved, which may point you in the right direction if snapshots aren't > the > > reason for the high utilization. > > https://github.com/dalibo/pgbadger > > > > Hope that helps. > > > > On Mon, Oct 10, 2016 at 4:06 PM Konstantin Raskoshnyi < > konra...@gmail.com> > > wrote: > >> > >> Because all your systems request information from SP, and default > >> installation doesn't make any sense if you have more that 50 machines, > so > >> you need to tyne postgres, tomcat & linux itself > >> > >> On Mon, Oct 10, 2016 at 12:34 PM, Allan Moraes < > al...@allanmoraes.com.br> > >> wrote: > >>> > >>> Hi > >>> In my CentOS 7 server, is installed the spacewalk 2.4 and PostgreSQL > from > >>> default installation. Via iotop, my postgresql write a lot of > informations, > >>> during all day. Why this occur? > >>> > >>> _______________________________________________ > >>> Spacewalk-list mailing list > >>> Spacewalk-list@redhat.com > >>> https://www.redhat.com/mailman/listinfo/spacewalk-list > >> > >> > >> _______________________________________________ > >> Spacewalk-list mailing list > >> Spacewalk-list@redhat.com > >> https://www.redhat.com/mailman/listinfo/spacewalk-list > > > > > > _______________________________________________ > > Spacewalk-list mailing list > > Spacewalk-list@redhat.com > > https://www.redhat.com/mailman/listinfo/spacewalk-list > > _______________________________________________ > Spacewalk-list mailing list > Spacewalk-list@redhat.com > https://www.redhat.com/mailman/listinfo/spacewalk-list >
_______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list