Naimserv service running at 98-100% (High CPU) 1

[n1koolkat]

I am having horrendous problems with epolicy orchestrator some due to the nature of our network but the majority for inexplicable reasons.

The lastest is that the naimserv running runs constantly at almost 100% which prevents any sort of administration from the server or console. I have excluded scanning of the network associates folder, removed inactive agents, the msde database is is not up to 1Gb, i've flushed dns, scanned for viruses, attempted to stop and restart the epo server and event parser service, rebooted and cleaned out the logs to no avail.

Because of the high CPU, agents cannot complete their updates, and the repositories cannot update. I've spoken to NAI technical support and sent them the results of the mertool, but received no response. (They appear to be even more perplexed than myself).

This has happened once b4 and a rebooted completely ruined the repositories resulting in scripting errors which were never resolved by NAI Tech Support. In the end i was forced to uninstall and then rebuild the server and the recreat the tasks. I have over 100 sites and i can't go through the process again. Does anyone have any suggestions

 

[mattmsudawg]

By any chance have you checked in GroupShield 6.0?

 

[n1koolkat]

I have Groupshield 5.2 for Exchange 2000 checked into the repository

 

[mrashburn]

I saw a posting in NAI's knowledge base about that. Ya might wanna chech it out.

Mark

 

[P3dr0]

What's your hardware configuration ?
How many clients did you have ?
What's your ePo configuration ? (asci, number of connections..)

Did you already check the ePo data processed with "Performance manager" in windows 2000 administrative tools ?

 

[n1koolkat]

I am using a Pentium 4 server with 785Mb Ram, 30Gb HD, I have about 3000 clients of over 100 sites (including home users). EPO configurations is maximum connections 3000 ASCI for LAN users 60 minutes, WAN users 480 minutes, enforcement intervals for all users 15 minutes. In the end i was forced to rebuild the servers as i started getting licensing messages with denied me access to the console. When i spoke to Network Associates i was told a large part of the registry was missing.

I have just rebuilt the server without importing the databse and still the naimserv service is running at 99%

 

[Karto]

N1koolkat,

You are not alone in this problem .. I've got the same issues but only have 400 clients over 2 sites. Checked out NAI support pages and found the following (but did not help me out): Also found that at the time this occured I was not able to run The DAT/deployment report either... are you able to run all reports ??

Solution 1:
1) Remove inactive ePolicy Orchestrator agents:
See NAI24104: "Removing inactive ePolicy Orchestrator agents".
2) Remove old events and repair the ePO Database:
Login to the ePO Database within the console Directory tree.
Select 'Alerts'.
Select the 'Removal' tab.
Select 'All events that occurred more than XX days ago" and enter a value for XX.
Click 'Start'.
Select the 'Repair' tab.
Click 'Start' to repair the database.
3) Modify the ePO Server settings:
Reduce the Maximum Connections value.
Increase the Policy Enforcement Interval value (e.g. 60 minutes).
Increase the Agent to Server Communication Interval (ASCI) (e.g. 500 minutes).

 

[simonjcook]

We have the same issue.
We currently have a call in with NAI for it which has been escalated to backline.

The suggestions in the NAI article don't make any difference. Even after clearing *all* events from the database.

One suggestion from NAI Tech support was to delete all the scheduled tasks. It worked to a degree but not completely.
The CPU usage was alternating between 0 and 80% for a period but soon shot straight up to 99% again and stayed there.
I would guess that as the tasks had been removed there were less agents contacting the server.

Performance monitor shows the software downloads counter maxed out and the completed ASCI going through the roof (double that of our servers functioning normally).

I seems that the agents are requesting the new agent and the queue is full so they're being told to try later.
This is building up with agents retrying and bombarding the server with agent connections which is causing the server to exhibit the high cpu.
Even switching off the agent upgrade policy made no difference as they'd already received the notification to upgrade and were seemingly forging ahead blindly.

I am toying with the idea of re-pushing the agent to force it to reinstall or deinstalling all the agents altogether.
My guess is, if it's not running it can't tie the server up.

Then reapply the agents in stages.
1) It's going to mess with those nodes with non standard policies.
2) Who's to say the problem won't reappear as the number of agents increases.

Has anyone got any other suggestions... I am open to ideas at the mo...

 

[Karto]

Ive got some good news no longer running at 95-100%

What did I do (may or may not help you but I list it anyway just in case)

1) Stoped the ePO Server & Event Parser
2) Deleted all machines in domain or groups which where showing as not installed.
3) Restarted the ePO server & Event Parser
4) Loged to the ePO Database within the console Directory tree.
4) Select 'Alerts', then 'Removal' tab.
5) Select 'All events' (you may or may not want to do this dont know the possible other issues here)
6) Closed and reopened console and now running okay .. all bar the reports which is a seperate issue.

Karto.

 

[SimonVR]

I have had the same issue but have a very different solution that worked in my case.

Having studied the performance of the system and associated processes in detail, it appeared that the SQL (MSDE) server was not able to process the requests from naimserv.exe quickly enough and queues were simply filling up. To that end I increased the priority of the SQL server process. Now my server only goes CPU-bound for brief periods, and only when many HTTP requests are being made simultainously. The performance now looks more like pulse-loading, rather than the saturation it was previously.

The priority can be changed through SQL commands. In a command prompt on the EPO server run OSQL -E to enter SQL commands. Enter the following SQL commands;
[ol]
[li]sp_configure 'priority boost', 1[/li]
[li]reconfigure[/li]
[li]go[/li]
[/ol]
To reset the priotity to normal, repeat the same commands replacing the 1 with a 0