BES Consoles slow or hanging?

(imported topic written by BenKus)

This post is meant as a discussion starter specifically for questions regarding BES Console responsiveness. Specifically, using the console to do normal console operations (excluding loading times and propagation times which we can deal with in another thread).

The BES Console should generally run very quick and respond to your clicks without delay. As a general rule, the BES Consoles will need to be more powerful in terms of memory and CPU for the more computers you manage, but it should continue to respond well as you grow to the very large deployments. The reason the BES Console uses lots of memory is because it helps scalability (moving the work from the server computer to your local computer) and because all the information you could want about your computers is “at your fingertips”.

If you start to see the BES Console “hang” for a long time or run very slowly, usually it is because you don’t have enough memory for the BES Console. Here are some indicators that you are low on memory:

  1. BES Console is slow to do operations like sorting lists or opening new windows.

  2. Your task manager shows the “peak mem usage” significantly higher than “mem usage” for the BES Console process (indicating that the memory was swapped to disk because another application needed the memory.

  3. In the task manager under “Performance” > “Physical Memory” > “Available”, the memory is less than 20% of the “Total” memory.

  4. When the BES Console is hanging, your hard drive is “chugging” (indicating that memory has been “swapped” to disk).

To make things generally faster, here are a few “best practices”:

a. Lower your BES Console refresh rate – This can be changed under File > Preferences. If you are using the default (15 seconds) and don’t know what to set it to, try 60 seconds or higher.

b. Keep the number of open windows low – The BES Console is a “Multiple Document Interface Application” which means that it keeps windows open “behind” the newest window. Close these extra windows to increase speed of refreshes.

c. Add memory – Memory is cheap and never hurts (you can ask BigFix for an “official vendor recommendation” for more memory for your computer if you can’t get your request approved). Hopefully some BES users will post their stories about how adding memory changed their performance significantly.

d. Delete old unnecessary actions – Helps keep console memory usage lower.

Feel free to post console responsiveness issues here.

Ben

(imported comment written by Rolf.Wilhelm91)

Hi Ben,

My whole workstation is running much more quickly since I upgraded memory some weeks before while the BigFix Console is open.

Because I am forced to keep the action history for clients, I cannot simply delete all old actions, but I deleted old (expired and stopped) actions which never got a respond from a client during their lifetime.

The speed is now significantly higher.

Regards,

Rolf.

(imported comment written by SystemAdmin)

Hello,

I was wondering if there is a registry value that I can run a report against to find out what all my console operators have set their refresh rate to?

thanks,

Baraq

(imported comment written by arnaud91)

Hi bisbell,

you can create an analysis with following parameters:

analysis relevance: name of operating system as lowercase starts with “win” and exists regapp “besconsole.exe”

property name: BES Console Refresh Rate (or any name you prefer :-))

property relevance: value “Tree Refresh Timeout” of key “HKCU\Software\BigFix\enterprise console\preferences” of registry

Regards,

Arnaud

(imported comment written by SystemAdmin)

Cool, thanks. I’ll give it a shot.

Is there a way to allocate a specific amount of RAM for the console to use? Maybe a registry setting or a command line switch?

This thread is over ten years old, probably worth starting a new one; I’m not sure those on this thread would reply.

Which parts of the console would you want to not display when it runs out of memory? I don’t think there is a setting specifically to limit memory usage, we usually control performance through the cache policy onder File-Preferences, or by limiting the computer or site subscriptions for a given operator.

Long-term the answer is to move more people to WebUI if the console is not necessary for their workflow, but we don’t have full feature-parity between WebUI and Console yet.

1 Like

Sounds like a plan. I’ll open a new thread.

I wasn’t looking to limit the amount of memory, I was looking to ensure that there wasn’t a cap on memory to begin with and if so increase the memory it was able to allocate.

Thanks!
Mooney

Ah, I see.
I’m pretty sure there’s not a cap. On consoles I use with ~250k endpoints, I usually see 10-12 GB of RAM used by the console

1 Like

Thanks. We’re at about 65k and the console is using about 6GB