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.
Melihat data kinerja historis untuk mesin virtual menunjukkan bahwa kondisi ini telah berlangsung selama setidaknya satu tahun tetapi frekuensi telah meningkat sejak Maret.
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 .
Pada titik ini saya kehabisan kopi dan ide. Bagaimana saya harus terus memecahkan masalah ini?
mmc.exe(mungkin jendela "Server manager" default?) Juga membuka lonjakan reguler.Jawaban:
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.
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).
Berikut ini adalah tumpukan di salah satu acara tersebut:
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%.
sumber
Anda mungkin dapat mengejar ini dengan membuat Set Kolektor Data kecil.
tracerpt –l “file.etl” –of CSVJika firasat saya benar, Anda akan melihat beberapa perangkat (IP: port) memalu DC Anda.
sumber
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
sumber
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
sumber