- Why is the machine so slow and with such a high load average?
- Because processes are beginning to accumulate due to the delay in the name resolution (UIDs, UID Numbers, Logins, etc..) caused by the pending query to the LDAP/AD server, that is, in itself, very time consuming
- What are the causes of those problems at AD level?
- The Performance of the server when responding to LDAP queries;
- A heavy structure with many users and changes done to the AD - when the clean installation was done, the performance was fast and efficient, however, and since so many alterations were implemented, such as; upgrades, new software installation, updates in the AD schema, software removal, user creation, etc. that the performance has been hindered;
- Also noteworthy is the addition of new AD Domain Controllers (of the same version as the original or not), the migration from one domain controller server to another, from one version to another, and the removal of other AD Domain Controllers (correctly removed or simply terminated with or without important tasks attributed - Operations Masters/Roles).
All these actions are normal practice in a modern organization, but that 'mistreat' of the database information - LDAP - will not help the AD to perform at its best and also, historically, the AD/LDAP will keep record of all these 'ill-treatments', creating thus, instability and unreliability in the system.
- So what can be done to minimize these problems?
- If the windows workstations are functioning unaware of the LDAP (AD), using just a service called Domain Controller (DC) that resides in the Samba server, they apparently work in a reasonably and acceptable manner! At least most of the time, unless someone tries to add a new DC and/or migrate 'Roles' (important AD tasks) from one server to another. In this case there's no solution in sight.
iPortalMais