Windows telah lama disalahkan karena lambatnya operasi file dan pembuatan proses. Pernahkah Anda mencoba membuatnya lebih lambat? Artikel ini akan menunjukkan teknik cara memperlambat proses pembuatan Windows (ad infinitum) secara tak terlihat tanpa terlihat bagi sebagian besar pengguna!

Dan tentu saja, artikel itu juga akan memberi tahu Anda cara mendeteksi dan menghindari masalah ini.

Ini adalah masalah nyata yang saya temui pada awal tahun, dan artikel itu menjelaskan bagaimana saya menemukannya dan menemukan solusinya. Artikel sebelumnya tentang memperlambat Windows:

• Memperlambat Windows, bagian 0: perlambatan sewenang-wenang dari VirtualAlloc
• Memperlambat Windows, bagian 1: akses file

Ada yang salah

Saya tidak mencari masalah, tetapi saya rasa saya menemukan mereka. Mungkin karena saya mengumpulkan Chrome dari sumber ratusan kali selama akhir pekan, atau saya tidak beruntung dalam hidup. Saya kira kita tidak akan pernah tahu. Dengan satu atau lain cara, artikel ini menjelaskan masalah serius kelima yang saya temui di Windows saat membuat Chrome.

1. Serialisasi tidak terencana, yang mengarah ke UI hang lengkap: "prosesor 24-core, tapi saya tidak bisa menggerakkan kursor . "
2. Sebuah deskriptor proses bocor di salah satu add-on Microsoft untuk Windows: "Proses zombie menghabiskan memori Anda . "
3. Kesalahan kebenaran lama dalam cache file Windows: "Compiler error? Kesalahan Linker? Bug kernel Windows. "
4. Kegagalan kinerja saat menggunakan pemberitahuan file secara tidak benar: "Memperlambat Windows, Bagian 1: akses file . "
5. Dan ini: solusi arsitektur aneh yang memperlambat penciptaan proses dari waktu ke waktu.

Pelacakan kerusakan langka

Komputer harus dapat diandalkan dan dapat diprediksi, dan hal lain mengganggu saya. Jika saya membuat Chrome beberapa ratus kali berturut-turut, saya ingin melihat setiap perakitan berhasil. Karena itu, ketika proses kompilasi terdistribusi kami (gomacc.exe) terkadang macet, saya ingin menyelidiki ini. Saya telah menyiapkan rekaman otomatis dari crash dumps , jadi saya melihat bahwa crash terjadi ketika tumpukan korupsi terdeteksi. Cara mudah untuk memeriksa adalah mengaktifkan pageheap sehingga Windows heap menempatkan setiap alokasi memori pada halaman yang terpisah. Ini berarti bahwa penggunaan-setelah-bebas dan buffer overflows menyebabkan kegagalan instan alih-alih kerusakan yang sulit didiagnosis. Saya sebelumnya menulis tentang mengaktifkan pageheap menggunakan App Verifier .

App Verifier memperlambat program karena dua alasan: alokasi memori diperlambat, dan alokasi perataan halaman praktis menonaktifkan cache prosesor. Dengan demikian, sedikit perlambatan dalam perakitan dapat diprediksi, dan itu terjadi.

Tetapi ketika saya datang kemudian, pertemuan itu tampaknya berhenti sama sekali. Setelah sekitar 7000 langkah perakitan , tidak ada kemajuan yang terlihat.

O (n ^ 2) biasanya tidak baik

Ternyata Pengesah Aplikasi suka membuat file log. Dan tidak peduli bahwa tidak ada yang menonton file-file ini, ia menciptakannya untuk berjaga-jaga. Dan file-file ini harus memiliki nama unik. Saya yakin itu sepertinya ide yang bagus untuk hanya memberikan nama numerik log dalam urutan menaik, seperti gomacc.exe.0.dat, gomacc.exe.1.dat, dan sebagainya.

Untuk mendapatkan nama numerik dalam urutan menaik, Anda perlu menentukan nomor mana yang akan digunakan selanjutnya. Cara termudah adalah dengan mencoba kemungkinan nama / angka sampai Anda menemukan satu yang belum digunakan. Yaitu, coba buat file baru bernama gomacc.exe.0.dat, dan jika sudah ada, coba gomacc.exe.1.dat dan seterusnya.

Apa yang bisa salah?

Bahkan, dalam kasus terburuk, semuanya sangat buruk

Ternyata jika Anda melakukan pencarian linear untuk nama file yang tidak digunakan saat membuat proses, maka memulai proses N membutuhkan operasi O (N ^ 2) . Akal sehat menyatakan bahwa algoritma O (N ^ 2) terlalu lambat jika Anda tidak dapat menjamin bahwa N selalu relatif kecil.

Seberapa buruk situasi akan tergantung pada berapa lama waktu yang dibutuhkan untuk memverifikasi keberadaan file. Saya melakukan pengukuran dan menemukan bahwa pada Windows dibutuhkan sekitar 80 mikrodetik (80 μs atau 0,08 ms). Memulai proses pertama adalah cepat, tetapi memulai proses ke-1000 membutuhkan pemindaian 1000 file log yang sudah dibuat. Dibutuhkan 80 ms, dan bahkan lebih.

Pembuatan Chrome yang khas mengharuskan kompiler berjalan sekitar 30.000 kali. Setiap menjalankan kompiler memerlukan pemindaian N file log yang dibuat sebelumnya, 0,08 ms untuk memeriksa setiap file. Pencarian linear untuk nama file log yang tersedia berikutnya berarti bahwa menjalankan proses N memerlukan (N ^ 2) / 2 memeriksa keberadaan file, mis. 30.000 * 30.000 / 2, yaitu 450 juta. Karena setiap verifikasi keberadaan file membutuhkan waktu 0,08 ms, ini adalah 36 juta milidetik, atau 36.000 detik. Artinya, waktu pembuatan Chrome, yang biasanya lima hingga sepuluh menit, akan meningkat sepuluh jam lagi.

Sial.

Saat menulis artikel ini, saya mereproduksi kesalahan dengan menjalankan file yang dapat dieksekusi kosong sekitar 7000 kali - dan melihat kurva O (n ^ 2) yang jelas seperti ini:



Anehnya, jika Anda mengambil jejak ETW dan melihat waktu panggilan rata-rata ke CreateFile, maka untuk hampir semua file hasilnya kurang dari lima mikrodetik (rata-rata 4,386 μs dalam contoh di bawah):



Tampaknya ini hanya menunjukkan pembatasan ETW pada penelusuran I / O file. File I / O events hanya melacak level terendah dari sistem file, dan di atas Ntfs.sys ada banyak level lagi, termasuk FLTMGR.SYS dan ntoskrnl.exe. Namun, perlambatan tidak dapat sepenuhnya disembunyikan - penggunaan CPU terlihat pada grafik Penggunaan CPU. Tangkapan layar di bawah ini menunjukkan interval waktu 548 ms, yang mewakili pembuatan satu proses tunggal. Pada dasarnya, semua waktu yang diperlukan untuk memindai sekitar 6850 kemungkinan nama file log:

Akankah disk yang lebih produktif membantu?

Tidak.

Jumlah data yang diproses kecil, dan jumlah penulisan ke disk bahkan lebih sedikit. Selama pengujian saya untuk mereproduksi bug, disk hampir idle. Masalah ini terkait dengan CPU karena semua data disk yang relevan di-cache. Dan bahkan jika biaya overhead dikurangi dengan urutan besarnya, mereka masih akan terlalu besar. Anda tidak dapat meningkatkan algoritma O (N ^ 2).

Penemuan

Masalah khusus ini dapat dideteksi dengan mencari% userprofile% \ appverifierlogs untuk file dat. Secara umum, Anda dapat mendeteksi perlambatan proses pembuatan dengan memeriksa jejak ETW, dan sekarang Anda tahu apa yang harus dicari.

Solusi

Solusi termudah adalah mematikan pencatatan. Ini juga akan berhenti mengisi disk dengan gigabytes log. Ini dinonaktifkan oleh perintah berikut:

appverif.exe -logtofile disable

Setelah menonaktifkan logging, saya menemukan bahwa proses saya mulai sekitar tiga kali lebih cepat (!) Dari pada awal pengujian, dan perlambatan benar-benar hilang. 7000 proses Verifikasi Aplikasi yang dipantau dibuat dalam 1,5 menit, bukan 40 menit. Dengan file batch sederhana saya untuk tes dan proses sederhana, saya melihat kecepatan pembuatan proses berikut:

• biasanya 200 per detik (5 ms per proses)
• 75 per detik dengan Aplikasi Verifier diaktifkan tetapi logging dinonaktifkan (13 ms per proses)
• 40 per detik dengan Aplikasi Verifier dihidupkan dan logging dihidupkan, pada awalnya ... (25 ms per proses, waktu secara bertahap meningkat hingga tak terbatas)
• 0,4 per detik setelah satu pembuatan Chrome

Microsoft dapat memperbaiki masalah ini dengan mengabaikan peningkatan jumlah file log yang monoton. Jika mereka menggunakan tanggal dan waktu saat ini sebagai nama file (hingga milidetik atau dalam resolusi lebih tinggi), mereka akan mendapatkan nama log yang lebih bermakna secara semantik yang dibuat dengan sangat cepat tanpa logika pencarian untuk file unik.

Tetapi Application Verifier tidak lagi didukung, dan file log tidak berguna, jadi matikan saja.

Informasi pendukung

File batch dan skrip untuk membuat ulang bug setelah mengaktifkan Application Verifier untuk blank.exe dapat ditemukan di sini .

Jejak ETW dari sekitar akhir percobaan ada di sini .

Tautan lain:

Data timing mentah digunakan untuk membuat grafik.

Diskusi tentang Reddit

Diskusi di Hacker News

Untuk contoh algoritma O (n ^ 2) lain yang menjajakan, lihat Quadratic Secara Tidak Disengaja

Untuk kenikmatan yang lebih duniawi, lihat kompilasi video dari 19 cara berbeda saya untuk mulai bekerja pada bulan September - saya terlalu sibuk untuk melanjutkan percobaan bulan ini.