Вам не потрібно "мати" файл сторінки на масиві жорсткого диска. Ви можете просто видалити його або встановити його на абсолютний мінімум, якщо ви хочете Crash Dumps (ОС вам скаже, коли ви зміните окремий розмір файлу сторінки на масиві жорсткого диска). Припустимо, що масив - це розташування ОС.
Це автоматично змусить записувати на SSD після використання файлу сторінки диска розділу ОС.
Наявність файлу сторінки в масиві має недоліки. Кожне написання сторінки переходить до контролера і без необхідності проходить логіку плати контролера, щоб визначити, на якому диску (их) насправді записати цю сторінку. Файл сторінки за своєю природою є тимчасовим зберіганням, тому немає жодної користі для того, щоб мати будь-який тип RAID або масив (особливо якщо доступна більш швидка підсистема, тобто SSD в цьому випадку).
Хтось може запитати "а як бути з великими кешами, знайденими на більшості контролерів масиву?" Вони не корисні для файлів сторінок, знову ж таки тому, що за визначенням те, що видається на екран, це те, що не було прочитано за деякий час, тому кеш, швидше за все, не буде доступний для читання файлів сторінки назад. SSD з вбудованим базовим кешем буде швидшим, ніж кеш масиву в цьому сценарії.
У вашій дуже конкретній ситуації (обчислення FEA) це стає дещо складним, якщо алгоритм повинен регулярно охоплювати всю виділену пам'ять. Тож тоді файл сторінки багато читається назад. У цьому випадку будь-який великий кеш на контролері "може" допомогти залежно від послідовності, в якій ваш алгоритм має доступ до пам'яті. Якщо це спричинить більше типів послідовності доступу LIFO (останній у першому), то це допоможе. Якщо це випадково, то ймовірно обмежена вигода. Якщо це FIFO (спочатку перший), то, швидше за все, це зашкодить.
Випадкові висловлювання Microsoft MVP вказують на те, що швидші диски будуть надані переваги автоматично. Хоча мої емпіричні спостереження протягом багатьох років показують, що накопичувач ОС є прихильним. Отже, наведена вище конфігурація вирішує обидва ваші проблеми.