Jump to content

AD LDS - Speichernutzung dsamain.exe


Recommended Posts

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:

grafik.png.9e9593f4b4d8b8a517ab2ce528dd27c1.png

 

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" :-)

Link to post

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?

Link to post
Posted (edited)
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.

Edited by daabm
Link to post

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:

grafik.png.29c1bf2573f174ed18ccfe200cb67488.png

 

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

grafik.png.809fb803be23d8da7de1d0178bf2286c.png

 

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

Memory insgesamt sieht in dem Moment so aus:

grafik.png.645b3e61777df7694a1676cae187148a.png

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

Link to post

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

 

Link to post

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:

grafik.png.16266d5128ef2dfc7818a17c110a7984.png

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

Link to post

So, kurzes Feedback - nach einer hinreichend langen Wartezeit:

grafik.png.fe7e863ad74ccca31a649413eb14072a.png

 

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.

  • Haha 1
Link to post

@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?

Link to post

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.

 

Link to post

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...