[Spacewalk-list] How to improve WUI performance

Matthew Madey mattmadey at gmail.com
Thu Oct 13 21:16:34 UTC 2016


I would also recommend upgrading to Spacewalk 2.4. I have a Spacewalk
environment with 8000 client systems, and clicking on systems would
eventually cause a timeout. This issue was fixed after upgrading to version
2.4.

On Thu, Oct 13, 2016 at 2:19 PM, Daryl Rose <darylrose at outlook.com> wrote:

> Jan-Albert,
>
>
> Thank you for the information, this and your previous reply.  Both very
> helpful.
>
>
> Daryl
>
>
> ------------------------------
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> on behalf of Ree, Jan-Albert van <J.A.v.Ree at marin.nl>
> *Sent:* Thursday, October 13, 2016 12:41 PM
>
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] How to improve WUI performance
>
>
> Pushing larger updates to ALL clients at once is a bad idea as soon as you
> go over 20-30 clients already...
>
>
> Our SW server (Scientific Linux 7, SW 2.5) is physical, with 64GB RAM. 6
> cores and a solid RAID drive set. As soon as I for instance update some
> software on one of our HPC clusters, as soon as I allow more than
> 20-25 clients to pull simultaneous I start getting tracebacks in my
> mailbox... specially if the updates become larger (new kernels, new nVidia
> CUDA suite, new LibreOffice)  I would try to move to
> CentOS/RHEL/ScientificLinux 7 for your new install, the later PostgreSQL
> version in it is a lot more efficient which helps speed up your SW
> instance.
>
>
> When I moved to a new server I didn't want to pull all the history (and
> some poor choices/mistakes from the past) so I set up a clean new server,
> with the proper channels/configs/packages and then on the old server
> selected batches of clients to which I pushed a script which registered
> them with the new server.
>
> This worked very well for us and allowed us to test and tweak the setup
> (it was during this phase on the new server that we noticed the OSAD issues
> and managed to solve it with moving to sqlite3) before moving to full
> production.
>
>
> What helped us debug/fix OSA issues was the script from post
> https://www.redhat.com/archives/spacewalk-list/2014-May/msg00124.html ;
> great to easily track which nodes are not working as expected.
>
> Regards,
>
> --
>
> Jan-Albert
>
>
>
> Jan-Albert van Ree | Linux System Administrator | MARIN Support Group
> MARIN | T +31 317 49 35 48 | J.A.v.Ree at marin.nl | www.marin.nl
>
> [image: LinkedIn] <https://www.linkedin.com/company/marin> [image:
> YouTube] <http://www.youtube.com/marinmultimedia> [image: Twitter]
> <https://twitter.com/MARIN_nieuws> [image: Facebook]
> <https://www.facebook.com/marin.wageningen>
> MARIN news: Software seminar in Shanghai for the first time
> <http://www.marin.nl/web/News/News-items/Software-seminar-in-Shanghai-for-the-first-time.htm>
>
> ------------------------------
> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces@
> redhat.com> on behalf of Konstantin Raskoshnyi <konrasko at gmail.com>
> *Sent:* Thursday, October 13, 2016 19:19
> *To:* spacewalk-list at redhat.com
> *Subject:* Re: [Spacewalk-list] How to improve WUI performance
>
> Hm..do you use osad? Just try to push updates for all of your clients and
> see what happens ;)
>
> On Thu, Oct 13, 2016 at 10:08 AM, Coffman, Anthony J <
> Tony.Coffman at snapon.com> wrote:
>
>>
>>
>> Spacewalk 2.5 (with 3 remote proxies)
>>
>> CentOS 6.8 VM (running stock Postgres 8.4)
>>
>> 4 vCPUs
>>
>> 12GB memory
>>
>>
>>
>> 550 clients (CentOS/OracleLinux/EL5/6/7 with a sprinkling of Ubuntu and
>> SuSE thrown in)A
>>
>>
>>
>> The System page in the WebUI loads in about 4-6 seconds (faster when the
>> cache is warm).
>>
>>
>>
>> I’ve done essentially no tuning except for changing the proxy timeout
>> (due to issue with the large updateinfo size for Oracle Linux).
>>
>>
>>
>> Looking at our memory utilization we could probably get away with 6-8GB
>> of memory for our workload.
>>
>>
>>
>> Hope this data point is useful.
>>
>>
>>
>> Regards,
>>
>> --Tony
>>
>>
>>
>>
>>
>>
>>
>> *From:* spacewalk-list-bounces at redhat.com [mailto:spacewalk-list-bounces
>> @redhat.com] *On Behalf Of *Daryl Rose
>> *Sent:* Thursday, October 13, 2016 12:25 PM
>> *To:* spacewalk-list at redhat.com
>> *Subject:* Re: [Spacewalk-list] How to improve WUI performance
>>
>>
>>
>> I am actually leaning to moving to a physical server.  I have a server in
>> the closet that is dual CPU, 8 core, 64GB of RAM.  I was originally
>> thinking that it was a bit of over kill, but after reading this reply,
>> perhaps its sized correctly.
>>
>>
>>
>> If I do move to a physical, can I migrate everything from the original SW
>> server to the replacement server?  Can I export the database and import it
>> over?  Migrate repositories over?  I am using a signed certificates, and I
>> would like to continue using the same machine name and configuration.  Do I
>> have to re-register these servers?  Its taken me a while to get 465 added
>> in, and I don't want to have to re-register everything, especially since I
>> continue adding on a daily bases.
>>
>>
>>
>> Thanks
>>
>>
>>
>> Daryl
>>
>>
>> ------------------------------
>>
>> *From:* spacewalk-list-bounces at redhat.com <spacewalk-list-bounces at redhat
>> .com> on behalf of Konstantin Raskoshnyi <konrasko at gmail.com>
>> *Sent:* Thursday, October 13, 2016 10:43 AM
>> *To:* spacewalk-list at redhat.com
>> *Subject:* Re: [Spacewalk-list] How to improve WUI performance
>>
>>
>>
>> You need bare metal high performance machine.
>>
>> We have 400 machines and use xeon7 24cores with 64 of ram.
>>
>> Plus tuning: Postgres, Linux, tomcat
>>
>> On Thursday, October 13, 2016, Daryl Rose <darylrose at outlook.com> wrote:
>>
>> I have 465 servers in my SW environment, and I keep adding more
>> everyday.  When finished, I'll have nearly a thousand servers in the
>> environment.
>>
>>
>>
>> My SW server is a virtual RHEL 6.6, SW v2.3.  I have four CPU's and four
>> Gigs of memory allocated to the server.
>>
>>
>>
>> Whenever I select "Systems" from the main menu a single CPU pegs at 100%,
>> and it takes several minutes for the page to come up.  It appears that
>> osa-dispatcher is what is using up the CPU.  osa-dispatcher is often at 99
>> to 100%.
>>
>>
>>
>> Is there  a way to performance tune SW?  Can I configure SW to use all
>> four CPU's, or should I add additional CPU's, can configure SW to use all
>> assigned CPU's?
>>
>>
>>
>> Thanks
>>
>>
>>
>> Daryl
>>
>>
>> _______________________________________________
>> Spacewalk-list mailing list
>> Spacewalk-list at redhat.com
>> https://www.redhat.com/mailman/listinfo/spacewalk-list
>> <https://portal.marin.nl/mailman/listinfo/,DanaInfo=www.redhat.com,SSL+spacewalk-list>
>>
>
>
> _______________________________________________
> Spacewalk-list mailing list
> Spacewalk-list at redhat.com
> https://www.redhat.com/mailman/listinfo/spacewalk-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161013/5c4b74d8/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imagec70e4d.PNG
Type: image/png
Size: 331 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161013/5c4b74d8/attachment.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image7fd843.PNG
Type: image/png
Size: 253 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161013/5c4b74d8/attachment-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageacccc5.PNG
Type: image/png
Size: 333 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161013/5c4b74d8/attachment-0002.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: imageabcd9b.PNG
Type: image/png
Size: 293 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/spacewalk-list/attachments/20161013/5c4b74d8/attachment-0003.png>


More information about the Spacewalk-list mailing list