Endpoint Protection

I've got a post or thread or two here already about how the SEMSVC really hammers the CPUs on the SEM server, but I wanted to dig further.
This is a pic of the NETWORK usage on the SEM server when the console is running over on my desktop computer, then can you tell when I logged off and fully closed the JAVA console?
Bet you can!
Wow, 3% or so of a 1GIG NIC. Pretty impressive.

 

Need a refresher on my other charts? Here's the CPU load...............

SEPM server really whams a VMWare server.

REMINDER - I never, I do not, run the console from a server. That's a no-no. Don't run interfaces or applications from servers. Servers are for services. Interfaces or apps are for desktops, so when I show these , the console is NOT running on any server.
This is the SEMSVC.
Check the memory usage - 1.5gig out of 4gig. That's over 33% of physical RAM.

Hi Bill,

Can you run the debugdiag tool and use the tool to inspect the semsvc for memory leaks?

Here is a useful link I came across for memory leaks.

http://rfvicente.spaces.live.com/Blog/cns!5228FAA8B79B6EB1!394.entry

Aniket

If it's a leak, it's HUGE as this is shortly after a total reboot.
I had a case open because the SEPM servers were being hammered and some workstations were totally taking all available bandwidth for the entire network - 6 meg worth.
Come to find out, it's a BUG with SEP/SEPM RU6a.
If you have a client at RU5 and have packages assigned to a group, and the computers in that group are supposed to update from the SEPM automatically, most do, but some will not, and they will totally suck all available bandwidth until no one can work.
The solution?
MANUALLY install RU6a on the clients. Don't do the group update package.  Until all are totally upgraded from RU5 to RU6a, it kills the network.
These are clean new servers, the only thing on them is SEPM installed fresh from the RU6a package from Symantec.
SEPM is the only app causing us any woes at the moment.
Symantec still doesn't see this issue, but trust me, it exists in a huge way.

This isn't a matter of the SEPM sitting for days and gradually taking resources, this is happening within minutes of reboots. And, if you close the console and don't have any clients still back at RU5, then you won't see this issue at all.

LU does still bring the servers to their knees - the solution - stretch out the LU intervals and use other methods to get defs.

Sorry, RU6a is so buggy I can't recommend it. Stick with RU5 if at all possible.

Do you have open support cases with Symantec on these resource issues? I ask, because I've got a lab set up here running VMware ESXi 4.0 with RU6a installed and no issues. Have you been able to isolate this behavior to client traffic and interaction with the SEPM? For example, have you tried blocking network access to the server or setting IIS to deny temporarily (to eliminate client traffic)? I ask because it would help to know if you are experiencing this as only part of the running SEPM background processes, or if it's a direct result of client interaction.

How many clients in your environment? What's the server's resources (CPU, RAM, disk subsystem, etc.)? What version of VMware? What is your DB backend (embedded or SQL)? How often is your heartbeat set? Push or pull? How many content revisions to you maintain? Etc.

I recently had a case in which a customer was seeing high amounts of CPU etc. on his SEPM, javaw.exe taking a bunch of memory.  When he installed SEP client on top of it, he couldn't even get the SEPM to load.

Long story short, it all boiled down to the page file.  He was using a virtual 2008 R2 server and had designated a 4 GB virtual disk for page file.  However, Windows was not recognizing it and was only using a 256 MB page file on the C: drive, which was exhausting resources VERY quickly.  This behaviour (Windows not recognizing the VHD as a page file) was duplicated on another virtual server with no SEPM/SEP on it at all.

Is this a possibility in your case?

sandra

I am currently having the same exact issue as you. After you did the manual install of RU6a on the clients that would not upgrade has the bandwidth issue gone away?  I have a group of about 160 clients that will not update to the RU6a but they are currently running RU3 do you think this could still be my issue?

Interestingly enough, I took a look at mine and it looked similar to ShadowsPapa's above. I removed 5 different install packages for various groups and the problem went away.

CPU hasn't went above 2% in the last 10 minutes.