Highlighted
cstech_swansea Absent Member.
Absent Member.
5996 views

OES SLES NDSD CPU LOAD HIGH

HI,

Could anyone help with a problem regarding the CPU load of my SLES server with OES addon.

The system in SLES 11 SP1, or OES 11 installed on that and since I have imported +20000 users into the eDriectory database the system appears to be running very slow. Even running a directory (ls -l) listing from a Linux command line as root take 5-10 seconds rather than the normal instantaneous response.

When I run the ls -l command or anything that appears to search the eDirectory database the NDSD CPU load jumps to +100% from montioring with 'top' and I am unsure if it should be doing that or if there is something mis-configured with the system.

Also before the 20000 users were imported connecting to the samba server I am running in the system via iManager took only a second to display the server details and user, where as now it take 1-2 minutes.

If anyone has any advice it would be most appreciated
Labels (2)
Tags (5)
0 Likes
7 Replies
Knowledge Partner
Knowledge Partner

Re: OES SLES NDSD CPU LOAD HIGH

Are all your users in one OU?
Does that server have a replica/copy of that partition that holds that information?

What's the server specs? (RAM, CPU, etc.)
0 Likes
W_Prindl Absent Member.
Absent Member.

Re: OES SLES NDSD CPU LOAD HIGH

How mach memory does that server have? What does top show as memory
consumption?

Did you only import your users into the edir database or are those
users now authenticating against the server and accessing resources on
the server.

Is this server the only server in the tree or are there other servers
in the same tree, too.

After completing the import and the replication of the import to all
other servers in the replica ring, if there is no additional user
activity on the server (like authentication and file access) you should
not have ndsd performance issues as long as you have enough memory
available.

If you have more than 20000 users accessing file resources via SAMBA on
this server simultaneously I would not be wondered if your server load
goes through the roof. SAMBA file access simply is not performing well
with much more than 500-1000 concurrent users.

BTW if you run ls-l this should not be touching the edir database all
time, as long as you have not masses of different LUM enabled edir
users as owners of the files you query - as the user information is
cached. But of course if you check the contents of a directory with
files, whose ownerships span over all 20000 users that is too big for
caching and this can negatively affect the performance of ndsd.


--
W. Prindl


cstech swansea wrote:

>
>HI,
>
>Could anyone help with a problem regarding the CPU load of my SLES
>server with OES addon.
>
>The system in SLES 11 SP1, or OES 11 installed on that and since I
>have imported +20000 users into the eDriectory database the system
>appears to be running very slow. Even running a directory (ls -l)
>listing from a Linux command line as root take 5-10 seconds rather
>than the normal instantaneous response.
>
>When I run the ls -l command or anything that appears to search the
>eDirectory database the NDSD CPU load jumps to +100% from montioring
>with 'top' and I am unsure if it should be doing that or if there is
>something mis-configured with the system.
>
>Also before the 20000 users were imported connecting to the samba
>server I am running in the system via iManager took only a second to
>display the server details and user, where as now it take 1-2 minutes.
>
>If anyone has any advice it would be most appreciated


W. Prindl
0 Likes
ataubman Absent Member.
Absent Member.

Re: OES SLES NDSD CPU LOAD HIGH

First is to make sure you are patched up, there have been a lot of fixes for ndsd and ncp that help with utilisation.
Second, make sure there isn't any eDir issue causing sync errors or excessive syncing, a full eDir health check IOW.
Third, there is some ndsd and ncp tuning that may need to be done to up the available thread counts.
Support | Get the most out of Novell Open Enterprise Server 11

Andrew C Taubman (Sorry, support is not provided via e-mail) Opinions expressed above are not necessarily those of Micro Focus.
0 Likes
cstech_swansea Absent Member.
Absent Member.

Re: OES SLES NDSD CPU LOAD HIGH

hi,

There is a 1 replica within the system that hold the information, i did however have the same issues before the replica was in place

Server spec
2 processors
model name : Intel(R) Xeon(R) CPU X5550 @ 2.67GHz
stepping : 4
cpu MHz : 2666.760
cache size : 8192 KB

6GB RAM,

System is running within a VMware
0 Likes
cstech_swansea Absent Member.
Absent Member.

Re: OES SLES NDSD CPU LOAD HIGH

Hi,

the server has 6GB of memory and top didnt show any excesive memory usage

I only imported the users, the server not being used by any users at present, it is development stage

only a small number of users are enabled for samba, 350, so that shouldnt be effecting it and they again are not using the system at present

the ls -l command was being run within the roots home directory so only on a small number of files and all owner by the user root and the group root
0 Likes
Knowledge Partner
Knowledge Partner

Re: OES SLES NDSD CPU LOAD HIGH

cstech_swansea;2217930 wrote:
Hi,

the server has 6GB of memory and top didnt show any excesive memory usage

I only imported the users, the server not being used by any users at present, it is development stage

only a small number of users are enabled for samba, 350, so that shouldnt be effecting it and they again are not using the system at present

the ls -l command was being run within the roots home directory so only on a small number of files and all owner by the user root and the group root


IMO, normally I see ndsd periodically spike in CPU usage (it varies on our busy system). For example, I've got a DS Master Replica server with 80 replicas, although only about 5500 users (I think maybe 20,000 objects in total)? DIB set is about 225 MB in size.
Running in XEN DomU, I see periodic spikes, at least after patching fully.

So I wonder if you're seeing Vmware disk latency/speed/performance.

I'm going to ASSUME:
This is OES2 SP3 64-bit FULLY patched?
That your VMWARE is set to SLES 10 64-bit
That you have installed the Vmware tools
That you are not using thin-provisioned disks (you get a performance hit as it grows the file system).

When you say the "server" has 6 GB are you referring to the VMware host, or the guest operating system?

If the guest, how much RAM is actually allocated to the guest, and how many CPU's/cores (depending upon your version of Vmware) are allocated to the guest?

I've got a test lab setup in vmware, but I'm running 64-bit everything, the guest machine has 2 vCPU (set at unlimited resources currently) and 2.5 GB of RAM, although the HOST in Vmware is an 8-core Xeon something or other with 64 GB of RAM and other vms on it.

You may also need to tweak/adjust your eDir cache, but I'm thinking if a simple linux file system command is what's causing issues, that you have disk contention going on.

I can do a:
du -sxh * at the root level of the disk (single disk in my vm system) and while I do a :
top

I do not see ndsd at 100% CPU at all)

In fact, the "du" command is at 2% CPU and it's the highest used.
0 Likes
cstech_swansea Absent Member.
Absent Member.

Re: OES SLES NDSD CPU LOAD HIGH

hi,

the system is OES 11 (not OES 2) which is fully patched
the VM is set to 64bit
VM tools is installed

It is the VN guest that has 6GB of memory, the entire VM host has a great deal of memory (I am not sure how much as i do not run the host system) but I know that it runs at least 20 vm guests within it, none of the other guest appear to have any issue so I believe it is something to do with the system i am running.

I have looked at the cache, and the DIB is 200Mb, and the cache size limit is set to 400Mb

I have temporarily removed all of the 20,000 users and the system is again running correctly, I get no 100% NDSD utilization when doing any file system commands.

Ill have to see what happens when i re import them in a day or so
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.