beserver.exe high CPU 11d

[Jeff_Couttouw]

Experiencing a very high use of the CPU by the beserver.exe process on a Windows 2000 server with SP4.  Currently running 11d build 7170 and have rebuilt the BE database, ran a .Net 2.0 repair.  Does anyone have any suggestions?

[Greg_Meister]

Hi Jeff,

Does the CPU utilization stay high, even when there is no backup activity? Does stopping and restarting the Backup Exec services drop the CPU utilization until next backup? If the CPU is consistently busy when no jobs are running, there may be a problem within the Backup Exec database. Worst-case scenario could involve loading a blank database, which would require recreating jobs, schedules, etc.

Greg

[Jeff_Couttouw]

Greg,

Yes, the beserver.exe process stays at a high CPU mark at all times the BE services are running regardless of a job running.  Stopping and restarting the BE services does not rectify the problem.  What is the process to delete the existing database and load a new one?

Regards,

Jeff

[Courtney_Kibbe]

I'm having the same issue.  My CPU hangs around 20% without any jobs runing.  I read a post on here to check out the crf.log (mine is located at C:\Documents and Settings\All users\Application Data\Symantec\CRF)  Sure enough, the log files shows the same message over and over again about how it could not load the file assmbly report viewer.  I called Symantec and they blamed Microsoft Framework 2.0.  I called Microsoft and they blamed Symantec.  I've got three different softwares on this server that install some form of free SQL and I think they are corrupting each other.  I have a call back to Symantec now to go over it again.  Anyway, check that log file and maybe it will give you a clue as to what is going on.

[Patty_McGowan]

Hello,

It appears that issue is the .NET Framework is missing a couple of folders.

BESERVER initializes the reporting engine (CRF), and it relies on .NET Framework to do this. However, the CRC.EXE (to compile the reports) doesn't start. The reason why it didn't start is because the directory "Temporary ASP.NET Files" does not exist in the .NET Framework install directory. So, creating this directory, allows CSC.EXE to do its work and place the required files by the reporting engine inside that directory. The result should be BESERVER immediately frees up the high CPU and memory utilization. If however, this directory exists, then deleting what ever is inside it - should also fix the issue.

The install path should be C:\WINNT\Microsoft.NET\Framework\v2.0.50727 create a folder named Temporary ASP.NET Files under this directory another folder named CRF will be created under this one.

If the folder does not exist, create it.  If it does exist delete the contents.

Please let us know if this resolves your issues.

Patty

[Jeff_Couttouw]

The problem was resolved by excluding the following processes from CA InoculateIT 6.0...

benetns.exe, beengine.exe, beremote.exe, beserver.exe, bkupexec.exe and pvlsvr.exe.

The server was upgraded from Veritas BackupExec 9.0 to Symantec BackupExec 11d.  The previous version of BackupExec did not require the BackupExec processes to be excluded from the realtime scan, but it appears 11d does.  We had originally excluded the file path to the upgrade installation of BackupExec 11d as was done for the 9.0 installation, but that no longer addresses this issue when using InoculateIT 6.0 with BackupExec 11d.

Jeff

[Patty_McGowan]

Jeff,

Thank you for posting the resolution.

Patty

[Todd_Neal]

I ran into a similar problem that we just resolved for weeks. Our DBA dumps all his sql backups to a file server with 3 drives. C (80GB) D (80GB) & E(250GB). I run one backup job against all 3 jobs. As soon as I upgraded to 11d and pushed out the new agent to this machine the DBA started to contact me every time the backup was running. It would hose up the machine and grab the CPU so that you could not really navigate.

Tried a bunch of things. Everything we researched on the net and installing all the updates...sitting on hold in the queue with BE support. Uninstalled and reinstalled the agent. We then split up the job and noticed that if you run the backup against the C: drive or the D: drive it was fine. It was only when you run it against the E: drive that there was a problem. We moved the content off of E: to D: and backed up that data fine. Replaced the E: drive and everything is good now.

It may have just been a coincidence that the drive went bad but I don't think so. The problems started right after the upgrade and nothing has changed on that server for years and we have been running Backup Exec for 3 years.