Bagikan melalui

Pertimbangan penggunaan memori untuk penyetelan performa AD DS

  • Artikel

Artikel ini menjelaskan beberapa dasar Layanan Subsistem Otoritas Keamanan Lokal (LSASS, juga dikenal sebagai proses Lsass.exe), praktik terbaik untuk konfigurasi LSASS, dan harapan untuk penggunaan memori. Artikel ini harus digunakan sebagai panduan dalam analisis performa LSASS dan penggunaan memori pada pengendali domain (DC). Informasi dalam artikel ini mungkin berguna jika Anda memiliki pertanyaan tentang cara menyetel dan mengonfigurasi server dan DC untuk mengoptimalkan mesin ini.

LSASS bertanggung jawab atas manajemen autentikasi domain otoritas keamanan lokal (LSA) dan manajemen Direktori Aktif. LSASS menangani autentikasi untuk klien dan server, dan juga mengatur mesin Direktori Aktif. LSASS bertanggung jawab atas komponen-komponen berikut:

  • Otoritas Keamanan Lokal
  • Layanan NetLogon
  • Layanan Manajer Akun Keamanan (SAM)
  • Layanan LSA Server
  • Lapisan Soket Aman (SSL)
  • Protokol autentikasi Kerberos v5
  • Protokol autentikasi NTLM
  • Paket autentikasi lain yang dimuat ke LSA

Layanan database Direktori Aktif (NTDSAI.dll) berfungsi dengan Extensible Storage Engine (ESE, ESENT.dll).

Berikut adalah diagram visual penggunaan memori LSASS pada DC:

Diagram of the components that use LSASS memory

Jumlah memori yang digunakan LSASS pada DC meningkat sesuai dengan penggunaan Direktori Aktif. Saat data dikueri, data di-cache dalam memori. Akibatnya, normal untuk melihat LSASS menggunakan jumlah memori yang lebih besar dari ukuran file database Direktori Aktif (NTDS.dit).

Seperti yang diilustrasikan dalam diagram, penggunaan memori LSASS dapat dibagi menjadi beberapa bagian, termasuk cache buffer database ESE, penyimpanan versi ESE, dan lainnya. Sisa artikel ini memberikan wawasan tentang masing-masing bagian ini.

Cache buffer database ESE

Penggunaan memori variabel terbesar dalam LSASS adalah cache buffer database ESE. Ukuran cache dapat berkisar dari kurang dari 1 MB hingga ukuran seluruh database. Karena cache yang lebih besar meningkatkan performa, mesin database untuk Active Directory (ESENT) mencoba menjaga cache sebesar mungkin. Meskipun ukuran cache bervariasi dengan tekanan memori di komputer, ukuran maksimum cache buffer database ESE hanya dibatasi oleh RAM fisik yang diinstal di komputer. Selama tidak ada tekanan memori lain, cache dapat tumbuh hingga ukuran file database Active Directory NTDS.dit. Semakin banyak database yang dapat di-cache, semakin baik performa DC.

Catatan

Karena cara kerja algoritma penembolokan database, pada sistem 64-bit di mana ukuran database lebih kecil dari RAM yang tersedia, cache database dapat tumbuh lebih besar dari ukuran database sebesar 30 hingga 40 persen.

Penyimpanan versi ESE

Ada penggunaan memori variabel oleh penyimpanan versi ESE (bagian merah dalam diagram di atas). Jumlah memori yang digunakan tergantung pada apakah Anda memiliki Windows Server 2019 atau versi Windows yang lebih lama.

  • Dalam versi Windows Server yang mendahului Windows Server 2019, secara default LSASS dapat menggunakan memori hingga sekitar 400MB (tergantung pada jumlah CPU) pada komputer 64-bit untuk penyimpanan versi ESE. Untuk informasi selengkapnya tentang bagaimana penyimpanan versi digunakan lihat posting blog ASKDS berikut oleh Ryan Ries: Penyimpanan Versi Dipanggil dan Semuanya Kehabisan Bucket.

  • Di Windows Server 2019, ini disederhanakan dan ketika layanan NTDS pertama kali dimulai, ukuran penyimpanan versi ESE sekarang dihitung sebagai 10% RAM fisik, dengan minimal 400MB dan maksimum 4GB. Untuk detail hebat tentang pemecahan masalah penyimpanan versi dan ini, lihat blog hebat lainnya dari Ryan Ries: Deep Dive: Active Directory ESE Version Store Changes in Server 2019.

Penggunaan memori lainnya

Terakhir, ada kode, tumpukan, timbunan, dan berbagai struktur data ukuran tetap (misalnya, cache skema). Jumlah memori yang digunakan LSASS dapat bervariasi, tergantung pada beban pada komputer. Ketika jumlah utas yang berjalan meningkat, begitu juga jumlah tumpukan memori. Rata-rata, LSASS menggunakan memori 100 MB hingga 300 MB untuk komponen tetap ini. Ketika sejumlah besar RAM diinstal, LSASS dapat menggunakan lebih banyak RAM dan lebih sedikit memori virtual.

Batasi atau minimalkan jumlah program pada pengendali domain Anda ATAU tambahkan RAM tambahan jika sesuai

Untuk performa optimal, LSASS mengambil RAM sebanyak mungkin pada DC tertentu. LSASS melepaskan RAM itu seperti proses lain yang memintanya. Idenya adalah untuk mengoptimalkan performa LSASS sambil tetap memperhitungkan proses lain yang mungkin berjalan di komputer. Daftar program yang perlu diwaspadai termasuk agen pemantauan. Beberapa pelanggan memiliki agen terpisah untuk berbagai fungsi server yang dapat menggunakan sumber daya RAM yang cukup besar. Beberapa mungkin mengeluarkan banyak kueri WMI, yang kami memiliki beberapa detail di bawah ini.

Karena hal ini dan untuk meningkatkan performa, adalah praktik yang baik untuk membatasi atau meminimalkan jumlah program pada DC. Jika tidak ada permintaan memori, LSASS menggunakan memori ini untuk menyimpan cache database Direktori Aktif dan karenanya mencapai performa optimal.

Ketika Anda melihat bahwa DC memiliki masalah performa, perhatikan juga proses dengan pemanfaatan memori yang signifikan. Ini mungkin memiliki masalah yang perlu Anda pecahkan masalahnya. Mereka mungkin menyertakan komponen Microsoft. Pastikan Anda mengikuti pembaruan layanan terbaru—Microsoft menyertakan solusi untuk pemanfaatan memori yang berlebihan sebagai bagian dari pembaruan kualitas, yang juga dapat membantu performa DC Anda.

Ada fasilitas OS bawaan yang dapat mengonsumsi RAM signifikan tergantung pada profil penggunaan:

  • Server file. DC juga merupakan server file untuk berbagi SYSVOL dan Netlogon, kebijakan grup layanan, dan skrip untuk kebijakan dan skrip startup/logon. Namun, kami melihat pelanggan menggunakan DC untuk melayani konten file lainnya. Server file SMB kemudian akan menggunakan RAM untuk melacak klien aktif, tetapi yang terpenting, konten file akan membuat cache file OS tumbuh, dan bersaing dengan cache database ESE untuk RAM.

  • Kueri WMI. Solusi pemantauan sering membuat banyak kueri WMI. Kueri individual mungkin murah untuk dijalankan. Seringkali itu adalah volume panggilan yang menimbulkan beberapa overhead, terutama karena solusi pemantauan mengekstrak peristiwa baru dari berbagai log peristiwa yang dikelola Windows.

    Log peristiwa yang menghasilkan volume terbanyak biasanya adalah log Peristiwa Keamanan. Dan ini juga merupakan log peristiwa yang ingin dikumpulkan administrator keamanan, terutama dari DC.

    Layanan WMI menggunakan skema alokasi memori dinamis yang mengoptimalkan kueri. Oleh karena itu, layanan WMI dapat mengalokasikan banyak memori, lagi bersaing dengan cache database ESE.