1 Introduction

This instruction concerns alarm handling for the SAF, LOTC Memory Usage Failed alarm.

1.1 Alarm Description

This alarm is related to Service Availability Forum (SAF).

The alarm is issued when the memory usage exceeds a defined threshold. The threshold level is configured to 90% for the System Controllers (SCs), and 93% for the payload blades or Virtual Machines (VMs).

The possible alarm causes and the corresponding fault reasons, fault locations, and impacts are described in Table 1.

Table 1 Alarm Causes
Alarm Cause	Description	Fault Reason	Fault Location	Impact
Memory occupation is above 90% on an SC.	Overload on an SC.	Heavy memory consumption processes running on an SC.	SC	Risk of service degradation or SC restart.
Memory occupation is above 90% on an SC.	Memory leak on an SC.	A process could be leaking memory resources on an SC.	SC	Risk of service degradation or SC restart.
Memory occupation is above 93% on a payload blade or VM.	Overload on a payload blade or VM.	Heavy memory consumption processes running on a payload blade or VM.	Payload blade or VM	Risk of service degradation or payload blade or VM restart.
Memory occupation is above 93% on a payload blade or VM.	Memory leak on a payload blade or VM.	A process could be leaking memory resources on a payload blade or VM.	Payload blade or VM	Risk of service degradation or payload blade or VM restart.

The alarm attributes are listed and explained in Table 2:

Table 2 Alarm Attributes
Attribute Name	Attribute Value
Auto Cease	`Yes`
Module	`SAF`
Error Code	`8`
Timestamp First	Date and time when the alarm was raised for the first time.
Repeated Counter	Number which indicates how many times the alarm was raised.
Timestamp Last	Date and time of the most recent alarm raised.
Resource ID	`.1.3.6.1.4.1.193.169.9.8.` `<length>` `.` `<NOI>`
Alarm Model Description	`LOTC memory usage, SAF`
Alarm Active Description	`SAF platform: LOTC memory usage @` `<NON>`
ITU Alarm Event Type	`processingErrorAlarm (4)`
ITU Alarm Probable Cause	`outOfMemory (162)`
ITU Alarm Perceived Severity	`(4) – Major`
Originating Source IP	Node where the alarm was raised.
Sequence Number	Number which indicates the order in which alarms were raised.

In Table 2, the indicated variables are as follows:

<NON> is the notifying object name that indicates where the component that generates the alarm is. For example:

safNode=PL_2_3
<NOI> is the notifying object identifier. It corresponds to <NON> in a dot-separated, ASCII-decimal-encoded, character-per-character format. For example:

80.76.95.50.95.51 for PL_2_3
<length> is the number of characters in <NON> , which is equivalent to the number of octets in <NOI> . In the previous example, <length> is 6.

For further information about attribute descriptions, refer to CUDB Node Fault Management Configuration Guide.

1.2 Prerequisites

This section provides information on the documents, tools, and conditions that apply to the procedure.

1.2.1 Documents

This instruction references the following document:

CUDB Node Fault Management Configuration Guide

1.2.2 Tools

Not applicable.

1.2.3 Conditions

Not applicable.

2 Procedure

If the alarm is raised, do the following:

Steps

Check if any extraordinary process is running that could generate extra memory usage.
If the alarm does not cease, contact the next level of maintenance support. Further actions are outside the scope of this Operating Instruction.

Copyright	© Ericsson AB 2016-2018. All rights reserved. No part of this document may be reproduced in any form without the written permission of the copyright owner.
Disclaimer	The contents of this document are subject to revision without notice due to continued progress in methodology, design and manufacturing. Ericsson shall have no liability for any error or damage of any kind resulting from the use of this document.
Trademarks	All trademarks mentioned herein are the property of their respective owners. These are shown in the document Trademark Information.