AD LDS - Speichernutzung dsamain.exe

[daabm 1.366]

Hallo zusammen.

 

Ich habe hier ein AD LDS mit einer adamntds.dit von 85 GB. Fragt nicht warum - ist so Der Server dazu (2012R2 Standard auf 2016 HyperV) hat 1 vSocket, 4 vCPU und 128 GB Hauptspeicher, und nach allem, was ich weiß und bei MS dokumentiert ist, sollte dsamain.exe (der LDS-Serverdienst) sich deshalb im Lauf der Zeit auch gut 85 GB RAM genehmigen. Tut es aber nicht:

 

Anders formuliert: Bei 28 GB gibt es ein Plateau, die vorher stetig steigende Speichernutzung stagniert und CPU/IO fallen in den Keller. Reproduzierbar auch nach Reboot, immer das gleiche Spiel - Speicher steigt kontinuierlich, Plateau bei 28 GB und Performance im Keller.

 

Hat jemand eine Erklärung, warum das so ist und was ich dagegen tun kann?

 

Braucht der Server mehr vCPU? (Obwohl die Auslastung da gerade mal um die 30% liegt). Gibt es irgendwelche hardcoded Limits in dsamain.exe? Liegts an der aktuellen Luftfeuchtigkeit? (Obwohl, gestern war es trockener, da war das aber auch schon so...)

 

Wenn Infos fehlen, einfach kurz Bescheid geben. Und ja, Google/MSDocs hab ich durch - da geht's aber immer nur um das Gegenteil, "AD braucht zu viel Speicher". Bei mir ist es "AD braucht zu wenig Speicher"

[NilsK 2.957]

Moin,

 

mal ganz dumm gefragt - es ist nicht einfach ein Tippfehler in der VM-Config? 28 versus 128 liegt da irgendwie so nah.

 

Gruß, Nils

 

[cj_berlin 1.329]

Moin,

 

nach allem, was ich weiß, liest ESE die Daten nicht auf Verdacht hin in den Cache ein, sondern erst, wenn sie angefordert werden. Daher:

 

1. Ist sichergestellt, dass da wirklich 85 GB Daten drin sind? Vielleicht ist da ganz viel Whitespace?

2. ist es vorstellbar, dass nicht alle Datensätze über den fraglichen Zeitraum abgerufen wurden?

[daabm 1.366]

vor 4 Stunden schrieb NilsK:

28 versus 128 liegt da irgendwie so nah.

Nein, ich seh schon 128 GB RAM und 97 GB verfügbar

 

vor 2 Stunden schrieb cj_berlin:

1. Ist sichergestellt, dass da wirklich 85 GB Daten drin sind? Vielleicht ist da ganz viel Whitespace?

2. ist es vorstellbar, dass nicht alle Datensätze über den fraglichen Zeitraum abgerufen wurden?

Punkt 1: Steht jetzt ganz oben auf der Liste - Offline-Defrag. Nur dauert der ein paar etliche Stunden, bisher noch nicht dazu gekommen. Danke für den Denkanstoß!

Punkt 2: Da läuft in dem Moment ein Check-Skript, das wirklich durch den kompletten Datenbestand durchgeht.  Und "komplett" meint genau das, rekursiv durch die gesamte Containerstruktur.

 

Edit: Das Check-Skript ist in dem Moment, wo die 28 GB Memory erreicht werden, bei weitem nicht zur Hälfte fertig. Ich bin gespannt... Und werde berichten.

bearbeitet 22. April 2021 von daabm

[daabm 1.366]

Ein fröhliches "Moin!" in die Runde

 

Viel Whitespace kann nicht drin sein - oben die originale, unten nach "ntdsutil file compact to" - stolze 13 MB kleiner geworden:

 

Ich habe die defragmentierte DIT dann verwendet, aber wir sind unverändert ratlos:

 

Die Diagramme decken einen Zeitraum von 30 Minuten ab. Memorywachstum stoppt, I/O stoppt auch.

Memory insgesamt sieht in dem Moment so aus:

Ich sehe da nichts, was auch nur ansatzweise an irgendeinem Limit wäre.

[NilsK 2.957]

Moin,

 

vor 3 Minuten schrieb daabm:

I/O stoppt auch.

das heißt, dann antwortet auch nix mehr?

 

Das Übliche habt ihr schon gemacht, also mit einer anderen VM probieren und so?

 

Gruß, Nils

 

[daabm 1.366]

Antworten tut's weiter, aber langsamer - viiiiel langsamer...

"Andere VM" - also andere Hülle/anderer Host - schon mehrfach. Update der VM auf 2016 oder 2019 wird auch diskutiert.

Konkret zum I/O:

Soll heißen: Solange der Speicher noch wächst, hab ich brutto knapp 300 MB I/O. Danach noch 180 kB.

[daabm 1.366]

So, kurzes Feedback - nach einer hinreichend langen Wartezeit:

 

Jetzt sind wir also "irgendwie" da gelandet, daß dsamain so viel Speicher braucht wie seine adamntds.dit. Eine Erklärung, warum das so lange gebraucht hat, habe ich nicht.

[tesso 375]

@daabm Falls es dich tröstet, ich kann mir das auch nicht erklären.

 

Aus Interesse wie lange hat es nach dem "anhalten" gebraucht bis die 85GB erreicht wurden? Laufen eure Abfragen jetzt wieder schneller?

[daabm 1.366]

Das lief über's Wochenende - ich hab also leider keine Ahung Hab jetzt mal nen Perfmon drauf angesetzt (nach Dienstneustart), hätte ich auch gleich machen können...

Wirklich schnell ist es immer noch nicht, aber das mag an der Anwendung liegen, die das nutzt - die ist etwas "verschachtelt" aufgebaut mit ACLs und Delegationen und etlichen Objekt-Querbeziehungen.