Penggunaan CPU "Peaky" pada Pengontrol Domain


25

Kami memiliki dua Pengontrol Domain Windows Server 2008 SP2 (sayangnya tidak 2008 R2) di 150 klien kecil domain yang menunjukkan penggunaan CPU yang sangat "pucat". Pengontrol Domain menunjukkan perilaku yang sama dan di-host di vSphere 5.5.0, 1331820. Setiap dua atau tiga detik penggunaan CPU melonjak hingga 80-100% dan kemudian dengan cepat turun, tetap rendah selama satu atau dua detik dan kemudian melompat ke atas lagi.

Kinerja Manajer Tugas DC3


Melihat data kinerja historis untuk mesin virtual menunjukkan bahwa kondisi ini telah berlangsung selama setidaknya satu tahun tetapi frekuensi telah meningkat sejak Maret.

Kinerja Mesin Virtual DC3



Proses menyinggung adalah SVChost.exe yang membungkus klien DHCP (dhcpcsvc.dll), EventLog (wevtsvc.dll) dan layanan LMHOSTS (lmhsvc.dll). Saya tentu saja bukan ahli Windows internal tetapi saya tidak bisa menemukan apa pun terutama salah ketika melihat proses dengan Process Explorer selain tampaknya EventLog memicu satu ton panggilan RpcBindingUnbind .

Explorer Proses DC3 untuk SVCHost.exe



Pada titik ini saya kehabisan kopi dan ide. Bagaimana saya harus terus memecahkan masalah ini?


Hanya spitballing di sini: 1. Apakah Anda memiliki sistem pemantauan yang menanyakan log peristiwa di DC? 2. Apakah Anda memiliki semua jenis audit yang diaktifkan yang mungkin mengarah pada aktivitas Log Kejadian yang berat di DC?
joeqwerty

1
Ingin berpadu saat utas ini muncul di pencarian Google untuk Log Kejadian CPU Tinggi. Masalah ini masih ada di Server 2012. Baru saja menyelesaikan masalah yang sama persis di Server 2012 DC. Periksa ukuran File Log. Path log default adalah% SystemRoot% \ System32 \ Winevt \ Logs \ Opsi radio ditimpa mengalami masalah berurusan dengan ukuran file log yang lebih besar. Saya mengatur tambang untuk Mengarsipkan log ketika penuh dan terguling.
KraigM

Bagi mereka yang datang ke sini dari Google, masalah layanan Log Event ini berlaku untuk mesin Windows Server non-controller juga. Dalam kasus saya, memiliki cukup pengguna dengan mmc.exe(mungkin jendela "Server manager" default?) Juga membuka lonjakan reguler.
Nickolay

Jawaban:


25

TL; DR: File EventLog penuh. Entri Timpa mahal dan / atau tidak diterapkan dengan baik di Windows Server 2008.


Di @pk. dan saran @joeqwerty dan setelah bertanya-tanya, saya memutuskan bahwa sepertinya ada kemungkinan implementasi pemantauan yang terlupakan sedang mengikis log peristiwa.

Saya menginstal Monitor Jaringan Microsoft di salah satu Pengontrol Domain dan mulai memfilter untuk MSRPC menggunakan ProtocolName == MSRPCfilter. Ada banyak lalu lintas tapi itu semua antara RODC situs jarak jauh kami dan sayangnya tidak menggunakan port tujuan yang sama dengan proses EventLog mendengarkan. Menisik! Begitulah teori itu.

Untuk menyederhanakan berbagai hal dan membuatnya lebih mudah untuk menjalankan perangkat lunak pemantauan, saya memutuskan untuk membuka layanan EventLog dari SVCHost. Perintah berikut dan reboot Kontroler Domain mendedikasikan satu proses SVCHost untuk layanan EventLog. Ini membuat penyelidikan sedikit lebih mudah karena Anda tidak memiliki beberapa layanan yang terlampir pada PID itu.

SC config EventLog Type= own

Saya kemudian beralih ke ProcMon dan menyiapkan filter untuk mengecualikan semua yang tidak menggunakan PID itu. Saya tidak melihat banyak upaya yang gagal oleh EventLog untuk membuka kunci registri yang hilang sebagaimana diindikasikan sebagai kemungkinan penyebabnya di sini (tampaknya aplikasi yang jelek dapat mendaftar sebagai Sumber Acara dengan cara yang sangat buruk). Bisa ditebak saya melihat banyak entri ReadFile yang berhasil dari Log Kejadian Keamanan (C: \ Windows \ System32 \ WinEvt \ Logs \ Security.evtx).

ReadFile Security.evtx

Berikut ini adalah tumpukan di salah satu acara tersebut: RpcBindingUnbind

Anda akan melihat RPCBinding terlebih dahulu dan kemudian RPCBindingUnbind. Ada banyak ini. Seperti ribuan per detik. Entah Log Keamanan benar-benar sibuk atau ada sesuatu yang tidak berfungsi dengan baik pada Security.evtxlog.

Di EventViewer, Log Keamanan hanya mencatat antara 50-100 peristiwa per menit yang tampaknya sesuai untuk domain dengan ukuran ini. Menisik! Ada teori nomor dua bahwa kami memiliki beberapa aplikasi dengan audit acara yang sangat verbose dihidupkan ke kiri di sudut yang terlupakan masih patuh pergi. Masih banyak (~ 250.000) peristiwa yang dicatat meskipun tingkat peristiwa yang dicatat rendah. Ukuran log mungkin?

Log Keamanan - (Klik Kanan) - Properti ... dan ukuran log maksimum ditetapkan untuk 131.072 KB dan ukuran log saat ini ditahan di 131.072 KB. Tombol radio 'Timpa acara sesuai kebutuhan' diperiksa. Saya pikir bahwa terus-menerus menghapus dan menulis ke file log mungkin kerja keras terutama ketika itu begitu penuh jadi saya memilih untuk Menghapus Log (saya menyimpan log lama kalau-kalau kita membutuhkannya untuk audit nanti) dan biarkan layanan EventLog membuat file kosong baru. Hasilnya: Penggunaan CPU kembali ke tingkat yang wajar sekitar 5%.


Kerja bagus. Juga, pindahkan TL; DR ke atas jawaban?
Zlatko

Hanya FYI ... ini baru saja mencapai banyak pengontrol domain kami, yang sebagian besar adalah 2012/2012 R2. Jadi tampaknya sama-sama tidak diimplementasikan dengan baik di versi Windows Server yang lebih baru.
HopelessN00b

Jadi ini adalah masalah saya, TETAPI saya telah mengatur untuk arsip ketika penuh dan tidak terlalu menulis. Ukuran log maksimum adalah 1 GB dan ukuran saat ini adalah 639 MB. Bingung apa yang harus dilakukan selain mungkin menghapus log sebagai ujian. Ini pada 2008 R2 Std dan mempengaruhi PDC dan DC sekunder. Keduanya adalah VM. Saya harus mengalokasikan 2 soket / 1 inti untuk setiap DC atau mereka berdua akan mematahkan alokasi 1/1 dan tidak menanggapi lagi. Menambahkan lebih banyak RAM tidak menghasilkan apa-apa. Ini terus-menerus menggunakan antara 60-100% CPU pada saat ini.
Travis

Menyimpan / menghapus log Keamanan. Masih menjalankan 74% penggunaan CPU.
Travis

5

Anda mungkin dapat mengejar ini dengan membuat Set Kolektor Data kecil.

  • Buka Monitor Kinerja dan buat Set Kolektor Data yang ditentukan pengguna baru.
  • Pilih Manual (tanpa template) dan pilih Event trace data only.
  • Tambahkan Layanan Domain Direktori Aktif: Data inti dan simpan set.
  • Ubah Kondisi Stop di bawah Properti menjadi 1 menit.
  • Mulai set dan tunggu.
  • Setelah selesai, konversikan file .etl yang disimpan ke .csv menggunakantracerpt –l “file.etl” –of CSV
  • Analisis ringkasan.csv dan data dumpfile.csv di Excel. Anda mungkin ingin mengunduh dokumen Impor-DC-Info.xlsm ini untuk membantu Anda dengan analisis Anda.

Jika firasat saya benar, Anda akan melihat beberapa perangkat (IP: port) memalu DC Anda.


1

Tentu saja yang sulit. Selain hanya membiarkannya sendiri (1 CPU / 50% memuat .. siapa peduli?), Anda dapat mencoba mengatur pengontrol domain baru dan melihat setelah beberapa hari jika yang ini memberi Anda perilaku yang sama. Jika ya, Anda mungkin ingin mencoba dengan jejak Wireshark (jelas, ada sesuatu dari Jaringan yang menyebabkan ini)

Hal berikutnya yang terlintas dalam pikiran adalah panggilan sederhana ke microsoft


-2

Travis, "arsip" tidak membantu Anda. Bahkan, bahkan menghapus log peristiwa saat 2/3 dewasa tidak membantu Anda. Tapi "arsip" memang membantu KraigM.

kce: membersihkan file "timpa" 131MB dan melihat penurunan kinerja dari katakanlah 55% o 5% tetapi PERTANYAAN: mungkin Anda pada akhirnya akan melihat pemanfaatan tinggi lagi karena ini mungkin (a) hanya dipicu ketika kondisi penimpa tercapai atau (b) ini bisa menjadi lebih buruk secara linear karena file yang dibersihkan meningkat dari ukuran 0mb menjadi ukuran 131MB.

Beberapa melihat ini untuk security.evtx dan satu melihatnya untuk log operasional Penjadwal Tugas. Saya sarankan untuk sepenuhnya menghapus AV Anda (yang Anda gunakan) dan mencoba. Penyusup perlu menyembunyikan jejak mereka dan jejak mereka dibuat dalam tugas terjadwal yang mereka atur atau login yang mereka lakukan. Jadi mereka akan menyembunyikan jejak mereka dengan memecahkan pegangan untuk log peristiwa ini dan menulis ulang mereka untuk melewati jejak mereka. AVs mungkin mendeteksi ini dengan cara yang tidak tepat karena jika itu Microsoft, utilisasi yang lebih tinggi ini akan dilaporkan, tetapi saya hanya melihat sedikit posting ketika Googling. Saya juga melihat ini di server 2008 R2 untuk log security.evtx. Tidak ada pelanggan log peristiwa, tidak ada monitor eksternal. Saya mengamati beberapa layanan AV (McAfee) berjalan dan mereka memiliki utilisasi total yang sangat rendah untuk server hingga berhari-hari, jadi saya curiga itu sudah dihapus dan hanya sebagian saja (sepertinya perlu uninstaller khusus McAfee) dan saya bertanya-tanya apakah ada kait di vestige (atau bahkan yang biasanya diinstal) layanan McAfee atau driver filter McAfee berjalan yang entah bagaimana mengambil penulisan normal ke log peristiwa dan memutuskan dalam penyaringan mereka bahwa mereka perlu mengubahnya menjadi pembacaan penuh seluruh log peristiwa. Percayalah, driver filter pihak ketiga dari beberapa perusahaan AV buggy dan pasti 10.000x buggier daripada implementasi Microsoft event logging, yang sangat mungkin sempurna. Singkatnya, 100% copot SEMUA AV ANDA DAN MELIHAT JIKA masalah terselesaikan. Jika demikian, bekerjalah dengan perusahaan AV Anda untuk memperbaiki AV mereka. Adalah keliru untuk membuat pengecualian file untuk.

Juga, ketika menggunakan procmon, perhatikan panggilan WriteFile karena Writefile adalah apa yang akan memicu manajer filter untuk membaca seluruh file. Dalam kasus saya, pembacaan dimulai sekitar 30 detik setelah penulisan selesai yang mungkin dirancang. Tapi itu konsisten dan dalam kasus saya file 4GB dan membaca file melibatkan 64K Readfiles masing-masing panjang 64KB dan itu digunakan 35% dari CPU untuk mencapai ini. Sangat sedih.


Pembaruan 03/23/2016 Saya melihat driver filter pada mesin ini setelah menyimpulkan ini harus disebabkan oleh salah satu dari mereka (mekanisme log peristiwa tidak akan pernah bisa buggy sendiri atau jumlah laporan semacam ini akan mengejutkan dan bukan itu). Saya melihat beberapa driver filter dari AV dan dari perusahaan pihak ke-3 yang terkenal yang meningkatkan kinerja disk mesin virtual dengan membaca di depan dan bertanya kepada arsitek utama mereka (yang sangat baik dan ramah) jika produknya mungkin terlalu agresif membaca keseluruhan log peristiwa keamanan (yang jelas terjadi per procmon). Ini akan membantu untuk log keamanan yang lebih kecil tetapi tidak untuk ukuran yang dilaporkan di sini. Tidak mungkin dia berkata. Dia setuju itu mungkin AV.

Seperti yang saya katakan kepada sesama Azure di bawah ini, kami tidak memiliki tindak lanjut dari Poster asli jika masalah muncul kembali setelah membersihkan log peristiwa karena itu adalah solusi umum dan salah karena kinerja menurun dari waktu ke waktu lagi. Ini disebut "tindak lanjut" dan saya melihat sendiri solusi poster asli dapat membodohi mereka yang tidak ikut percaya bahwa mereka telah memecahkan masalah. Saya hampir tertipu juga. Saya membersihkan log peristiwa dan kinerja ditingkatkan - tapi saya menggunakan procmon dan melihat masalah akan tumbuh dan tumbuh perlahan dari waktu ke waktu hingga menjadi bermasalah. Untuk beberapa alasan, orang Azure itu dengan keras mengkritik saya ketika poster aslinya tidak ditindaklanjuti (mungkin telah meninggal, dipecat, berhenti, atau menjadi sibuk). Rekan Azure di bawah ini berpikir jika poster asli tidak ikut, itu pasti masalah yang diperbaiki. Ini menjengkelkan dan membingungkan karena saya tidak bisa memikirkan siapa pun yang sangat dihormati secara teknis yang akan mengambil posisi ini. Saya minta maaf jika saya berani. Mungkin dalam aktivisme saya di tempat lain di Internet di mana saya memanggil orang-orang keluar saya berani - di sini (serverfault) saya hanya bersikap baik dan berbagi pengetahuan teknis yang mendalam dan hasil dari Pak Azure menggertak tentang apakah kontribusi teknis saya bahkan diperlukan atau untuk beberapa blog saya (saya tidak punya blog seperti itu). Saya belum bermaksud untuk mengirim tautan ini ke sekitar setengah lusin kroni kunci di Microsoft dan bertanya kepada mereka apa yang sedang terjadi dengan jenis intimidasi dari karyawan MSFT kunci ini karena saya sangat fokus untuk memiliki kepentingan terbaik dari komunitas dalam pikiran dan tanggapan di bawah ini dari Tn. Azure, dalam beberapa kata, sulit dipercaya, tajam, mengerikan dan intimidasi - yang saya yakin sebagian orang suka lakukan kepada orang lain. Saya awalnya tersinggung tetapi saya mengatasinya dan tahu bahwa, pembaca pasif atau aktif akan menghargai apa yang saya katakan dan menghargai komentar saya - saya berdiri 100% di belakangnya tanpa memperhatikan alasan legalistik mengapa itu agak tidak pantas di sini atau tidak. M. Azure, tolong latih kebaikan dan jangan memberikan komentar saya dalam cahaya yang buruk. Lupakan saja dan tunjukkan pengekangan dan jangan berkomentar lagi. tolong berlatih kebaikan dan jangan memberikan komentar saya dalam cahaya yang buruk. Lupakan saja dan tunjukkan pengekangan dan jangan berkomentar lagi. tolong berlatih kebaikan dan jangan memberikan komentar saya dalam cahaya yang buruk. Lupakan saja dan tunjukkan pengekangan dan jangan berkomentar lagi.

Harry


Tampaknya Anda berbicara dengan orang-orang yang berkomentar, dan bukan OP dan pertanyaan awal. Dan Anda membuat saran seperti menghapus AV. OP sudah memecahkan masalah mereka, dan mengidentifikasinya sebagai masalah Log Kejadian. Saya tidak melihat ini sebagai jawaban yang valid.
David Makogon

Ini tidak terselesaikan jika Anda membaca poster dengan hati-hati dan ringkasan saya. Anda harus menderita dari masalah ini untuk mengurai kata-kata mereka jauh lebih hati-hati maka Anda lakukan dan lihat ini. Saya menyesal Anda tidak dapat melakukannya dan menghakimi saya dengan kasar. Sebagai contoh, OP mengatakan kembali ke 5% waras tetapi dengan mudah bisa kembali setelah membersihkan log dan dia tidak menindaklanjuti - sebenarnya ini terjadi pada komentator lain. Karena itu tidak ada yang terselesaikan karena dia tidak memverifikasi hasil tetap pada 5% secara permanen.
Harry

Maaf Harry - ini bukan jawaban; Anda membuat klaim perangkat lunak kereta dan memberi tahu OP untuk bekerja dengan perusahaan anti-virus mereka. Ini bagus untuk blog pribadi Anda atau artikel, tetapi editorial bukanlah jawaban, untuk pertanyaan dua tahun dengan jawaban yang diterima, dengan akar penyebab yang tidak terkait dengan anti-virus.
David Makogon

@mengherankan aku kembali ke sini lagi mencoba mencari tahu semuanya lagi :) Tidak ada AV pada sistem. Saya melakukan beberapa pembaruan windows dan mengubah file log maksimum untuk arsip ke 500 MB dari 1 GB. Bahkan pada 1 GB itu hanya berguling sekali dalam 8 bulan sedangkan DC saya yang lain berguling sedikit lebih. Saya memang mengikuti saran "SC config EventLog Type = own" untuk memecahkan file log. Setelah mem-boot ulang, proses evenlog menurun hingga di bawah 1%. "Dhcp dan lmhosts" yang dilampirkan pada proses juga di bawah 1% CPU. Saya hanya mendaftarkan sekitar 15 peristiwa keamanan / detik.
Travis

Saya menduga agen SSO yang saya jalankan ada hubungannya dengan itu karena ada banyak kesalahan tetapi menonaktifkan layanan tidak menghasilkan penurunan dalam penggunaan CPU bahkan setelah reboot. Agen SSO kembali dan CPU masih rendah jadi siapa tahu.
Travis
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.