No relevant resource is found in the selected language.

This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Search

Reminder

To have a better experience, please upgrade your IE browser.

upgrade
Knowledge Base

High CPU usage after U2000 upgrade

Publication Date:  2018-10-23  |   Views:  415  |   Downloads:  0  |   Author:  v84083080  |   Document ID:  EKB1001938255

Contents

Issue Description

We upgraded our U2000-Server from version V200R016C60SPC200 to V200R016C60CP2023

There is a system task, which uses 50% of all 16 vcores.


The name of the process is BulkCollectorDM. I think it’s not normal, because it’s running for days now.

 

Solution


[Root Cause]Inconsistency exists between the content of multiple dynamic libraries of the BulkCollectorDm_1 process. This produce an automatic restart of the BulkCollectorDm_1 process.

[Solution]

Step 1      Install the following U2000 patch:


·       U2000 V200R016C60 CP2025 (for U2000 V200R016C60CP2023)

Step 2      Delete the core file core.BulkCollectorDm* generated by the BulkCollectorDm_1 process. The asterisk (*) indicates that the file contains a file name extension and is uniformly identified. This operation frees up disk space.

On Solaris, assume that the installation directory is /opt/oss. Run the following commands as the ossuser user to delete the core file:
cd /opt/oss/server/var/logs
rm -rf core.BulkCollectorDm*

On Windows, manually delete the core.BulkCollectorDm* file. If the installation directory is D:\oss, delete the file in D:\oss\server\var\logs.

[Confirmation]
The BulkCollectorDm_1 process is running properly and does not automatically restart. Historical performance data of the bulk instance can be collected and viewed.

Step 1      On the Service Monitor tab page of the System Monitor client, check whether the BulkCollectorDm_1 process is running properly. Check the start time of the process to determine whether the process is running properly. If the start time does not change, the process does not automatically restart.


Step 2      After two collection periods, verify that the historical performance data of PTN V8 NEs (such as PTN7900/PTN990/PTN970/PTN905E) or OSN9800/OSN9600 NEs is displayed.


Step 3      After two collection periods, verify that the historical performance data of the instance created by using the default bulk template under the Router/Switch/MA/ME NE


node is displayed.