BigFix Client Has Excessive Hard Drive IO

(imported topic written by stephen691)

BigFix client is installed on my computer for VPN connection to my emplooyer’s site. I’m not connected to the site right now and BigFix is thrashing my hard drive. Thousands of i/o per second. This is typical behavior for BESclient.exe. I’ve tried to kill the process and it just restarts. I use Windows XP Pro SP2.

Is there any way to stop BESclient when I’m not connected to the VPN?

It can’t be good for my hard drive to contiuously have this much io. It sounds like it’s defragmenting continously.

(imported comment written by BenKus)

Hey stephen,

If you have access, you can stop the BESClient service and it shouldn’t restart on its own unless your BigFix Administrator has created a policy to restart the agent automaticall. I think you will need to work with your BigFix Administrators to figure out the best course of action.

Also, please not that although Task Manager will report high aggregate values of IO usage, it is actually a very small percentage of your overall system resources and it is not expected to have any noticeable impact on your system. It might be something else that is causing your disk to actively churn (which you should be able to figure out after you stop the agent).

More info at:

http://support.bigfix.com/cgi-bin/kbdirect.pl?id=43

Ben

(imported comment written by stephen691)

I have tried killing the process and my computer becomes quiet, as far as disk access goes. Then BESclient.exe starts again and the hard drive access can be heard. I work for a giant mega corporation so my compaint is likely to be as effective as trying to raise the level of the ocean by adding buckets of water.

(imported comment written by BenKus)

Hi stephen6,

It is possible that your BigFix Administrator is running actions for things like searching the disk for files or something like that. We can certainly look to help you troubleshoot this (because we certainly don’t expect this issue), but unfortunately, we would need to speak with your system administrators to figure out what is going on.

Ben

(imported comment written by tscott91)

I am also seeing this issue… I demoed BigFix on about 150 Servers and PC’s (mostly servers) and never really checked Disk IO… Yesterday, I rolled it out to about 800 computers… Today I got a request that someone’s PC was running slow… Not seeing anything spiking the CPU or memory I turned to filemon…

I ran filemon for about 5 minutes and BESClient.exe was constantly hammering away… I’m assuming this was what was causing her slowness but can’t be sure until I have her check back later as she is gone for now… I decided to run filemon on a few other PC’s and both returned the same results… BESClient.exe filling up the filemon log…

This is normal?

Thanks

(imported comment written by NoahSalzman)

The appearance of disk activity in filemon or perfmon is normal and usually not indicative of a true performance hit.

http://support.bigfix.com/cgi-bin/kbdirect.pl?id=111

It would be good to compare what you are seeing on a computer that is not running slow and see if the Client disk activity is roughly the same.

(imported comment written by jessewk)

Also a good test is to just turn the client service off and see if the slowness persists.

(imported comment written by garycleft91)

Right. Just turn it off when not needed. My PC works a bit slow with Bigfix running so I simply just turn it off when it does. Easy as pie. [

color=#DCDCDC

_ pokies _[/color]|http://www.pokies.net.nz/]

(imported comment written by mcalvi91)

we havent seen any major disk IO from the bigfix client. what we have seen is where something will interfere with the normal operation of the system (corrupted HIPS policy, messed up WMI from an application install) and the bes client will be blamed for the issue. In the case of the WMI any application polling WMI would spike the CPU until the app was killed. In the case of the corrupted HIPS install, when BF attempted to access the registry, the HIPS client returned a result in a manner that did not conform to MS standards and caused the bes agent to tank the CPU.