Utilisation at 40% 1

[fatboy69]

I have a Netware 5.1 SP5 DS7.60A environment with 10 local and 4 remote sites with a server on each. The server that contains the Master for evey partition has an issue every afternoon when user start logging off the server shows 40-48% utilisation for about 2.5 hours. This overall performance. It also is the main File server and runs Zenworks. (no inventory)

A Trace shows no eratic traffic, and Adrem shows server.nlm running at 70%. This is true through out the day. I have performance tuned this server based on my knowledge and all the available tids on the novell site. I am yet to remove all the replicas off it but DS.nlm is harldy working?

Any tips would be greatly appreciated.

 

[marvhuffaker]

Fatboy, with limited info on your configuration, it's very difficult to try to tell you what could be causing the utilization.

What I would recommend doing is figure out what NLM is causing the processor utilization to peak. You can do this from within MONITOR.NLM on the server. Make sure to do it when you are experiencing a spike.

Step by step from the console:

LOAD MONITOR
KERNEL (Select this option from the main menu)
BUSIEST THREADS (Select this option)

Wait a few seconds and see what is at the top spot on the list. Hopefully it is named by NLM and not just server process. You can then focus on that particular NLM as suspect and troubleshoot from there.

Hope that helps.

Marvin

Marvin Huffaker MCNE, CNE
Marvin Huffaker Consulting

http://www.redjuju.com

 

[LolaRed]

Hi Fatboy. Are your users working with Microsoft Office products? Novell TID 10065560 "Poor performance accessing Microsoft Office documents on a Novell server" explains a little. I'm only mentioning this because you wrote about the high utilization that occurs when users start logging off. They're most likely saving documents at that time as well.

I recently applied Nw51Sp6 to my servers and discovered that Excel was the culprit (actually freezing workstations and sending the file server to the moon with high utilization). No resolution yet.

Just wondering if this might be your issue.

Lolared

 

[LolaRed]

If your problem is related to document saving, try SET CLIENT FILE CACHING ENABLED = OFF. It solved my problem.

 

[fatboy69]

Thanks LOLA.

I havent actually tried the set file caching to off but I will. All users are running MS office so I will look into that aswell.

I forgot to mention that they are using Romaing profiles and that this server stores the home directories for all 500+ users. They are also a government agencie so come 4pm they are all logging of to go home.

I will definatley post my results from your recommendations.

cheers.
Fatyboy

 

[Jontmke]

If the utilisation stays up all day, even after everyone has gone home then you have a runaway process. If you have my luck the culprit will only say server.nlm. In that case the only thing (I think) you can do is reboot the server.
Been there, Done that.

Jon

There is much pleasure to be gained from useless knowledge. (Bertrand Russell)

 

[terry712]

what size are the roamers?

run a treesize across them - this should cause high utile though

you said every master for all partitions

how many partitions do you have - and why would you put all masters on one?

what kind of spec of server are we looking at?
whats you lru , cache buffs etc

 

[spi200]

Hi Fatboy

I had a case last week which is worth a mention as it sounds familiar.
One afternoon one of our server sent the utilization thru the roof to the point where the server was slow to repsond to requests etc. We have a dual processor and Monitor showed the server at around 40%, but managewise showed the utization at almost double this for one of the processors.
Monitor show no unusual activity or high disk useage, but managewise showed a couple of users who had recently logged out with an extermely high amount of NCP requests. The totals were high and all were roughly the same value at around 4,900,000,000. I could find no reason for this, the only common thing was the numbers went thru the roof as people logged off. I check the caching stuff on the server, and I check we had the lastest virus signatures, but nothing so I bounced the Server and have had no problems now for two weeks. As users logged off I just kept clearing the users in monitor by hitting F6 under connection which clears the "Not-logged" in connections from the server. This kept the utilization under control till the reboot. I have installed and maintained hundreds of Novell server for years and never seen or herd of a server doing this, so good luck.

David CNE

 

[pawpaw]

I have recently come across a similar situation. DS could be the culprit.
I had old volume objects in my tree that did not exist any longer.
It seems for whatever reason, clients were making calls to these objects and utilization pegged at 100%. If I would unload DS, util. would drop. Reload DS, and util. would stay down for awhile.
A LAN trace would verify this. Look for a large amount of NDS and NCP calls from particular workstations.

Also had another server with high utilization. After a reboot, though, the server went into a vrepair. Had many errors. Utilization has been fine since.

 

[jsinghota]

Hi
We had a similar issue and found the following info, hope it helps:

High Utilization Caused by NDS - TID10065129 (last modified 17FEB2003)

Keep Smiling
Jai

 

[johndpatriort]

We are this issue and I have checked the Kernal-threads. the highest one is:

VxNDMP_cd12c400 3,890,095.

Is this normal?

 

[spi200]

Hi

Check the Version of HPGATE.nlm, has been some problems with version earlier than 2.01a. There is TID on this on the Novell Site.

Regards

David

 

[fatboy69]

Thankyou everyone for all your input. Never ended up solving this one as we went to NW6.5 on the weekend.

Would have been nice to come to a resolution, but 6.5 works great. Cant complain.

FB

 

[johndpatriort]

I had he same issue and just switched the Master to one of the other servers on site. This seems to have cleared the issue up although I am now rebuilding the other server anyway.