BUG REPORT: The nbpem process may consume large amount of CPU when there isn't at least one schedule with a due date.

Article:TECH53314  |  Created: 2008-01-30  |  Updated: 2008-01-30  |  Article URL http://www.symantec.com/docs/TECH53314
Article Type
Technical Solution

Product(s)

Environment

Issue



BUG REPORT: The nbpem process may consume large amount of CPU when there isn't at least one schedule with a due date.

Solution



Bug: 1124176 - Manually submitted immediate backups queue very slowly in MP5

Symptom(s):
If there are no policies that schedule a backup, nbpem ends up recomputing the work list almost constantly.  This scenario could happen in an environment where solely third party schedulers are used to start backups.  The constant recomputing of the work list causes very slow response to user and immediate backups.  Additionally, submitted jobs (such as user directed backups) may not show up in the NetBackup Activity Monitor.  

There are two ways to detect this issue:

1. Check nbpem logs for message "no jobs scheduled for future", indicating there are no jobs scheduled.  
2. Check the nbpemreq -tables screen and verify that not a single scheduler is due.
The critical piece of information to review in the output is the year displayed.  In the example below, the year is 2015 (bold added for clarity).  This indicates a valid schedule is due in the future, despite the "Not_Due" message.  
due = Sun Aug  2 00:00:00 2015  (1438466400) Not_Due

In the following example, the year is 2038, which is interpreted as infinity, thus indicating there is no schedule due.  
due = Tue Jan 19 04:14:07 2038  (2147483647) Not_Due

Log Files:  
The nbpem log file (at verbose 1) shows the following:
08/31/07 11:39:55.618 [Debug] nbpem PID:10330 TID:9 File ID:116 [No context] 1 [JobScheduler::scheduleNextJob]  no jobs scheduled for future, setting wakeup for 1188553255 (Fri Aug 31 11:40:55 2007 )(JobScheduler.cpp:2703)

Workaround:
To resolve this issue, create at least one policy that uses the scheduler.  The policy doesn't actually need to back anything up.  It can be a policy which fails or has an invalid client name.  The policy must, however, have an open window.  This stops the over recomputation of the work list.  Confirm the open window using the nbpemreq -tables command.  This command should return something similar to the following (any year but 2038):

due = Sun Aug  2 00:00:00 2015  (1438466400) Not_Due

ETA of Fix:
Symantec Corporation has acknowledged that the above-mentioned issue is present in the current version(s) of the product(s) mentioned at the end of this article. Symantec Corporation is committed to product quality and satisfied customers.

This issue is currently being considered by Symantec Corporation to be addressed in a forthcoming Maintenance Pack or version of the product.  The fix for this issue is expected to be released in the fourth quarter of 2007.  Please note that Symantec Corporation reserves the right to remove any fix from the targeted release if it does not pass quality assurance tests or introduces new risks to overall code stability.  Symantec's plans are subject to change and any action taken by you based on the above information or your reliance upon the above information is made at your own risk.  Please refer to the maintenance pack readme or contact NetBackup Enterprise Support to confirm this issue ET1124176 was included in the maintenance pack.  

As future maintenance packs are released, please visit the following link for download and readme information:  
 http://www.symantec.com/enterprise/support/downloads.jsp?pid=15143




Supplemental Materials

SourceETrack
Value1124176
Descriptionmanually submitted immediate backups queue very slowly in MP5


Legacy ID



290875


Article URL http://www.symantec.com/docs/TECH53314


Terms of use for this information are found in Legal Notices