NBSL process load

[Frbutler]

I have my Master server (6.0MP4) running on AIX 5.2
I also run NOM from a VMware server.

With NOM turned off I still get abnormal CPU load from the
Master server NBSL process.. after looking it up, NBU refers to it (NBSL) as the communication process between the master and the Nom server.

Has anyone had any issues with memory leaks for NBSL?

We did find a KB article on NBSL memory leak but it was in the context of "If Access Control is enabled"

Thanks in advance

 

[Frbutler]

woohoo!!
Tell me I did not stump the stumpr!!??

 

[dukbtr]

I too am getting high CPU loads from NBSL. We run NB Master on HP-UX 11.i system. It is sometimes soo bad that we are 100% cpu load for hours. Please if anyone has any ideas on this issue let us know.

 

[Stumpr]

Don't look at this and say it doesn't apply. I am only posting it to give some idea of where to look for potential problems and places to look for hints to resolve the issue.
For instance it mentions a nbsl logfile. What do you find in yours? What about the TCP/IP configuration? Are you collecting sar stats?


STATUS CODE 195: Viewing media or volume pools in the NetBackup Administration Console results in status code 195: unable to connect to the Netbackup service layer service.

http://support.veritas.com/docs/295397

Exact Error Message
Unable to connect to the NetBackup service layer service (NetBackup Service Layer Daemon) on host <master>, it failed to respond - Server connection failed. Verify services or daemons are up and running (195).

Details:
Overview:
The above problem can occur when going to view media or volume pools if nbsl terminates during normal operation of NetBackup. In one case it was seen during a period of heavy backup activity at the same time that NetBackup Operations Manager (NOM) was performing data collection.

Troubleshooting/Log Files:
The last messages seen in the nbsl log when the service stopped:

11/6/2007 21:28:56.288 [Debug] NB 51216 nbsl 132 PID:4384 TID:4880 File ID:132 [No context] 1 [ServiceManagerCollector:oCollect()] PC Flag is 1(ServiceManagerCollector.cpp:312)
11/6/2007 21:28:56.288 [Debug] NB 51216 nbsl 132 PID:4384 TID:4880 File ID:132 [No context] 1 [ServiceManagerCollector:oCollect()] Collecting data for Media Server = <media server> (ServiceManagerCollector.cpp:286)

During this time there is a heavy demand on master server resources, particularly with socket availability. Check for a large number of TIME_WAIT processes by running netstat -a on the master server. This number can be considered large generally if it is over 100.

Resolution:
If the above symptoms occur and a large number of TIME_WAIT processes on the master server are found, consider reducing the TcpTimedWaitDelay value. This can be an indication that ports are not being released quickly enough to allow another connection on that port. The registry setting TcpTimedWaitDelay can be added to reduce the time a port will stay in this state.

1. Go to Start | Run, type regedit, and click OK
2. Navigate to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters
3. Highlight the Parameters key, right-click and select New | DWORD Value
4. Type the name TcpTimedWaitDelay
5. Double-click TcpTimedWaitDelay and enter a decimal value of 30

By default, this value is 240 seconds (4 minutes). It is recommended that this be changed to a value between 30-60 (seconds) in decimal, to decrease the wait time before a port becomes available.


Bob Stump
VERITAS - "Ain't it the truth?"