Priorytetyzacja pliku strony na wielu dyskach [duplikat]

8

Zarządzam serwerem Dell R710 używanym do niektórych bardzo dużych obliczeń nieliniowej analizy elementów skończonych (FEA). Czasami te przebiegi zajmą ponad 500 GB przydzielonej pamięci. Ponieważ to urządzenie ma obecnie tylko 132 GB pamięci RAM, ten dodatkowy przydział pamięci odbywa się za pomocą pliku stronicowania.

Plik stronicowania jest obecny na obracającej się macierzy dysków twardych i powoduje ogromne wąskie gardło. Zbadałem maksymalne wykorzystanie pamięci (288 GB) i dodanie 400 GB dysku SSD Intel 750 NVMe jako dedykowanego dysku pliku stronicowania. To powinno zwolnić część wąskiego gardła we / wy pliku stronicowania, ale chcę się upewnić, że nie zmaksymalizujemy pliku stronicowania i nie spowodujemy dużej awarii.

Czy brakuje mi 800 GB Intel 750 dla znanego maksymalnego rozmiaru pliku strony 864 GB (3 x 288 GB), czy mogę powiedzieć systemowi Windows, aby używał macierzy dysków twardych jako trybu failover dla dodatkowego miejsca na pagedisk? Czy jest jakiś sposób, aby ustalić priorytet dysku SSD jako podstawowego dla pliku stronicowania? Dzięki.

Dan
źródło
+1 za dobre pytanie. Zapytany również jako superuser.com/questions/446747/... ale dla Windows 7. Niestety nie ma jeszcze odpowiedzi. Jeśli otrzymamy dobrą odpowiedź na ten, który działa dla obu, mam nadzieję, że zamknę drugi jako duplikat tego.
Hennes,
co z Windows 10?
Necktwi

Odpowiedzi:

2

Nie musisz „mieć” pliku strony w macierzy HDD. Możesz go po prostu usunąć lub ustawić na absolutne minimum, jeśli chcesz Crash Dumps (system operacyjny poinformuje Cię o zmianie indywidualnego rozmiaru pliku strony w macierzy HDD). Zakładając, że tablica jest lokalizacją systemu operacyjnego.

To automatycznie wymusi zapis na dysku SSD po wykorzystaniu pliku stronicowania dysku partycji systemu operacyjnego.

Posiadanie pliku stronicowania w tablicy ma wady. Każdy zapis strony jest kierowany do kontrolera i niepotrzebnie przechodzi przez logikę płyty kontrolera w celu ustalenia, na jakich dyskach faktycznie zapisać tę stronę. Plik strony jest z natury magazynem tymczasowym, więc nie ma żadnej korzyści z posiadania dowolnego typu macierzy RAID lub macierzy (zwłaszcza jeśli dostępny jest szybszy podsystem, w tym przypadku SSD).

Ktoś może zapytać „co z dużymi pamięciami podręcznymi znajdowanymi na większości kontrolerów macierzowych?” Nie są one przydatne do pliku stronicowania, ponieważ z definicji to, co jest stronicowane, jest tym, czego nie czytano od jakiegoś czasu, więc pamięć podręczna i tak nie jest dostępna w celu odczytania pliku strony. W tym scenariuszu dysk SSD z wbudowaną podstawową pamięcią podręczną będzie szybszy niż pamięć podręczna macierzy.

W bardzo szczególnej sytuacji (obliczenia MES) staje się to nieco trudne, jeśli algorytm musi regularnie obejmować całą przydzieloną pamięć. Więc plik strony jest często odczytywany. W takim przypadku każda duża pamięć podręczna na kontrolerze może „pomóc” w zależności od sekwencji, w której algorytm uzyskuje dostęp do pamięci. Jeśli spowoduje to więcej sekwencji dostępu typu LIFO (ostatni na wejściu pierwszy), to pomoże. Jeśli jest losowy, prawdopodobnie ograniczona korzyść. Jeśli jest to FIFO (pierwsze weszło pierwsze wyszło), prawdopodobnie będzie bolało.

Losowe wypowiedzi Microsoft MVP wskazują, że szybsze dyski zostaną automatycznie uprzywilejowane. Chociaż moje obserwacje empiryczne na przestrzeni lat pokazują, że dysk OS jest preferowany. Tak więc powyższa konfiguracja rozwiązuje oba problemy.

LMSingh
źródło