Bagaimana Windows dapat membuang RAM lengkap dalam file hibernasi begitu cepat?

65

Saya sedang membaca artikel yang menjelaskan prosedur hibernasi di Microsoft Windows. Poin utama yang saya dapatkan adalah

Windows membuang seluruh RAM (setelah memprosesnya mungkin) dalam hiberfil.sysfile.
Selama boot up, file hibernasi dibaca, dan isinya dimuat dalam RAM.

Pertanyaan saya adalah ketika saya biasanya menyalin file ukuran, katakanlah, 1 GB, dibutuhkan sekitar 2 menit untuk menyelesaikan.

Namun, ketika Windows menulis file hibernasi (selama prosedur hibernasi), seluruh proses mungkin memakan waktu 10-15 detik. Mengapa ada perbedaan kecepatan menulis?

Ukuran RAM saya adalah 4 GB. (Saya tidak berbicara tentang teknologi boot cepat.)

Tolak ukur:

Menyalin file 1 GB dari Disk 1 ke Disk 2 (eksternal): 2,3 menit.
Hibernasi sistem: 15 detik.

windows memory hibernate

— pembuat kode
sumber

3

Saya tidak tahu jawabannya, tetapi saya bertaruh jika Anda memeriksa buku Windows Internal "Bab 13: Startup dan Shutdown" itu akan memberi tahu Anda (jika saya memiliki buku itu sendiri saya akan memeriksa).

— Scott Chamberlain

2

Ini pertanyaan yang bagus. Ketika hibernasi pertama kali diterapkan pada tahun 1998, itu tidak terlalu cepat.

— Gabe

22

@coder: sistem NT memastikan hyberfil.sys memiliki ruang penuh yang dialokasikan dan seluruh file tidak terfragmentasi. Dalam kondisi itu tidak ada kepala melompat pada hard drive selama operasi. Jadi Anda akan mendapatkan kecepatan efektif seperti 150Mo / s. Anda dapat memeriksa kembali dengan apa yang saya katakan fsutil.

— user2284570

3

Disk eksternal biasanya lebih lambat dari disk internal juga.

— Harry Johnston

2

@EricLippert - ini tentu saja tidak menyimpan semua RAM, tapi itu masih belum menjelaskannya. Saya secara teratur memiliki beberapa gigabytes RAM aktif yang perlu disimpan (VS2013 atau Eclipse + beberapa hal memakan banyak ram), dan mereka disimpan pada kecepatan yang menurut saya lebih besar daripada kecepatan tulis teoritis non-SSD saya. mendorong.

— Davor

45

Ini mungkin jawaban tiga kali lipat.

Satu hal yang mungkin berperan di sini adalah Hybrid Shutdown di Windows yang secara efektif menutup aplikasi Anda, membuat Anda log off dan kemudian melanjutkan untuk hibernasi inti dari sistem operasi. Sudah menyimpan data ini berarti tidak perlu "hibernate" secara potensial.

Hal kedua adalah bahwa hibernasi tidak perlu menyimpan halaman memori yang di-paging ke file swap atau tidak digunakan (ini akan menjadi salah satu alasan untuk secara agresif mengisi file swap dan menyimpan data dalam memori juga) .

Yang ketiga adalah bahwa data file hibernasi juga dikompresi . Gabungkan dengan poin kedua saya dan jika Anda hanya memiliki satu set kecil data untuk diekspor yang berisi data yang sangat kompresibel (executable umumnya dikompresi dengan baik) maka jumlah data yang keluar ke file hibernasi dapat jauh lebih kecil daripada set kerja data. Perhatikan bahwa, sebagaimana dinyatakan dalam komentar, cache file dan data buffer lain yang tidak perlu dapat dengan mudah dibuang tanpa efek buruk untuk mengurangi jumlah data yang akan dibuang di file hibernasi.

Selain itu, hard drive saat ini cukup cepat. Dengan disk yang memiliki penulisan berkelanjutan dalam urutan 100 MB / s Anda akan dapat menulis (tidak terkompresi) RAM 4 GB dalam waktu kurang dari satu menit. Karena hibernasi dapat dilakukan sebagai hal terakhir setelah menangguhkan semua proses pengguna dan sebelum menangguhkan CPU, OS umumnya akan memiliki kecepatan tulis penuh pada disk. Ini adalah satu hal yang tidak dimiliki oleh tolok ukur sederhana Anda, dan menyalin dari disk ke disk berpotensi lebih lambat daripada hanya menulis RAM ke disk.

Gabungkan hal-hal ini dan jumlah data yang akan ditulis ke file hibernasi bisa sangat kecil, berpotensi dari urutan 1 GB dan mungkin akan ditulis ke satu blok terus menerus besar dalam waktu kurang dari 10 detik.

— Mokubai
sumber

37

Atau, untuk membuatnya lebih jelas: RAM Anda mungkin tidak penuh. Buffer memerah dan cache dibuang saat hibernasi. Hanya memori yang benar-benar digunakan oleh aplikasi yang harus ditulis ke disk. Shutdown hibrid mengurangi jumlah memori yang digunakan dengan mengeluarkan pengguna.

— Daniel B

2

Halaman yang tidak kotor adalah pernyataan yang lebih umum dari "paged out to swap file", ini termasuk executable. (Karena executable agak terfragmentasi pada disk, ini bisa memperlambat bangun.) Selain itu, buffer file bersih mungkin bisa saja dijatuhkan bahkan jika mereka bukan bagian dari file yang dipetakan memori.

— Paul A. Clayton

3

@ user2284570 dari dokumen yang saya tautkan dalam jawaban itu "Windows mendukung hibernasi dengan menyalin konten memori ke disk. Sistem memampatkan konten memori sebelum menyimpannya pada disk, yang mengurangi ruang disk yang diperlukan hingga kurang dari jumlah total memori fisik pada sistem. "

— Mokubai

4

@ user2284570: Itu karena skenario terburuk adalah kompresi 1: 1. Windows harus memastikan ada cukup ruang (cadangan) di hyberfil.sys untuk konfigurasi memori yang memungkinkan - bahkan jika hanya membutuhkan sepersepuluh dari ukuran RAM untuk hibernasi tertentu. Tambahkan ke bahwa sebagian penggunaan RAM yang layak adalah file yang dimuat ke dalam memori (executable, resource ...), tetapi masih dipetakan dari HDD, dan Anda memang dapat menghemat banyak penulisan. Memiliki program yang menghasilkan 4 GiB data kripto-acak dalam RAM, dan hibernasi membutuhkan waktu lebih lama - dan bahkan kemudian, beberapa di antaranya mungkin telah di swap.

— Luaan

3

@ user2284570: File tersebut berukuran besar untuk memastikan ada ruang pada disk untuk menyimpan semua memori. Tidak semua ruang itu benar-benar digunakan dalam hibernasi. Kadang-kadang file akan (katakanlah) isi memori 7% terkompresi, 93% sampah.

— psmears

31

Pertama, jumlah RAM yang perlu disimpan sangat kecil. Bahkan, hanya set halaman kotor yang dipetakan ("lazeback writeback") yang perlu disiram, dan juga semua halaman pribadi yang telah ditulis ke dan dipindahkan kode yang dapat dieksekusi perlu ditulis.

Segmen .teks dari file executable selalu didukung oleh pemetaan file. Itu juga berlaku untuk setidaknya beberapa DLL (tetapi tidak semua, tergantung pada apakah mereka perlu dipindahkan).
Memori yang juga didukung oleh pemetaan file dapat dibuang (dianggap bukan CoW atau RW dan kotor).
Penulisan balik malas masih harus terjadi, tetapi selain itu, cache dapat dibuang.
Memori yang telah dialokasikan tetapi belum ditulis (biasanya bagian terbesar dari data aplikasi!) Didukung oleh halaman nol dan dapat dibuang.
Bagian yang lebih besar dari halaman memori yang berstatus "siaga" (pengaturan per-proses yang bekerja pada Windows ternyata sangat kecil, hanya 16MB) akan disalin ke file halaman di latar belakang di beberapa titik dan dapat dibuang. .
Wilayah memori yang dipetakan oleh perangkat tertentu seperti kartu grafis mungkin (mungkin) tidak perlu disimpan. Pengguna terkadang terkejut bahwa mereka menyambungkan 8GiB atau 16GiB ke komputer, dan 1GiB atau 2GiB hanya "hilang" tanpa alasan yang jelas. API grafik utama mengharuskan aplikasi dapat dengan konten buffer menjadi tidak valid "dalam beberapa kondisi" (tanpa mengatakan apa artinya ini). Dengan demikian tidak masuk akal untuk berharap bahwa memori yang disematkan oleh driver grafis juga dibuang. Lagipula layar akan menjadi gelap.

Kedua, bertentangan dengan Anda menyalin file, membuang set halaman RAM yang perlu disimpan disk adalah menulis berurutan tunggal, berdekatan dari sudut pandang drive. Win32 API bahkan memperlihatkan fungsi tingkat pengguna untuk operasi ini. Kumpulkan write secara langsung didukung oleh perangkat keras dan bekerja secepat disk secara fisik dapat menerima data (controller akan langsung menarik data melalui DMA).
Ada sejumlah prasyarat agar ini berfungsi (seperti penyelarasan, ukuran blok, penjepit), dan itu tidak cocok dengan caching dan tidak ada yang namanya "lazy writeback" (yang merupakan optimasi yang sangat diinginkan dalam operasi normal ).
Itulah alasan mengapa tidak setiap menulisbekerja seperti itu setiap saat. Namun, ketika sistem menyimpan file hibernasi, semua prasyarat dipenuhi secara otomatis (semua data disejajarkan halaman, seukuran halaman, dan disematkan) dan caching menjadi tidak relevan karena komputer akan dimatikan sebentar lagi.

Ketiga, melakukan satu tulisan yang berdekatan sangat menguntungkan baik untuk disk pemintalan dan untuk disk solid state.

File swap dan file hibernasi biasanya merupakan file paling awal yang dibuat dan dicadangkan di disk. Mereka biasanya memiliki satu, paling banyak dua fragmen. Jadi, kecuali sektor rusak dan disk harus merealokasi sektor fisik, penulisan sekuensial logis diterjemahkan menjadi penulisan sekuensial fisik pada disk pemintalan.

Tidak diperlukan operasi baca-modifikasi-tulis pada disk saat sejumlah besar data yang berurutan dan bersebelahan sedang ditulis. Masalah ini kurang diucapkan pada harddisk berputar yang dapat menulis sektor tunggal yang cukup kecil (Asalkan Anda tidak menulis byte tunggal, yang biasanya dicegah dengan cache, perangkat tidak perlu mengambil konten asli dan menulis kembali versi yang dimodifikasi.) .
Namun, ini adalah sesuatu yang sangat terlihat pada SSD di mana setiap penulisan berarti bahwa misalnya blok 512kB (yang merupakan angka biasa, tetapi bisa lebih besar) harus dibaca dan dimodifikasi oleh pengontrol, dan ditulis kembali ke tempat yang berbeda. blok. Meskipun pada prinsipnya Anda dapat menulis (tetapi tidak menimpa) unit yang lebih kecil pada flash disk, Anda hanya dapat menghapus blok besar, begitulah cara kerja perangkat keras. Ini adalah alasan mengapa SSD menjadi jauh lebih baik pada penulisan berurutan besar.

— Damon
sumber

Bahkan jika DLL direlokasi, satu-satunya hal yang diperlukan untuk mengembalikannya adalah alamat yang dipindahkan. Relokasi adalah proses deterministik dan dapat diulang.

— MSalters

"Kumpulkan menulis"? Apakah maksud Anda "Sebaliknya, tulis"?

— Peter Mortensen

3

@PeterMortensen: Tidak, maksud saya benar-benar kumpul menulis (sebagai lawan dari scatter read). Ini berarti menulis ke satu file sambil mengumpulkan data dari berbagai lokasi. Anda menyediakan berbagai struktur yang masing-masing berisi alamat awal dan panjang (dengan persyaratan pelurusan yang ketat). Sistem operasi meneruskan ini ke pengontrol, dan perangkat keras melakukan sisanya.

— Damon

1

@MSalters: Tetapi relokasi membuat salinan pribadi halaman, dan kemudian sangat sulit untuk menentukan apakah ada modifikasi lain yang dibuat untuk salinan pribadi. Kontras dengan pemetaan yang tidak memerlukan perbaikan, dan gunakan copy-on-write. Jika modifikasi lain dilakukan, akan ada salinan pribadi. Jika tidak, halaman tersebut masih akan dikonfigurasikan untuk Kontrak Karya.

— Ben Voigt

1

@ MSalters Ini mungkin proses deterministik, tetapi itu tidak menyiratkan bahwa kode hibernasi beroperasi pada lapisan yang sama dari tumpukan perangkat lunak sebagai tautan. Jika hibernasi berada pada lapisan kernel dan penautan adalah lapisan pengguna, maka hibernasi tidak dapat membuat asumsi tentang apa yang dilakukan linker.

— kasperd

10

Itu tidak membuang seluruh RAM pada waktu hibernasi.

Ini sudah memiliki sebagian besar RAM yang sudah diduplikasi pada disk. Ini tidak hanya memungkinkan hibernasi terjadi dengan cepat tetapi juga memungkinkan memori disediakan dengan cepat untuk program baru (sehingga mereka dapat diluncurkan dengan cepat).

Oleh karena itu hanya perlu menulis sebagian kecil dari 4GB dan itu dapat dilakukan dalam 10-15s.

Dari microsoft :

Ketika kekurangan pasokan RAM (misalnya, Bytes Komit lebih besar daripada RAM yang dipasang), sistem operasi akan mencoba untuk menjaga sebagian kecil dari RAM yang terpasang tersedia untuk segera digunakan dengan menyalin halaman memori virtual yang tidak digunakan secara aktif ke pagefile. . Oleh karena itu, penghitung ini tidak akan mencapai nol dan tidak selalu merupakan indikasi yang baik tentang apakah sistem Anda kekurangan RAM.

— Peter Crotty
sumber

2

Selain semua hal di atas, saya pikir ada beberapa faktor lain yang berperan.

Salah satunya adalah bahwa, ketika menyalin file, file tersebut harus dibaca dan ditulis; hybernation hanya membutuhkan file yang akan ditulis. Ini, menurut definisi, sudah ada dalam memori!

Terkait erat dengan ini, ketika membaca file dan menulisnya pada saat yang sama, untuk menghemat memori, prosesnya adalah: membaca sepotong, menulis sepotong, memperbarui direktori (untuk menunjukkan ukuran baru); baca sepotong, tulis sepotong, perbarui direktori.

Setiap kali Anda berpindah dari satu bagian disk ke yang lain (mis. Membaca file a untuk menulis file b, menulis file b untuk menulis direktori, dan menulis direktori untuk membaca potongan berikutnya) disk harus dicari - pindahkan kepala, biarkan kepala menetap, tunggu bagian kanan disk muncul. Ini adalah salah satu kelebihan dari solid state disk - mencari tidak membutuhkan waktu sama sekali. Saat hibernasi, data ditulis end-to-end. File hibernasi (swap) sudah dialokasikan sebelumnya, sehingga direktori tidak perlu diperbarui (Anda tidak mengubah ukuran file hibernasi, hanya isinya).

Dan akhirnya, komputer Anda telah menangguhkan semua tugas lain - ini adalah SATU-SATUNYA yang dilakukannya (saya ragu ini akan membuat banyak perbedaan, tetapi pasti akan membuat beberapa!). Bahkan hal-hal seperti manajemen memori dan pengalihan tugas ditangguhkan.

— AMADANON Inc.
sumber

Ini pasti akan membuat perbedaan besar !

— Lightness Races dengan Monica

@LightnessRacesinOrbit: pertikaian CPU akan membuat hampir tidak ada perbedaan sama sekali. Kurangnya pertikaian I / O adalah masalah besar, tetapi jawaban ini telah menyatakan bahwa mencari membunuh kinerja, dan mencari, bukan kekurangan bandwidth keseluruhan, adalah masalah utama dengan pertengkaran I / O.

— Ben Voigt

@ BenVoigt: Ya, saya setuju. Dan ketika Anda memiliki 40 proses yang semuanya mencoba melakukan hal-hal pada disk, itu akan secara substansial meningkatkan pencarian disk. (tl; dr. Saya tidak berbicara tentang pertikaian CPU)

— Lightness Races with Monica

@LightnessRacesinOrbit: Kelihatannya ... tidak biasa bahkan selama operasi normal (semuanya kecuali masuk dan keluar dari hibernasi). Saya tahu bahwa ketika saya menangkap tugas latar belakang mengenai disk, saya menghapus pengisap dan menggantinya dengan sesuatu yang hanya mengakses disk ketika saya meminta sesuatu.

— Ben Voigt

@ BenVoigt: Sepertinya tidak mungkin. Daemon logging adalah contoh tandingan yang paling jelas, diikuti oleh hal-hal seperti pembaruan file drift ntpd. Saya tidak mengklaim bahwa salah satu contoh tersebut memiliki efek besar di sini, tetapi saya rasa tidak masuk akal untuk mengharapkan tidak ada tugas latar belakang untuk menyentuh disk secara mandiri.

— Lightness Races dengan Monica

0

Ini mungkin karena RAM memiliki kecepatan input / output yang lebih cepat daripada hard disk, sehingga RAM dapat menampilkan barang-barang di dalamnya secepat hard disk dapat membaca.

Saat menyalin file, Anda juga dibatasi oleh berbagai faktor - kecepatan disk, jika harus membaca masuk dan keluar ke disk yang sama akan memakan waktu lebih lama, kecepatan koneksi terbatas (jika ke drive eksternal), memeriksanya tidak menimpa apa pun, dll

— Wilf
sumber

9

tapi OS masih perlu menulis data RAM 4GB pada Disk yang diatur oleh bottleneck I / O

— coder

Juga dengan asumsi parameter yang menguntungkan itu menyiratkan bahwa selama hibernasi kecepatan tulis Disk saya berubah dari 40MB / s menjadi ~ 260 MB / s. Bisakah itu benar?

— coder

1

Mungkin - seharusnya tidak ada terlalu banyak hambatan I / O karena hanya perlu menulis data (mungkin ada sesuatu di tempat sehingga tahu itu tidak akan menimpa barang dan di mana harus meletakkan data sehingga tidak perlu membaca disk terlalu banyak). Pada laptop saya (linux dual booted) yang bisa saya gunakan dd if=/dev/zero of=/tmp/output.img bs=8k count=256kdan dapatkan 1862606848 bytes (1.9 GB) copied, 1.81605 s, 1.0 GB/s, jadi sepertinya mungkin (saya akan menambahkan bahwa file-file copy windows sepertinya butuh waktu lama).

— Wilf

Anda juga bisa mendapatkan transfer yang jauh lebih cepat saat menyalin file melalui internet lokal. Mungkin juga tidak perlu menyalin semua barang dalam RAM - beberapa data dalam RAM mungkin hanya di-cache dan tidak diperlukan untuk memulihkan sistem ketika bangun dari hibernasi.

— Wilf

Saya baru saja mencoba benchmark dd pada sistem saya. Itu tidak pernah berjalan lebih dari 52 MB / s: / (mesin lama) Namun saya percaya "mungkin ada sesuatu di tempat sehingga ia tahu itu tidak akan menimpa barang dan di mana harus meletakkan data sehingga tidak perlu membaca disk terlalu banyak " Adalah kunci untuk kecepatan cepat.

— coder