Windows tüm RAM'i hazırda bekleme dosyasına nasıl bu kadar hızlı atabilir?


65

Microsoft Windows'ta hazırda bekleme yordamını açıklayan bir makaleden geçiyordum . Bundan kurtulmamın ana noktaları

  1. Windows, RAM'in tamamını (belki işledikten sonra) hiberfil.sysdosyaya atar.
  2. Başlatma sırasında, hazırda bekletme dosyası okunur ve içerikler RAM'e yüklenir.

Sorum şu ki, genellikle 1 GB boyutunda bir dosyayı kopyalarken 1 GB’yi tamamlamak yaklaşık 2 dakika sürüyor .

Ancak, Windows hazırda bekleme dosyasını yazarken (hazırda bekletme prosedürü sırasında), tüm işlem belki 10-15 saniye sürer. Neden yazma hızında böyle bir fark var?

RAM büyüklüğüm 4 GB. (Hızlı açılış teknolojisinden bahsetmiyorum.)

Testleri:

  1. 1 GB dosyayı Disk 1'den Disk 2'ye (harici) kopyalama: 2.3 dakika.
  2. Sistemi hazırda bekleme: 15 saniye.

3
Cevabı bilmiyorum, ama bahse girerim Windows Internals kitabını kontrol ettiyseniz "Bölüm 13: Çalıştırma ve Kapatma" size söyleyecektir (Kitabı kendim kontrol edersem).
Scott Chamberlain

2
Bu iyi bir soru. Hazırda bekleme, 1998'de ilk kez uygulandığında, neredeyse hiç hızlı değildi.
Gabe

22
@coder: NT sistemi hyberfil.sys dosyasının ayrılmış alana sahip olduğundan ve tüm dosyanın parçalanmadığından emin olun. Bu durumda, işlem sırasında sabit sürücü üzerinde kafa atlaması yoktur. Böylece 150Mo / s gibi efektif hızlara sahip olacaksınız. Ne dediğimi tekrar kontrol edebilirsin fsutil.
user2284570 9:15

3
Dış disk de genellikle iç diskten daha yavaştır.
Harry Johnston

2
@EricLippert - kesinlikle tüm RAM'leri saklamaz, ancak bu hala açıklamaz. Düzenli olarak depolanması gereken birkaç gigabayt aktif RAM'im var (VS2013 veya Eclipse + birkaç şey daha fazla ram alıyor) ve SSD olmayanların teorik yazma hızından bile daha büyük görünen hızda saklanıyorlar. sürücü.
Davor

Yanıtlar:


45

Bu muhtemelen üç kat bir cevaptır.

Burada oyunda olabilecek bir şey, uygulamalarınızı etkin bir şekilde kapatan, oturumunuzu kapatıp işletim sisteminin çekirdeğini hazırda bekleme moduna geçiren Windows'taki yeni Hybrid Shutdown. Zaten bu verilerin kaydedilmesi, potansiyel olarak "yeniden hazırda bekletme" gerekmediği anlamına gelir.

İkincisi, hazırda bekletme modunun, takas dosyasına ya da kullanımda olmayan bellek sayfalarını kaydetmesi gerekmeyecek (takas dosyasını agresif bir şekilde doldurmak ve verileri bellekte saklamak için bir neden olabilir ). .

Üçüncüsü, hazırda bekleme dosyası verilerinin de sıkıştırılmış olmasıdır . Bunu ikinci noktamla birleştirin ve yüksek oranda sıkıştırılabilir veri içeren (yürütülebilir dosyalar genellikle iyi sıkıştırılır) dışa aktarmak için yalnızca küçük bir veri kümeniz varsa, bu durumda hazırda bekletme dosyasına giden veri miktarının çalışma kümesinden daha küçük olabileceğini unutmayın. Verilerin Yorumlarda belirtildiği gibi, dosya önbellekleri ve diğer gereksiz arabellek verilerinin, hazırda bekletme dosyasına atılacak veri miktarını azaltmak için hiçbir olumsuz etkisi olmadan kolayca atılabileceğini unutmayın.

Ek olarak, mevcut sabit sürücüler oldukça hızlı. 100 MB / s sırayla sürekli yazma özelliğine sahip bir diskle, bir dakikada 4 GB RAM yazabilir (sıkıştırılmamış). Hazırda bekletme, tüm kullanıcı işlemlerini askıya aldıktan sonra ve CPU'yu askıya almadan önce son işlem olarak yapılabildiğinden, işletim sistemi genellikle diskin tam yazma hızına sahip olacaktır. Bu, basit kriterinizin sahip olamayacağı bir şeydir ve diskten diske kopyalamak, RAM'i diske yazmaktan daha yavaştır.

Bunları ve hazırda bekletme dosyasına yazılacak veri miktarını bir araya getirme potansiyeli 1 GB'ın üzerinde oldukça küçük olabilir ve büyük olasılıkla 10 saniyenin altında bir büyük sürekli bloğa yazılabilir.


37
Veya daha netleştirmek için: RAM'iniz muhtemelen dolu değil. Tamponlar temizlendi ve hazırda bekletme modundayken önbellek atıldı. Yalnızca uygulamalar tarafından gerçekten kullanılan hafıza diske yazılmalıdır. Karma kapatma, kullanıcı oturumunu kapattığında kullanılan bellek miktarını azaltır.
Daniel B,

2
Kirli olmayan sayfalar, "çalıştırılabilir dosyaya disk belleği eklenmiş" ifadesinin daha genel bir ifadesidir; bu, çalıştırılabilir dosyaları içerir. (Yürütülebilir dosyalar biraz disk üzerinde parçalandığından, bu durum uyanmayı yavaşlatabilir.) Ayrıca, temizlenmiş dosya tamponları bellek eşlemeli bir dosyanın parçası olmasalar bile muhtemelen bırakılabilir.
Paul A. Clayton

3
@ user2284570, bu cevabı verdiğim belgeden "Windows, belleği içeriğini diske kopyalayarak hazırda bekletme modunu destekler. Sistem, disk içeriğini diskte
Mokubai

4
@ user2284570: Çünkü en kötü senaryo 1: 1 sıkıştırma. Windows, herhangi bir olası bellek yapılandırması için hyberfil.sys dosyasında yeterli (ayrılmış) alan olduğundan emin olmak zorundadır - belirli bir hazırda bekleme için yalnızca RAM boyutunun onda birine ihtiyaç duysa bile. RAM kullanımının makul bir kısmının belleğe yüklenen dosyalar (çalıştırılabilir dosyalar, kaynaklar ...) olduğunu, ancak yine de HDD'den eşlendiğini ve gerçekten çok fazla yazı kaydedebileceğinizi ekleyin. Bir programın RAM’de 4 GiB kripto-rasgele veri oluşturmasını sağlayın ve hazırda bekletme modunun kullanılması daha uzun sürer - ve o zaman bile, bazıları değişmiş olabilir.
Luaan

3
@ user2284570: Diskin üzerinde tüm belleği depolamak için alan olduğundan emin olmak için dosya çok büyük. Bu boşluğun tamamı aslında hazırda bekletme modunda kullanılmıyor. Bazen dosya (diyelim)% 7 sıkıştırılmış hafıza içeriği,% 93 önemsiz olacaktır.
psm,

31

İlk olarak, kaydedilmesi gereken RAM miktarı şaşırtıcı derecede küçüktür. Aslında, yalnızca eşlenmiş kirli sayfaların ("tembel geri yazma") ayarlanması ve ayrıca çalıştırılabilir kodun üzerine yazılmış ve taşınan tüm özel sayfaların yazılması gerekir.

  • Çalıştırılabilirlerin .text kesimleri her zaman dosya eşlemesi ile desteklenir. Bu aynı zamanda en azından bazı DLL'ler için de geçerlidir (fakat hepsi değil, yeniden konumlandırılmaları gerekip gerekmediğine bağlıdır).
  • Benzer şekilde dosya eşlemeleriyle desteklenen bellek atılabilir (farenin CoW veya RW olmadığı ve kirli olduğu varsayılmıştır ).
  • Tembel geri dönüş hala gerçekleşmek zorunda kalacak, ama bunun dışında, önbellek atılabilir.
  • Tahsis edilmiş fakat yazılmamış hafıza (genellikle uygulama verilerinin büyük kısmı!) Sıfır sayfa tarafından desteklenir ve atılabilir.
  • "Bekleme" durumundaki bellek sayfalarının daha büyük kısmı (Windows'taki işlem başına çalışan asıl kişi şaşırtıcı derecede küçüktür, yalnızca 16 MB) arka planda sayfa dosyasına bir noktada kopyalanıp atılabilir .
  • Grafik kartı gibi bazı cihazlar tarafından eşlenen hafıza bölgelerinin (muhtemelen) kaydedilmesi gerekmeyebilir. Kullanıcılar bazen bir bilgisayara 8GiB veya 16GiB taktıklarına şaşırırlar ve 1GiB veya 2GiB belirgin bir sebep olmadan sadece "gitmiş" olur. Ana grafik API'leri, uygulamaların "bazı koşullar altında" tam olarak ne anlama geldiğini belirtmeden tampon içeriğinin geçersiz hale gelmesini gerektirir. Bu nedenle, grafik sürücüsü tarafından sabitlenen hafızanın da atıldığını beklemek mantıksız değildir. Sonuçta ekran yine de kararıyor.

İkincisi, bir dosyayı kopyalamanın aksine, kaydedilmesi gereken RAM sayfaları kümesini atmak, sürücünün bakış açısından tek sıralı, bitişik bir yazıdır. Win32 API , bu işlem için kullanıcı düzeyinde bir işlev gösterir . Toplama yazma, donanım tarafından doğrudan desteklenir ve diskin fiziksel olarak veri kabul edebildiği kadar hızlı çalışır (denetleyici doğrudan DMA aracılığıyla veri çeker).
Bunun çalışması için bir takım ön koşullar vardır (hizalama, blok boyutu, sabitleme gibi) ve önbellekleme ile iyi oynamaz ve "tembel geri yazma" gibi bir şey yoktur (bu normal işletimde çok istenen bir optimizasyondur) ). Her yazmanın
sebebi bu değil.her zaman böyle çalışır. Ancak, sistem hazırda bekletme dosyasını kaydederken, tüm ön koşullar otomatik olarak karşılanır (tüm veriler sayfa hizalı, sayfa boyutunda ve sabitlenir) ve bilgisayar bir anda kapatılacağı için önbellekleme ilgisiz hale geldi.

Üçüncüsü, tek bir bitişik yazma yapmak hem eğirme diskleri hem de katı hal diskleri için çok uygundur .

Takas dosyası ve hazırda bekleme dosyası genellikle diskte oluşturulan ve ayrılan en eski dosyalardan bazılarıdır. Genellikle bir, en fazla iki parçadan oluşur. Bu nedenle, sektörler zarar görmediği ve diskin fiziksel sektörleri yeniden konumlandırması gerekmediği sürece, mantıksal bir sıralı yazma, dönen bir disk üzerindeki bir fiziksel sıralı yazma anlamına gelir.

Büyük miktarda ardışık, bitişik veri yazarken, diskte okuma-değiştirme-yazma işlemi gerekmez. Bu sorun, oldukça küçük olan tek sektörler yazabilen dönen bir sabit disklerde daha az belirgindir (Önbellekleme genellikle önleyen tek baytlar yazmamanız koşuluyla, cihazın orijinal içerikleri getirmemesi ve değiştirilen sürümü geri yazması gerekir). .
Bununla birlikte, bu, her yazının örneğin bir 512kB bloğun (normal bir sayıdır, ancak daha büyük olabilir) denetleyici tarafından okunması ve değiştirilmesi ve farklı bir yere geri yazılması gerektiği anlamına geldiği SSD'de çok belirgin olan bir şeydir. blok. Prensip olarak yazabiliyorken (ancak üzerine yazamazsınız)) flash disklerdeki daha küçük üniteler, sadece büyük blokları silebilir, donanım böyle çalışır. SSD'lerin devasa sıralı yazılarda daha iyi ücret almasının nedeni budur.


Bir DLL'nin yerini değiştirmiş olsanız bile, onu geri getirmek için gereken tek şey yer değiştirilen adres. Yer değiştirme belirleyici bir süreçtir ve tekrar edilebilir.
MS’e

"Yazmayı topla" mı? "Aksine yaz" demek mi istiyorsun?
Peter Mortensen

3
@ PeterMortensen: Hayır, gerçekten toplama yazma demek (dağılımın aksine). Bu , verileri birden fazla konumdan toplarken tek bir dosyaya yazma anlamına gelir . Her biri bir başlangıç ​​adresi ve bir uzunluk (katı hizalama gereksinimleriyle) içeren bir yapı dizisi sağlarsınız. İşletim sistemi bunları denetleyiciye iletir ve donanım gerisini halleder.
Damon,

1
@ MSalters: Ancak yeniden yerleştirme sayfanın özel bir kopyasını oluşturur ve daha sonra özel kopyada başka bir değişiklik yapılıp yapılmadığını belirlemek son derece zordur. Düzeltme gerektirmeyen eşlemelere zıtlık yapın ve yazma üzerine kopya kullanın. Başka değişiklikler yapılmışsa, özel bir kopyası olacaktır. Aksi halde, sayfa hala CoW için yapılandırılacaktır.
Ben Voigt

1
@ MSalters Bu deterministik bir işlem olabilir, ancak bu hazırda bekleme kodunun, yazılım yığınının bağlayıcıyla aynı katmanında çalıştığı anlamına gelmez. Hazırda bekletme modu çekirdek katmanındaysa ve bağlanma kullanıcı katmanıysa, hazırda bekletme modu bağlayıcının yaptığı hakkında herhangi bir varsayımda bulunamaz.
kasperd

10

Tüm RAM'i hazırda bekletme zamanında terk etmez.

Zaten diskte çoğalmış olan RAM'in büyük bir bölümüne sahip olacak. Bu, yalnızca hazırda bekletme modunun hızlı bir şekilde gerçekleşmesini sağlamakla kalmaz, aynı zamanda yeni programlar için belleğin hızlı bir şekilde kullanılmasını sağlar (böylece hızlı bir şekilde başlayabilirler).

Bu nedenle sadece 4 GB'lik küçük bir kısmını yazması gerekir ve bu 10-15'lerde yapılabilir.

Gönderen microsoft :

RAM yetersiz tedarik edildiğinde (örneğin, Committed Bytes kurulu RAM'den büyükse), işletim sistemi aktif olarak kullanılmayan sanal bellek sayfalarını sayfa dosyasına kopyalayarak anında kullanım için kurulu RAM'in belirli bir bölümünü kullanmaya devam edecektir. . Bu nedenle, bu sayaç sıfıra ulaşmayacak ve mutlaka sisteminizin RAM yetersiz olup olmadığının iyi bir göstergesi değildir.


2

Yukarıdakilerin hepsine ek olarak, oyunda başka birkaç faktör olduğunu düşünüyorum.

Birincisi, bir dosyayı kopyalarken, dosyanın okunup yazılması gerektiğidir; hybernation sadece dosyanın yazılmasını gerektirir. Bu, tanımı gereği, zaten bellekte!

Bununla yakından ilişkili, bir dosyayı okurken ve aynı anda yazarken, hafızadan tasarruf etmek için, işlem şu şekildedir: bir yığın okuyun, bir yığın yazın, dizini güncelleyin (yeni boyutu göstermek için); bir yığın oku, bir yığın yaz, dizini güncelle.

Diskin bir parçasından diğerine (örneğin, dosyayı yazmak için b dosyasını okumak, dizini yazmak için b dosyasını yazmak ve dizini yazmak için dizini yazmak için), disk aramak zorunda - kafaları taşımak, kafaların oturmasını sağlayın, diskin sağ kısmının gelmesini bekleyin. Bu, katı halli bir diskin avantajlarından biridir - arama hiç zaman almaz. Hazırda bekletme modundayken, veriler uçtan uca yazılır. Hazırda bekleme (takas) dosyası önceden tahsis edilmiştir, bu nedenle dizinin güncellenmesi gerekmez (hazırda bekleme dosyasının boyutunu, yalnızca içeriği değiştirmezsiniz).

Ve son olarak, bilgisayarınız diğer tüm görevleri askıya aldı - bu SADECE yaptığı şey (bunun çok fazla fark yaratacağından şüpheliyim, ancak bazılarının yapılması zorunlu!). Bellek yönetimi ve görev değiştirme gibi şeyler bile askıya alınır.


Çok büyük bir fark yaratabilir!
Orbit'teki Hafiflik Yarışları

@LightnessRacesinOrbit: CPU çekişmesi neredeyse hiç bir fark yaratmayacak. G / Ç çekişmesinin olmaması büyük bir meseledir, ancak bu cevap zaten performans öldürme arayışının ve genel bant genişliği eksikliğinin aranmasının G / Ç çekişmesinin temel sorunu olduğunu belirtti.
Ben Voigt

@ BenVoigt: Evet, aynı fikirdeyim. Ve diskinizde bir şeyler yapmaya çalışan 40 işleminiz olduğunda, bu disk aramayı büyük ölçüde artıracaktır. (tl; dr CPU çekişmesinden bahsetmiyordum)
Orbit'teki Hafiflik Yarışları

@LightnessRacesinOrbit: Bu normal çalışma sırasında bile olağandışı görünüyor (hazırda bekletme moduna girip çıkma hariç her şey). Diske isabet eden bir arka plan görevi yakaladığımda, enayi çıkardığım ve diske yalnızca bir şey istediğimde erişen bir şeyle değiştirdiğimi biliyorum.
Ben Voigt

@BenVoigt: Bu pek mümkün görünmüyor. Daemon logging en açık olan karşı örnekdir, bunu ntpd'nin drift dosyası güncellemeleri gibi takip eder. Bu örneklerden herhangi birinin burada büyük bir etkisi olduğunu iddia etmiyorum, ancak diske özerk bir şekilde dokunmak için arka plan görevi beklemenin makul olduğunu sanmıyorum.
Orbit'teki Hafiflik Yarışları

0

Bunun nedeni RAM'in sabit diskten çok daha hızlı giriş / çıkış hızlarına sahip olmasıdır, bu nedenle RAM içindeki malzemeleri sabit diskin okuyabildiği kadar çabuk çıkarabilir.

Dosyaları kopyalarken, aynı zamanda çeşitli faktörlerle de sınırlandırılmış olursunuz - diskin hızı, aynı diske okumak ve okumak zorunda kalırsa, bağlantının sınırlı hızı (harici sürücüye ise) kontrol eder. hiçbir şeyin üzerine yazmıyor vb


9
ancak yine de işletim sisteminin I / O darboğazının yönettiği Diskteki 4GB RAM verilerini yazması gerekiyor
kodlayıcı

Ayrıca uygun parametreler olduğu varsayımıyla, hazırda bekletme modundayken Diskimin yazma hızının 40 MB / sn'den ~ 260 MB / sn'ye düştüğü anlamına gelir. Doğru olabilir mi?
kodlayıcı

1
Muhtemelen - yalnızca veriyi yazması gerektiğinden çok fazla G / Ç darboğazı olmamalıdır (muhtemelen bir şey vardır, bu yüzden bir şeyin üzerine yazmayacağını ve verilerin nereye koyacağını bilmemesi gerekir) diski çok fazla okumanız gerekiyor). (Linux dual booted) dizüstü bilgisayarımda kullanabiliyorum dd if=/dev/zero of=/tmp/output.img bs=8k count=256kve alabiliyorum 1862606848 bytes (1.9 GB) copied, 1.81605 s, 1.0 GB/s, bu yüzden mümkün gözüküyor (dosyaları kopyalamanın gereksiz yere uzun sürdüğünü düşünüyorum).
Wilf

Ayrıca, dosyaları yerel internet üzerinden kopyalarken çok daha hızlı bir transfer elde edebilirsiniz. Ayrıca RAM'deki her şeyi kopyalamanız gerekmeyebilir - RAM'deki verilerin bir kısmı yalnızca önbelleğe alınabilir ve hazırda bekletme modundan uyanırken sistemi geri yüklemek için gerekli olmayabilir.
Wilf

Sistemimdeki dd kriterini yeni denedim. Hiç bir zaman 52 MB / sn'den fazla sürmedi: / (eski makine) Ancak , "muhtemelen bir şeyin yerinde olduğunu, bu yüzden bir şeylerin üzerine yazmadığını ve verileri nereye koyacağını bilmeyerek diski okumak zorunda kalmayacağını biliyor. Çok fazla " Hızlı hızlı anahtarı var.
kodlayıcı
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.