Submit a ticketCall us

WebinarUpcoming Webinar: Should I Move My Database to the Cloud?

So you’ve been running an on-premises SQL Server® for a while now. Maybe you’ve moved it from bare metal to a VM, and have seen some positive benefits. But, do you want to see more? If you said “YES!”, then this session is for you, as James Serra will review the many benefits that can be gained by moving your on-prem SQL Server to an Azure® VM (IaaS). He’ll also talk about the many hybrid approaches, so you can gradually move to the cloud. If you are interested in cost savings, additional features, ease of use, quick scaling, improved reliability, and ending the days of upgrading hardware, this is the session for you.

Register now.

Home > Success Center > VoIP & Network Quality Manager (VNQM) > VNQM - Knowledgebase Articles > VNQM restarting module engine service due to out of memory error

VNQM restarting module engine service due to out of memory error

Created by Matthew Lamb, last modified by MindTouch on Jun 23, 2016

Views: 783 Votes: 0 Revisions: 9

Overview

This article describes an issue that can occur with the Orion Module Engine Service restarting due to the VNQM module crashing from an out of memory exception error.

The following error message is seen in the BusinessLayerHost.log:

ERROR SolarWinds.BusinessLayerHost.PlugInstanceSeparateProcess - Instance C:\Program Files (x86)\SolarWInds\Orion\VoIP

Monitor\SolarWinds.Orion.IpSla.NusinessLayer.dll.congif - ProcessID:9468 doesn't exists anymore

ERROR SolarWinds.Common.Ultility.ScheduledTask - CheckPlugins threw and exception.

System.InvalidOperationException: Instance C:\Program Files (x86)\SolarWins\Orion\VoIP Monitor\SolarWinds.Orion.IpSla.BusinessLayer.dll.config

Environment

VNQM 4.2 and later

Cause 

This is due specifically when an Avaya Call Manager environment is configured to send its call records (CDR) and its call metric information (RTCP) to the VNQM server, but the Call Manager was never added into VNQM or was removed.

What happens is the VNQM collector is still receiving the CDR\RTCP data, but has nowhere to place the data. Such data is normally dropped and not collected, but excessive amounts of data arriving to the VNQM server causes the data to be loaded into the memory allocated for VNQM through the Orion Module Engine service until it can be parsed through and compared against the database. Eventually, that amount of data is going to exceed the limits in place for the module's usage and causes it to run out of memory. At that point, the module crashes resulting in the Orion module engine service restarting in an attempt to restart the VNQM module.

Last modified

Tags

Classifications

Public