Есть несколько вещей, которые следует рассмотреть и, возможно, протестировать, учитывая ваши настройки и варианты использования.
Рекомендуемое расположение разделов SWAP
Если USB HDD не очень хорошая идея, где я должен поставить какой-то своп?
Короткий ответ: да, вы можете создать раздел подкачки на жестком диске USB3, но жесткий диск на 2x750 ГБ, возможно, является самым безопасным местом для установки подкачки.
Однако вы также можете распределить и расставить приоритеты разделов подкачки по всем дискам с различным приоритетом, чтобы попробовать максимальную производительность и емкость подкачки. Если вам нравится чрезмерная оптимизация, как я, я бы порекомендовал попробовать что-то вроде следующего (для этого нужно поработать с fstab и т.д.):
- Выделите небольшое пространство раздела подкачки в массиве 2x SSD, например, 4 ГБ, с высоким приоритетом (ограниченное пространство SSD и паранойя в течение срока службы SSD являются причинами, по которым другие люди не делают этого).
- Выделите больше пространства раздела подкачки в массиве 2х жестких дисков, например, 8 ГБ, со средним приоритетом.
- Выделите еще больше места подкачки в файле подкачки на жестком диске USB3, например, 16 ГБ с низким приоритетом.
Таким образом, если системная оперативная память будет перегружена большим количеством процессов, требующих оперативной памяти и выполняющих выгрузку, нагрузка распределяется по всем дисковым устройствам. Также обратите внимание, что приоритет обмена был основан на производительности базовых дисковых систем.
Далее я попытаюсь перейти к некоторым подробным рассуждениям.
Скорость хранения, вероятно, гораздо важнее
Вы, вероятно, прочитали рекомендацию размещать своп на менее занятый или выделенный диск, но он применяется только при сравнении типов яблоки и яблоки и не является точным правилом для более сложной системы, смешивающей разные носители данных, такие как твердотельные накопители против жестких дисков и интерфейсов SATA против USB3. Для вашего случая руководящий принцип должен состоять в том, чтобы сбалансировать типы нагрузки ввода-вывода и выделить SWAP там, где вы ожидаете, что типы интерфейсов хранилища и накопители имеют лучшую свободную / свободную пропускную способность случайного ввода-вывода. Это могут быть SSD, но с оговоркой ...
USB3 HDD для SWAP
Вы упомянули в комментарии, что опция USB3 работает не очень хорошо, и, действительно, причины могут быть:
- Ваш накопитель USB3, вероятно, представляет собой однодисковую систему, в то время как ваш 2x SSD и 2x HDD с RAID должны иметь лучшую производительность, учитывая:
- RAID 0 почти удваивает производительность чтения и записи.
- RAID 1 почти удваивает производительность чтения и может снизить производительность записи на предельную величину.
- Таким образом, при условии одинаковой производительности отдельных накопителей жесткий диск USB3 был бы лучше, если бы в среднем массив SATA 2x HDD был занят 50% времени, а жесткий диск USB3 1x был занят 0%.
- И даже более того, если вы сравните обмен на одном жестком диске с двумя твердотельными накопителями, не будет никакого шанса / шанса, что он также будет работать. SSD-накопители SATA должны быть примерно на 95% занятыми, прежде чем один неактивный USB-жесткий диск начнет сравниваться ...
- USB3 будет иметь большую задержку, чем SATA. А низкая задержка является ключевым фактором производительности доступа к памяти и скорости отклика.
Внутренний массив жестких дисков для подкачки
Как указано выше, 2x жестких диска для подкачки должны быть лучше, чем 1 жесткий диск, подвешенный на USB3, и, как будет объяснено, должны быть безопасны для использования в качестве SWAP.
- Два жестких диска лучше всего подходят для больших наборов данных, которые, как правило, имеют последовательные шаблоны доступа, например, медиафайлы (музыка / видео / изображения).
- Я не уверен в настройке Intel RAID, но с Linux RAID (mdadm) я знаю, что у вас есть варианты, например:
- Вы можете использовать одни и те же диски, но сделать RAID 0 для подкачки и RAID 1 для образов / данных виртуальных машин
- Вы можете избежать накладных расходов на рейды и напрямую настроить 1-й раздел подкачки в начале каждого отдельного диска, а также настроить mdadm для создания массива из 2-го раздела на каждом диске.
- Предполагается, что магнитные носители HDD имеют лучшую долговечность записи по сравнению с твердотельными накопителями (если они не страдают от других типов преждевременного отказа ...)
- Если система много поменяется, это означает, что много записей.
SSD для обмена
2x SSD 120 ГБ отлично подходят для производительности подкачки, но срок службы SSD является фактором, на который стоит обратить внимание.
- SSD больше похожи на RAM по сравнению с вращающимися дисками и имеют гораздо лучшую поддержку случайного ввода-вывода.
- Если запущено много виртуальных машин и процессов, а оперативная память интенсивно используется, шаблоны доступа к ошибкам страниц (чтение) к разделу / файлу подкачки в конечном итоге окажутся случайными.
- Единицы выделения страницы памяти небольшие, т.е. 4 КБ
- Я предполагаю, что ядро Linux хорошо разбирается в «swapout» (освобождая некоторый ОЗУ, вынимая страницы и помещая их на диск), и делает это партиями для оптимизации для более последовательной записи на диск.
- Для 'swapin' (когда процессу нужны данные из ОЗУ, которых нет, но на самом деле это происходит из-за сбоя подкачки / страницы), это может быть довольно случайным, и именно здесь SSD может превзойти себя.
- Блог Windows 7 Engineering MDSN рекомендует использовать твердотельные накопители по количеству записей, превышающих число записей примерно в 40 раз (надеюсь, что Linux в принципе похож), что устраняет опасения по поводу слишком большого объема записи в SSD
- Даже если ваши твердотельные накопители используются для хранения вашей основной ОС и некоторых образов виртуальных машин, возможно, для операций с SWAP-файлами достаточно места. У меня 2x 128 ГБ Crucial M4 в RAID0, и они получают потрясающий последовательный ввод-вывод (почти 1000 МБ / с), а также довольно хорошую производительность произвольного чтения / записи (я измерил около 5000 IOP и 50 МБ / с на неприятном сочетании случайного чтения со смешанными размерами) в основном в блоках 4K и 16K, но до 256K).
- SSD корпоративного класса, т. Е. Основанный на более надежной технологии SLC, может обрабатывать больше циклов стирания-записи и должен подойти для замены.
- Основанные на потребителе твердотельные накопители, то есть основанные на более дешевых MLC с более высокой плотностью, могут иметь худшую, чем ожидалось, продолжительность жизни, если использование свопа становится очень тяжелым (я предполагаю, что у вас есть основанные на потребителе твердотельные накопители, учитывая сделанные вами комментарии по бюджету). Тем не менее, по крайней мере, в нормальных сценариях рабочей нагрузки на рабочем столе, я думаю, что замена на SSD не проблема.
- Когда твердотельные накопители используются полностью, производительность записи ухудшается, а проблема износа при записи и срок службы становятся еще хуже.
- Потенциально можно уменьшить ограничения стирания-записи и проблемы с производительностью записи массива SSD, выделив дополнительные ресурсы для сбора мусора SSD, чтобы высвободить непрерывные блоки записи для повышения производительности и долговечности записи.
- Предполагая, что вы ранее использовали SSD на полную мощность, операция безопасного стирания ATA может помочь обновить их, поэтому алгоритмы выравнивания износа видят полный SSD как нераспределенный.
- Просто разделите только 80-90% емкости и оставьте свободное место на конце SSD.
- Тип RAID? Если вы больше верите в надежность твердотельных накопителей и можете выделить время для восстановления из резервной копии, я рекомендую RAID0. Обратите внимание, что RAID 1 на 2 SSD технически окажет двойное влияние на срок службы записи по сравнению с RAID0 (так как он удваивает каждую запись). Так что, возможно, держитесь подальше от RAID1 ...
Другие настройки
Есть также несколько других настроек и вариантов, которые вы должны рассмотреть, учитывая проблемы поддержки нескольких виртуальных машин и т.д.
Linux любит больше оперативной памяти для кэширования ввода-вывода, а виртуализация ненавидит дисковый ввод-вывод
Потенциальные ловушки:
- Не перераспределяйте всю оперативную память гостевым операционным системам, чтобы сэкономить часть для кэширования ввода-вывода
- Найти сладкое место для «swappiness». Подкачка должна оставить некоторое место в оперативной памяти для кэширования дискового ввода-вывода, но слишком большая перестановка приведет к тому, что процессы будут выгружены слишком рано и повредят многозадачности.
Современные процессоры имеют хорошую аппаратную поддержку для виртуализации ресурсов процессора и памяти, но когда дело доходит до совместного использования дискового пространства, рабочие нагрузки виртуализации часто становятся узким местом. Linux (и Windows) могут улучшить производительность ввода-вывода, используя оперативную память для кэширования операций ввода-вывода, пока дисковые устройства SSD или HDD все еще заняты «наверстыванием». Следовательно, дополнительная оперативная память может быть полезна не только для запуска нескольких ОС, но и для кэширования операций ввода-вывода виртуальной машины.
Расположение виртуального гостевого файла подкачки
Было бы отличным решением, если бы я мог также использовать то же место для клиентов Windows vbox, чтобы переместить своп из C: туда!
Я не уверен в этом, но моя догадка:
- скорее выделите достаточно / больше оперативной памяти для каждой виртуальной машины и
позвольте linux поменяться местами и сформировать процесс виртуального ящика на хосте, как и при необходимости, посмотреть на использование всплывающего элемента управления VirtualBox Memory
- после двойной проверки звучит так, будто VirtualBox блокирует и забирает оперативную память, а ОС хоста не может вывести ее на экран
- так что вам все равно понадобится своп для виртуальных гостей
- Наличие достаточного количества ОЗУ для каждого гостя и использование раздувания памяти должно быть быстрее / лучше по сравнению с каждым отдельным гостем виртуальной машины, выполняющим собственный обмен через виртуальный ввод-вывод, который снижает производительность
- также изучите возможность установки драйверов virtio для Windows (VirtualBox поддерживает это сейчас, и RedHat имеет эти драйверы)
Сжатый обмен хранилищ
Если ваш виртуальный хост имеет достаточное количество запасных ядер ЦП, то что-то вроде zswap может работать хорошо:
- Может иметь хороший прирост производительности, если использовать 2x HDD для подкачки.
- Может не сильно повлиять на производительность при переходе на 2x SSD, но сжатие будет означать меньшее количество циклов записи.
- И подразумевает большую емкость виртуальной памяти из меньшего объема памяти
В любом случае, это может не стоить усилий, так как для этого потребуется более новое ядро, а Debian печально известен тем, что придерживается старых испытанных и протестированных ядер, поэтому это непростой вариант, если вы не создадите бэкпорт ядра или не посмотрите другой дистрибутив: например, Ubuntu 14.04 или CentOS 7 должен предлагать более свежие ядра.
Опыт сравнительного анализа
На своей рабочей станции (Windows 7) я использовал fio (http://www.bluestop.org/fio/), чтобы имитировать тенденции случайного чтения и случайного ввода-вывода, упомянутые в блоге MSDN. Любой, кто захочет проверить, что различные варианты хранения могут предложить при рабочих нагрузках файла подкачки / подкачки, может попробовать нечто подобное.
Рассматривая данные телеметрии из тысяч трассировок и сосредотачиваясь на чтениях и записи файлов подкачки, мы находим, что
- Pagefile.sys читает больше, чем pagefile.sys пишет примерно в 40 к 1,
- Размер чтения Pagefile.sys обычно довольно мал: 67% меньше или равно 4 КБ и 88% меньше 16 КБ. Записи Pagefile.sys относительно велики: 62% больше или равны 128 КБ, а 45% составляют ровно 1 МБ.
Настройка бенчмарка
Это файл работы fio, который я использовал:
[global]
description="test random read and write to estimate suitability for page file use"
filename=fakeswap
numjobs=1
iodepth=1
direct=1
sync=1
filesize=2048m
[pageout]
rw=randwrite
bssplit=64k/38:256K/15:1024K/45:4096k/2
[pagein]
rw=randread
bssplit=4K/67:16K/21:64K/10:256K/2
Поскольку в тексте сообщения блога MSDN лишь кратко упоминаются некоторые статистические данные, я сделал несколько обоснованных предположений о размерах блоков и пропорциях операций ввода-вывода для этих размеров. Я использовал опцию bssplit для взвешивания блоков разных размеров. Надеюсь, мои предположения были не так уж и плохи, учитывая, что окончательное соотношение числа операций ввода-вывода и чтения-записи, которое я получил, составило 38,5: 1, что довольно близко к 40: 1, упомянутому в сообщении в блоге.
Я провел тесты на чипсете для хранения на базе AMD SB850 и сравнил их с производительностью ОЗУ.
- Двухканальный DDR3 1600 МГц с 2 ГБ RAMDisk (с использованием продукта DataRAM RAMDisk)
- SSDx2 RAID 0 (Crucial M4 128 ГБ), NTFS
- HDDx4 RAID 10 (Seagate 7200.14 3TB), NTFS
- Флэш-накопитель ADATA UV150 USB3 32 ГБ, FAT32
Обратите внимание, что я выполнил тесты случайного чтения и произвольной записи независимо (не смешанные, но реальная система может видеть смешанные шаблоны - мне было интересно сравнить чтение / подкачку с записью / выгрузкой, поэтому я разделил ее). Например, команды, которые я использовал, были:
fio --section=pageout --output raid10_hdd4_pageout_2G.txt page2g.fio
fio --section=pagein --output raid10_hdd4_pagein_2G.txt page2g.fio
Результаты тестов
После выполнения тестов они подтвердили мое собственное подозрение, что флэш-накопитель USB3 (обратите внимание, не жесткий диск на USB3) может работать довольно хорошо при небольшом случайном вводе-выводе. Однако оказывается, что это не так хорошо для больших блоков случайной записи с очень неустойчивым временем задержки.
На следующем графике показано время, затрачиваемое на постраничное и обратное размещение в 2G пространства подкачки с репрезентативными / оценочными шаблонами случайного ввода-вывода для подкачки
Я также посмотрел на среднюю пропускную способность и сравнил ее с оперативной памятью - это дает представление о том, как плохо обстоят дела, когда системе приходится использовать своп ;-)
Дальнейшие наблюдения
- Случайный ввод-вывод имеет большее значение, чем случайный ввод из-за меньшего размера блока и большего количества операций ввода-вывода. Пропорционально, pagein более болезнен, чем pageout ...
- SSDx2 RAID 0 был примерно в 10 раз медленнее, чем RAM
- HDDx4 RAID10 выглядит ужасно на странице - примерно в 300 раз медленнее, чем RAM, и в 30 раз медленнее, чем SSD.
- Тем не менее, HDDx4 RAID10 выглядит относительно лучше при выводе страниц - примерно в 40 раз медленнее, чем ОЗУ, и только примерно в 4 раза медленнее, чем SSD
- Флэш-накопитель USB3 был намного лучше при небольших случайных операциях чтения по сравнению с жестким диском RAID (~ в 9 раз быстрее), настолько, что восполнял то, насколько плохой он был при произвольной записи (~ в 7 раз медленнее). Даже если он подключен к порту USB 2, он в целом превосходит RAID-массив жесткого диска.
ВНИМАНИЕ - не рекомендуется помещать файл подкачки / файла подкачки на USB-накопитель
- На NAND-накопителе и контроллере USB-накопителя может отсутствовать надежное выравнивание износа и реализация сборщиков мусора (например, невозможно использовать команду SSD ATA TRIM), что повышает вероятность того, что при использовании для файла подкачки / файла подкачки он будет иметь короткий срок службы и снижение производительности с течением времени. Мои тесты были на свежей / новой флешке. Может быть, после 6 месяцев обмена с ним, он не будет поддерживать производительность и преждевременной смерти.
Последние несколько заметок
- Мои SSD и HDD имеют довольно большой кэш. 256 МБ и 64 ГБ соответственно на каждом устройстве, так что это, вероятно, дает им толчок, в то время как на флеш-накопителе USB этого, вероятно, нет.
- Я не уверен, насколько хорошо замечание, сделанное M $ относительно использования файла подкачки Windows, применимо к разделу или файлу подкачки в Linux, но держу пари, что это не за горами ...
Рекомендации
Больше чтения (извините, выложил бы больше ссылок, но я только что зарегистрировался, и суперпользователь мне еще не доверяет)
