Upgraded our UMS from 6.01.130 to 6.03.130 and are seeing a significant performance issue in the UMS console

Hi everyone! We recently upgraded our UMS from 6.01.130 to 6.03.130 and are seeing a significant performance issue in the UMS console. When clicking on directories or devices, it spins for several seconds (sometimes 10-15 seconds) before loading. We are running on embedded DB and have roughly 5200 devices, most using ICG (which is why we upgraded, to resolve disconnection issues). Server is Windows Server 2016. We have plenty of free space on the drive used by UMS, 16gb ram and 8 cores. Anyone else experience this issue? Thank you!

Learn more, read the entire thread inside the IGEL Community o Slack

How does it look under UMS Administration > UMS Network > Server > <server_name> ?

This is what it currently looks like. Thank you for the quick reply!

That’s interesting – it should be performing better on 6.03 due to the following changes:

Changed: Increased the maximum memory usage of UMS Console (1024mb -> 3072mb), UMS Server (2048mb -> 4096mb) and RM Admin (512mb -> 1024mb)

Changed: Redesign of the UMS Cache. The cache is now always switched on. The corresponding configuration dialogs were removed.

Is that a physical machine with 8 cores or a VM with 8 vCPU? If it’s the latter, I would bump that down to 4 – counterintuitively, that can cause contention on your Hypervisor

@member can you try to disable the Antivirus (if present), reboot the service IgelRmGuiServer and check if the problem persists?

If yes, open the rmadmin.exe (UMS Administrator), go to Datasource, click optimize Database. After that, disable the DB connection and reactivate it (you will the main UMS Password).

Oh, and just for testing… Can you disable online check and see if it performs better?

kb.igel.com/endpointmgmt-6.03/en/online-check-22462458.html kb.igel.com/endpointmgmt-6.03/en/online-check-22462458.html

Last one: does it happen also when opening the console on the server itself or if the console is started remotely like from your client?

Just a question for @member, would 5200 devices call for considering a move to an external database?

It would be one of the (last) recommendations , yes @member

I still see enterprise customers with 10K endpoints using the embedded DB so we have to do some benchmark job for a clearer sizing recommendation

It depends on a bunch of different factors as @member said, but 3000+ is when I would begin to consider another UMS server for load balancing purposes (which requires an external DB 🙂)

I’m overwhelmed (in a good way) with the responses! I’ll take a look at lowering the cores back to 4 and disable AV to see if it makes a difference. One thing to note is, I have a few ums users who are using AD access, seeing more performance issues than those with local accounts in ums. I’ll let you know what I find

AD on the same LAN as UMS?

Yes sir. I just logged into a local UMS account and I’m experiencing the same lag there as well. Searches within UMS are also extremely slow, sometimes locking up the console

@member Looks like I’ve isolated it to any secondary account. Local or AD accounts experience the lag. Using admin (DB) it works flawlessly

Did you checked the DB Optimization, AV also? Or is it still in the testing queue?

We optimized the DB before upgrading, should we do it again? AV was just disabled so I’ll test and reply. If the DB admin account works flawlessly remotely and on the server, would this still be an optimization issue?

No, definitely not but I‘m still seeing strange issues when the DB isn‘t in a right state.

You could gather Logs and look into the catalina.log to have a first impression of the root cause

Help, Save Support Informations

Saving the logs now. I do have a ticket in with support but have not heard from anyone regarding it. I noticed when I log into UMS with a local ad account, the server cpu spikes. CPU usage is coming from the DB process.

You could also check then if all DCs listed are online, and healthy😁

UMS Administration, Active Directory, Edit your connection, Click Resolve and see if they are maybe „Walking Dead“ Server🙏

Just checked the DC’s and they all look fine, the thing is, locally created, non-AD accounts, inside of UMS experience the same issue as well. The only account working great is the DB admin account.:thinking_face:

Could you, just for fun create a

• local group

• a new user

• add both the new user and an existing but slow one to the group

• Give the group full access to almost everything

and see if the result varies? Sorry, on the road atm. cannot test by myself.

Ok did all of the above. Created a test group with full access to UMS server, created a test user, placed user inside of the test group, placed an existing user in it as well. Logged in with brand new user and still experience the same issue. 🙁

Weird… Sorry, no more ideas beside hope that the Logs will reveal something.

Whatever issue it was, it was resolved via the 6.04.100 UMS update.

Continue reading and comment on the thread ‘Upgraded our UMS from 6.01.130 to 6.03.130 and are seeing a significant performance issue in the UMS console’.  Not a member? Join Here!

Learn more, search the IGEL Knowledge Base

Ask a question or comment on the above message thread?

Join or log in to the IGEL Community to ask us anything and meet other IGEL customers, partners, and EUC enthusiasts.

Submit a question, or Join Today!

Popular Message Threads

Categories & Tags: