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 <m...@moldvan.com>: > 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 > -- Atenciosamente... *Allan Moraes* *- Linux Consulting at Venda e Cia <http://vendaecia.com/>* *- Founder and Editor at MySQL Box <http://www.mysqlbox.com.br/>* *- Linux System Administrador and DBA MySQL at Umbler <https://www.umbler.com/>* *Cel: (51) 81885480* *E-mail: al...@mysqlbox.com.br <al...@mysqlbox.com.br>* *Skype: al...@allanmoraes.com.br <al...@allanmoraes.com.br>*
_______________________________________________ Spacewalk-list mailing list Spacewalk-list@redhat.com https://www.redhat.com/mailman/listinfo/spacewalk-list