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
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
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
I understood. Can you explain me what is registered in database after a
request information from SP and why the default installation not make
sense? The correct is, I install httpd, tomcat and postgres with my
optimizations?
2016-10-10 17:06 GMT-03:00 Konstantin Raskoshnyi :
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
wrote:
> Hi
> In my CentOS 7
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
On 10.10.2016 11:43 Morten A. Middelthon wrote:
On 05. okt. 2016 19:24, Lichtinger, Bernhard wrote:
Hi
I implemented workaround in spacewalk-repo-sync.
https://github.com/spacewalkproject/spacewalk/commit/47d82a693ac26a25970732c10aee8731eb92fe82
Patch works fine with spacewalk-2.5 with
On 05. okt. 2016 19:24, Lichtinger, Bernhard wrote:
Hi
I implemented workaround in spacewalk-repo-sync.
https://github.com/spacewalkproject/spacewalk/commit/47d82a693ac26a25970732c10aee8731eb92fe82
Patch works fine with spacewalk-2.5 with one modification:
Instead of
log(2, "Bugzilla