Here’s a nice tip that can help you eek out a bit more performance from your Orion® server. The following approach is used in some larger environments to resolve out-of-memory issues experienced by the Orion Module Engine. However, it’s also safe in environments where there is spare RAM that the service might use.

 

How to apply the change

Previously, the change involved editing a configuration file directly. However, the latest versions of Orion Core   have made this process much simpler. Navigate to one of the two URLS below (the global option will be the one to run, unless there is a specific reason not to). This will set the change on not only the main Orion server, but also on all the additional polling engines.

 

The advanced configuration settings editor pages are hidden and can be accessed via link:

    • {OrionWebsite}/Orion/Admin/AdvancedConfiguration/Global.aspx - leads to “Global” tab
    • {OrionWebsite}/Orion/Admin/AdvancedConfiguration/ServerSpecific.aspx - leads to “Server-Specific” tab
  • Find ForcePluginsInSeparateProcess under SolarWinds.BusinessLayerHost.BusinessLayerHostSettings
  • Set ForcePluginsInSeparateProcess to have a “tick”

 

Business Layer Host Settings.jpg

 

You will then be prompted to restart the Orion Module Engine. This is safe to do, and should not affect any customer experience in the console.

 

What exactly does the change do?

The Orion Module Engine loads numerous different plugins when it runs (Examples: Orion, NPM, Interfaces, UnDP, VIM, Wireless, SAM, UDT, NCM, etc.). Since 32-bit executables start to run out of memory close to 1GB of RAM, a single plug-in running in the service can act as bottle for the others. The changes mentioned above simply allow each individual plug-in to run in its own process. So, not only does this simplify troubleshooting in some support issues, but it also has the bonus of improving performance in perfectly healthy machines.

 

And how do you know it works?

• Open Task Manager -> View-> Add Columns -> Add "Command Line"

You can then see how much CPU and memory each one instance of the business layer uses!

 

Disclaimer: While this change can be considered safe and extremely low-risk to deploy, as always, every change to a production system should be first thoroughly tested, and steps should be taken to allow roll-back if things go awry.