Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

DLO Agent [DLOClientu.exe] takes way too much processor time

Created: 15 Feb 2005 • Updated: 21 May 2010 | 8 comments

Hi ALL-

I have a bunch of Software engineers that are complaining about the DLO Agent indexing all the file changes while they are running their intensive tests. Is there a way to keep the Agent from scanning for changes during the normal working hours? I believe that it is related to the DLO Agent Change Journal Reader scanning the changed files. I would reather not have to shut down the Agent service in the services control panel.

Steve

Comments 8 CommentsJump to latest comment

Dana Larson 2's picture

I just posted basically the same question...

could we get some kind of answer from the support staff please?

priya khire's picture

Hello,

Your query seems to be related to the DLO agent indexing all file changes during tests.Is this causing other applications to run slowly? In case you are referring to the user bandwidth settings, you can change them. Refer to pg. 1196 of the administartor's guide. you can dowload it from the following link:

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

In case you problem is not the one mentioned above, you can write up in this forum. However if we do not receive your intimation within two business days, this post would be "assumed answered" and archived.

Regards.

Warren McNeil 2's picture

I am also having this problem the only difference is that we are using Netbackup DLO.

How do I prevent the agent from indexing the files in realtime?

Robert Gutierrez's picture

Hi All,

I am having the same problem with my Software group as well. The DLOchangelogSvcu.exe stays at 100% CPU. When I refresh the agent, it clears but upon the auto scan, it returns at 100%. Knowing that open files are not backed up, and these engineers use Rational Rose and have local folders to back up(with files still open at times), is it possible to to disable the Change log? I verified that my network is not the concern here.

Thanks

Robert

Steve Shellard's picture

Hi, We too suffer from the DLOClientu.exe process using excessive processor time, which makes the laptop virtually unusable. We are currently testing DLO with a view to rolling it out to our users. However if there isn't a solution to this problem, we will probably look elsewhere for a solution.

Cheers
Steve

Robert Gutierrez's picture

Steve,

Does your environment have open files? Seems like if the user has open files, it attempts to keep trying to update the log file.

Thanks for the update Steve.

Regards,

Robert

Robert Gutierrez's picture

Here is a pre-released tech note that solved my problem and will help others with the same issue...
Bug:
When a drive or path that doesn't exist on a DLO agent is specified for backup, DLO processes take up as much as 80% or more of CPU usage. The DLOChangeLogSVCu.exe and DLOClientu.exe processes specifically will be seen consuming CPU.

Bug ID: 319077

Symptom(s):

Master Log Files: N/A

Media Server Log Files: N/A

Client Log Files: N/A

Workaround:
Examine the backup selection information within the profiles for the affected machines. Identify the use of static drive letters that may not exist on some DLO Agents. For example, suppose that "d:\data" is specified as a backup selection. If this folder doesn't exist for one of the DLO Agents that use that profile, that DLO Agent will experience the CPU usage issue mentioned above.
Instead of specifying an exact drive, use the %LOCALFIXEDDRIVES% macro. For example, if there is a folder called "data" at the root level, add the following entry as a backup selection:
%LOCALFIXEDDRIVES%data
This macro will back up paths such as c:\data, d:\data, e:\data, etc. This applies only to local fixed disk drives.

ETA of Fix:
This issue is scheduled to be addressed in a forthcoming release of DLO.
Another TechNote of interest is here: http://seer.support.veritas.com/docs/275960.htm
and here: http://seer.support.veritas.com/docs/277986.htm

Hope this helps all.

Thanks to Symantec for the note!

Regards,

Robert