PrimoCache (aka FancyCache) — [7] :: Программы :: Компьютерный форум rpilot62.ru

← Вернуться в раздел «Программы»

Страницы: 123

Предыдущая тема: Трансляция картинки с ноута на телик независимо от ноута


Форум Ru-Board.club — поднят 15-09-2016 числа. Цель — сохранить наследие старого Ru-Board, истории становления российского интернета. Сделано для людей.

» PrimoCache (aka FancyCache)

Автор: DefenderDf
Дата сообщения: 28.07.2013 01:12


Сайт программы:www.romexsoftware.com


PrimoCache
PrimoCache программное обеспечение призванное увеличить скорость обращения к жёсткому диску, путём создания кэша (в оперативной памяти) между файловой системой и операционной.

Ключевые особенности:
Поддержка LRU (наиболее давно использовавшийся) и LFU (наименее часто используемых) алгоритмы кэширования
Поддерживает стратегии кэширования: Read/Write, Read-Only и Write-Only
Поддерживает технологию отложенной записи на диск
Поддерживает память свыше 4Гб в 32 разрядных ОС и SSD накопители для кэша второго уровня
Поддерживает кэширование томов и дисков
Поддерживает TRIM команду для SSD накопителей
Поддержка визуального монитора производительности
Поддержка plug and play устройств
Поддерживает основной и дополнительный разделы
Поддерживается точка соединения NTFS
Поддержка распределённых файловых систем

Поддерживаемые ОС: Windоws XP/Vista/7/8/8.1/10 (x86/x64) / Windоws Server 2003(R2)/2008(R2)/2012(R2) (x86/x64)

Скачать PrimoCache v2.5.0 (60 дней) от 2016-08-19

Похожие программы:
eBoostr
SuperSpeed SuperCache

Автор: WatsonRus
Дата сообщения: 28.07.2013 11:41
Цитата:

(90 дней)

Уже 90 стало? Еще недавно давали 180.

Добавлено:
Добавил в шапку ссылку на смежный топик в Варезнике.

Автор: PREVED
Дата сообщения: 28.07.2013 13:07
Поверхостное описание работы утилиты на официальном сайте как-то не убеждает в увеличении производительности по сравнению со встроенным дисковым кэшем в Win7.

Хотелось бы подтвержденных тестов и замеров в доказательство эффективности данного решения.

Автор: WatsonRus
Дата сообщения: 28.07.2013 18:46
PREVED
Во всяких сборках Винды на внешних USB HDD или особенно флешках, выигрыш есть.

В стационарной Винде ИМХО нафиг не нужно.

Автор: ProkVS
Дата сообщения: 28.11.2013 15:41
Интересно, а файл подкачки тоже кэширует, к нему-то чаще всего идет обращение!?Актуально было бы при 32х разрядных ОС свыше 4гб оперативки..
Если файл подкачки и все кэши, то получается эта прога — смерть всем рамдискам!?
Кто нибудь может предположить чем лучше рамдиск или вариант совместного использования с сабжем?
Автор: dimka11gg
Дата сообщения: 03.07.2014 18:56
Как оживить fancy cache? trial expired и все…

Добавлено:
PrimoCache не устраивает по функциональности, посоветуйте алтернативу

Автор: DefenderDf
Дата сообщения: 19.07.2014 14:08
SuperCache аналогичная по функционалу тулза
Автор: dreamReckless
Дата сообщения: 21.10.2014 19:16
Все таки что лучше — PrimoCache или SuperCache?

Пробовал устанавливать на Windows XP -все ок. Но на Windows 7 что-то не работает, и в чем дело понять не могу. Все делаю вроде бы правильно (настраивал как http://shte.ru/programu/primocache-kesh-dlya-zhestkogo-diska-vyidelennyiy-iz-ozu).

у кого были подобные проблемы и еще — какой софт может помешать работе программы?

Добавлено:
и у кого большой обьем памяти — напишите как работает ваша windows при кеше от 2 gb, мне кажется что она должна очень быстро работать — напишите. Особенно у кого windows 7.

Автор: dreamReckless
Дата сообщения: 09.11.2014 09:58
Ребята, у меня к вам вопрос.

Программа действительно видит то что не может видеть система?

Хочу поставить Windows XP на компьютер с 16 гб ОЗУ.

Смогу ли я создать кеш из 12 гб?)

Спасибо!

Автор: RTX
Дата сообщения: 09.11.2014 12:05
Цитата:

Хочу поставить Windows XP на компьютер с 16 гб ОЗУ. Смогу ли я создать кеш из 12 гб?)

Да.

Автор: ekun
Дата сообщения: 22.08.2015 11:22
Что за фигня, поставил программу а она не видит диски которые надо кешировать?
Автор: zlin9
Дата сообщения: 04.09.2015 16:39
ekun

Цитата:

Что за фигня, поставил программу а она не видит диски которые надо кешировать?

Диски обычные или какие то программные , виртуальные ?

Добавлено:
Заметил такой косяк при использовании PrimoCache : Игра Сталкер ТЧ при запуске даёт многократную ошибку :
Точка входа в процедуру CreateDXGIFactory2 не найдена в библиотеке DLL C:\WINDOWS\SYSTEM32\d3d11.dll

Предполагаю , что подобные ошибки могут давать и другие игры. И дают видимо на компьютерах , где возможно изменены параметры кэширования по сравнению с оригинальными настройками.

Получается , что библиотека не попадает в кэш , созданный PrimoCache.

Автор: sergEO7905
Дата сообщения: 24.09.2015 00:10
от этой программы какой нибудь толк вообще есть? Чего то поюзал 2 недели, но разницы так и не ощютил.
Автор: ALEX666999
Дата сообщения: 24.09.2015 15:18
Оттестенные глюки: при кешировании системного диска — ошибки, неустранимые до перезагрузки,
при кешировании несистемного диска и попытке помещения в спящий режим/возврате из спящего режима
(гибернация включена) — ошибки.

Т.е. толку от кряжика "включить поддержку гибернации" при кешировании — ноль.
Есть смысл только для виртуальных дисков, основанных на невидимой памяти.

На версиях до 2.1.0 тестил.

sergEO7905

Есть. Если дофига памяти, то можно кешировать частоиспользуемые файлы/папки.
В этом случае: во-первых, не "насилуется" диск (при раздаче популярного файла, допустим);
во-вторых, доступ ускоряется до мгновенного, что актуально для владельцев стареньких винтов,
где все идёт с "хрустом" и вялым темпом.

Пробовал аналогичную прогу — неудобный интерфейс и закешировать
с невидимой памятью нормально так и не вышло. Если ромексовцы допилят свою — будет чудесно.

Автор: YaMarchu
Дата сообщения: 26.09.2015 19:20
У меня были проблемы с разными глюками и зависанием Win7x32 с 4 ГБ ОЗУ, при попытке использования "невидимой памяти". Всё дело в том, что встроенная в чипсет графика "ATI Radeon HD 4200" отнимала 256 МБ памяти — как раз из той самой "невидимой" для системы области за пределами 3,25 ГБ. В результате, когда для PrimoCache выставлялся размер кэша равный размеру "невидимой области" — получался конфликт с тем участком памяти, где хранила свои данные видеокарта.

Проблему решил изменением UMA Location в значение Below в BIOS. После этого всё заработало как положено и без сбоев. Сейчас благополучно используется вся доступная "невидимка" размером 764 МБ. Кэш задействован для 2-х разделов: системного [C:], и с разным портативным софтом [D:]. Скрин

Подробнее на эту тему, можно почитать в базе знаний, тут:

http://www.romexsoftware.com/en-us/knowledge-base/unified-invisible-memory-management-interface.html

Цитата:

If "UMA Location" option in BIOS is set to "Below", VGA shared memory uses OS managed memory. In such scenario, it has no conflict with UIMMI. However if "UMA Location" is set to "Above", VGA shared memory will use back-end Invisible Memory.

Добавлено:
Да, к слову.. для избежания конфликта между данными видеокарты и кэша в "невидимой области" ОЗУ — изменять значение UMA Location в BIOS вовсе не обязательно!

Можно просто попробовать задать значение Reserve front-end Invisible Memory или Quota… в настройках PrimoCache, в зависимости от размера данных видеоядра и места их хранения в IM: в начале — "Front-end", или в конце — "Back-end".

Всё это расписано по ссылке выше.

Автор: haydeGen
Дата сообщения: 20.11.2015 07:21
Автор: maratasgard12
Дата сообщения: 29.11.2015 00:56
Нашел более менее вменяемое описание новых версий http://shte.ru/novyiy-primocache-2-0-eto-super-kesh-dlya-tvoego-diska.html

Добавлено:
Помогите разобраться.
Человек пишет http://shte.ru/primocache-kesh-dlya-zhestkogo-diska-vyidelennyiy-iz-ozu.html, что в v1.01 «первый запуск программы всегда будет как обычно — ведь в кеше пусто».
А в v2.1.0 http://shte.ru/novyiy-primocache-2-0-eto-super-kesh-dlya-tvoego-diska.html возможна «загрузка прошлого кэша при запуске системы (Prefetch Last Cache)»
Но я заметил одну особенность при работе с v1.01 – каждый раз при включении и перезагрузке, запуск всех программ и служб при старте намного(!) быстрее, чем без PrimoCache. А поле Free Cache – имеет примерно такое же значение, что и до завершения работы. Но по-идеи, кеш должен был освободиться.
Получается, при завершении работы системы кеш PrimoCache куда то записывается из оперативки для хранения? И если это SSD, то на него?!

Автор: Levvon
Дата сообщения: 29.11.2015 09:27
В режиме RAM-only кэша ссылки на наиболее востребованные системой файлы (блоки) пишутся в файл pf# в папку prefetch с установленной программой, где # — номер задачи.

В режиме, когда SSD выступает в роли L2-кеша, помимо описанного выше, непосредственно сами файлы (блоки) пишутся на SSD.

Лёгкая задержка при загрузке связана со считыванием файла prefetch и помещение файлов (блоков), на которые он ссылается, в RAM-кэш.

Автор: maratasgard12
Дата сообщения: 29.11.2015 15:06
спасибо за пояснения, но
prefetch системы у меня выключена,
папки prefetch в PrimoCache не имеется,
файла\ов pf* в папке prefetch с установленной программой, естественно, нет.

Система грузится намного быстрее. Никакой лёгкой задержки при загрузке.

Автор: vasevase
Дата сообщения: 18.12.2015 10:10
Цитата:

Т.е. толку от кряжика "включить поддержку гибернации" при кешировании — ноль.

Похоже оно работает только в Primo Ramdisk, в PrimoCache — нет.
У них на скриншотах досупна данная галка, а в самой проге — нет. На форуме игнорируют вопрос по этой теме.
Сейчас вышла версия 2.20, надо попробовать, может есть какие-то инновации…

Автор: BezPoniki
Дата сообщения: 02.03.2016 20:07
Есть вопрос, связанный с данной программой. У меня Win7 x64, установил ее только из-за того, что х32 не видела более 2,3 ГБ. Но вот в чем проблема: 64-битная ОСь тоже не видит всех 4Гб, а только 3,82! Не критично, но все же жаба давит за недоступную память. Я тут мимо проходил, да и узнал об PrimoCache, которая, судя по описанию, может адресовать недоступное операционке пространство. Собственно, вопрос: смогу ли я задействовать неиспользуемые 184 МБ ОЗУ, используя данную программу? Ноут у меня бюджетный, с самым дешевым хардом, поэтому ускорить его было бы, мягко говоря, не лишним.

Благодарю.

ЗЫ
Мог бы, конечно, сам поставить и узнать, но вдруг на форуме чего интересного всплывет, помимо ответа?

Автор: vasevase
Дата сообщения: 02.03.2016 20:20
BezPoniki
В настройках биоса материнки есть опция а-ля «Enable PAE» или «Memory Remap Feature».
Скорее всего у вас оно не стоит. Удачи.
P.S. На 64-битке без Primo должно увидеть всю память.
Автор: BezPoniki
Дата сообщения: 02.03.2016 21:21
vasevase, спасибо за оперативный ответ. К сожалению, у меня в биосе (Insyde Bios 2.16) только функции установки ahci-ide, выбор приоритета загрузки носителя, установки даты\времени, пароля, пара левых функций вроде network boot и просмотр инфы о железе. Короче, практически нечего настраивать.

Предыдущий вариант с задействованием неиспользуемой памяти через PrimoCache прокатит?

Автор: vasevase
Дата сообщения: 02.03.2016 21:31
Цитата:

BezPoniki: практически нечего настраивать

UPD: прошу прощения, ошибся я. С ноутом-то конечно нечего.

Цитата:

неиспользуемой памяти через PrimoCache прокатит

Можно через их же прожку RamDisk. Только я "сванговать" результат не могу, надо ставить и смотреть.

Автор: BezPoniki
Дата сообщения: 02.03.2016 23:06
Автор: YaMarchu
Дата сообщения: 02.03.2016 23:59
BezPoniki
Цитата:

64-битная ОСь тоже не видит всех 4Гб, а только 3,82!
смогу ли я задействовать неиспользуемые 184 МБ ОЗУ, используя данную программу?

Скорее всего, этот объём в 184 МБ зарезервирован системой для данных видеоядра, если графика встроенная.

Автор: vasevase
Дата сообщения: 03.03.2016 00:15
С ноутом я дал маху — почему-то сразу про системник подумал (не по шарам).
Конечно, там-то какие настройки. YaMarchu, вы правы, так и есть с видюхой, с 99% вероятностью.
Автор: BezPoniki
Дата сообщения: 03.03.2016 13:01
Вот оно как… Практически точно, так и есть. Посмотрел на паре других ноутов, там ситуация та же, но их владельцы недосчитались около 500 мб. Вопрос немного не по теме, если у меня встроенная видюха резервирует 180 мб, а у других — 500, это хорошо или плохо?

Скорее все же первый вариант т.к. системе больше остается, но может у меня просто слабая интеграшка по сравнению с другими?

Автор: YaMarchu
Дата сообщения: 03.03.2016 16:37
Ну, например, у меня на десктопе 6-ти летней давности: чипсет AMD 785G с интегрированной графикой ATI Radeon HD 4200 — отнимает 256 МБ из ОЗУ. В игры практически не играю, а так.. для основных потребностей, в т.ч. просмотра HD видео через PotPlayer с кодеками DXVA — вполне хватает.
Автор: BezPoniki
Дата сообщения: 03.03.2016 19:41
YaMarchu, спасибо, одной загадкой стало меньше. А прогу я все равно потестю

Здравствуйте, дорогие друзья! Сегодня хочу немного поговорить об SSD дисках и хранении данных. Есть много статей на эту тему, но я хочу затронуть тему чуть более специфическую, а именно: «Использование SSD дисков для кэширования данных в СХД».

Какие бывают SSD?

Разновидностей SSD-дисков немало, они отличаются друг от друга по следующим параметрам:

  • типу подключения: SATA, SAS, U.2 NVME, PCI-e NVME;
  • типу флеш-памяти: SLC, MLC, TLC и т.п.;
  • классу: для корпоративного или домашнего использования;
  • объему: от 128 ГБ до нескольких ТБ;
  • гарантированному сроку службы;
  • по скорости доступа на чтение и запись.

Это всего лишь несколько отличительных характеристик, которые важны для выбора SSD-дисков для СХД, в том числе и для целей кэширования.

Как выбирать?

Как я уже писал в предыдущей статье про подход к выбору СХД, в зависимости от вашей задачи на СХД будет создаваться различная нагрузка, которая трансформируется в непосредственную нагрузку на носители. Поскольку носители могут быть организованы в разные RAID-структуры, трансформация вашего входного паттерна нагрузки в непосредственную нагрузку на носитель может быть далеко не прямой. Например, при работе с RAID 5, 6, 7, N+M запись на диски ведется чанками, которые не соответствуют размеру блоков, которыми «пишет» инициатор. При модификации части такого чанка необходимо его перечитать, модифицировать и записать обратно.

Если речь идет о случайной записи, то на RAID четности количество записей будет гораздо большим, то есть одна операция ввода-вывода (IO) вызывает аналогичную операцию на всех дисках RAID. Если вы работаете с RAID 0 или 10, нагрузка будет трансформироваться в нагрузку на диски более прямолинейно. Одна IO на массив будет вызывать одну IO на диск в случае RAID 0, и по одной IO на два диска в случае RAID 10.

Кроме того, запись на SSD-диск осуществляется не совсем так, как на вращающийся. Логическая адресация ячеек памяти, доступная пользователю (local block addressing; LBA), не соответствует физической. Если записать один блок данных, а потом еще один, то об их физическом размещении будет «знать» только контроллер диска. Для операционной системы это процесс прозрачный, так как она будет оперировать своими стандартными LBA.

Как известно, физически запись на SSD-диск осуществляется страницами, а очистка – erase-блоками, причем в одном erase-блоке обычно содержатся сотни страниц. Например, страница размером 8KБ и блок размером 1024КБ. Запись на SSD всегда ведется кратно размеру страницы, то есть, если вы записали 4К, вторые 4К страницы останутся не заполнены. При записи следующих 4К будет занята следующая страница.

При перезаписи данных на SSD новые данные пишутся на свободное место, а старые данные помечаются как удаленные.

При работе контроллер диска периодически запускает «сборку мусора», при которой фактически дефрагментирует данные на SSD. Контроллер берет частично пустые страницы и записывает данные в новые страницы, и только когда erase-блок содержит исключительно удаленные или перенесенные данные, он может быть переиспользован для записи данных. Причем для этой операции SSD обычно использует специальный запас свободного места. Чем больше этот запас и менее заметно влияние процесса «сборки мусора» на производительность, тем выше класс SSD и его стоимость.

Один из ключевых параметров SSD – это поддерживаемое количество перезаписей в день. «Упражнение», которое необходимо будет выполнить при выборе твердотельного диска для кэширования, состоит как раз в вычислении среднего количества перезаписей кэша на SSD-носитель, которые будут генерироваться вашей нагрузкой.

Каков же будет паттерн нагрузки на кэширующий SSD? Тут логика проста. При записи на SSD правильно использовать лог-структурированную запись. Это позволяет снизить износ самого диска и нагрузку на «сборщик мусора», зашитый в контроллер диска. В итоге нагрузка будет следующего вида:

  • Последовательная запись (за счет лог-структурированной записи) комфортными для SSD блоками;
  • Случайное/последовательное чтение. Размеры блоков следует анализировать в зависимости от приложения: обычно это 2-16K в случае транзакционных приложений. Перезаписи при этом не происходит, но, если запрашиваемые данные кэшируются, они также вызывают запись на кэширующий SSD.

Количество перезаписей будет в простейшем случае приблизительно соответствовать общему объему считанных и записанных случайных данных, поделенных на полезный объем диска.

Таким образом, получается, что кэширующий SSD подвергается довольно высокой нагрузке, но при этом может значительно повысить быстродействие системы.

Выводы:

  • SSD диск для кэширования должен поддерживать нужное вам количество перезаписей в день, при этом обычно под кэширующие SSD надо выбирать SSD enterprise-класса с большим количеством перезаписей в день – около 10.
  • Для эффективной работы SSD-кэша вместимость диска должна позволять хранение необходимого объема данных для записи с учетом скорости вытеснения данных на основное хранилище. То есть большой поток случайных данных на запись не должен переполнить диск SSD-кэша по мере вытеснения данных в основное хранилище.
  • Кроме того, с учетом вышесказанного, диск должен параллельно располагать нужным объемом для хранения локальностей для случайного чтения (одни и те же области данных, которые регулярно запрашиваются случайным образом).
  • SSD не должен быть узким местом в системе по показателям скорость записи. Отдельный твердотельный диск или группа SSD, объединенная в RAID, должна позволять записывать и считывать данные с необходимой скоростью (в IOps).

В RAIDIX 4.4 уже есть возможность использовать SSD-кэширование случайного чтения. В RAIDIX 4.5 будет также доступна опция SSD-кэширования случайной записи, что позволит улучшить производительность при работе со смешанными и случайными паттернами. В этой же версии мы планируем использовать SSD не только для кэширования, но и в качестве основного носителя информации.

Следите за нашими обновлениями и техническими новинками!

Это может быть немного не по теме для строго программирующего сайта, но я заинтересован в запуске программного проекта или в создании существующего проекта, который может делать то, что я предлагаю.

Теперь, когда SSD-хранилище становится все более популярным, меня больше интересует использование его на моем компьютере с декомпрессией. Так как они очень дороги для Gigabyte по сравнению со стандартными дисками, я должен ограничить размер диска.

Я хочу максимизировать использование, но не могу разместить на нем все мои данные.

То, что я хотел бы сделать, — использовать SSD как невидимый встроенный кеш для остальных моих данных без явного хранения данных на нем. Поскольку данные считываются с моего обычного диска, он кэшируется на SSD. Весь последующий доступ к этим файлам будет извлекаться из SSD, и любые изменения будут распространяться на более медленный диск. Пользователь никогда не увидит SSD в своем списке дисков.

Таким образом, при первом доступе к файлу он может быть немного медленнее обычного, но с этого момента он будет намного быстрее. Очевидно, через некоторое время SSD пополнится, и менее часто используемые файлы могут быть освобождены, чтобы освободить место.

Существуют ли какие-либо файловые системы, которые позволяют что-то вроде этого, или возможно ли, что драйвер низкого уровня выполняет работу между ОС и файловой системой?

filesystemscachingmemorydrivessd

задан Tim Rupe 18 июня '09 в 17:52

источникподелиться

Большинство серверных приложений работают с дисковой подсистемой сервера в режиме случайного доступа, когда данные читаются или записываются небольшими блоками размером несколько килобайт, а сами эти блоки могут располагаться в дисковом массиве случайным образом.

Жесткие диски имеют среднее время доступа к произвольному блоку данных порядка нескольких миллисекунд. Это время необходимо для позиционирования головки диска над нужными данными. За одну секунду жесткий диск может прочитать (или записать) несколько сотен таких блоков. Этот показатель отражает производительность жесткого диска на случайных операциях ввода-вывода и измеряется величиной IOPS (Input Output per Second, операций ввода-вывода в секунду). То есть производительность случайного доступа для жесткого диска составляет несколько сотен IOPS.

Как правило, в дисковой подсистеме сервера несколько жестких дисков объединяются в RAID-массив, в котором они работают параллельно. При этом скорость операций случайного чтения для RAID-массива любого типа возрастает пропорционально количеству дисков в массиве, а вот скорость операций записи зависит не только от количества дисков, но также и от способа объединения дисков в RAID-массив.

Довольно часто дисковая подсистема является фактором, который ограничивает быстродействие сервера. При большом количестве одновременных запросов дисковая подсистема может достичь предела своей производительности и увеличение объема оперативной памяти или частоты процессора не даст никакого эффекта.

Радикальным способом увеличения производительности дисковой подсистемы является использование твердотельных накопителей (SSD-накопителей), в которых информация записывается в энергонезависимую flash-память. У SSD-накопителей время доступа к произвольному блоку данных составляет несколько десятков микросекунд (то есть на два порядка меньше, чем у жестких дисков), благодаря чему производительность даже одного SSD-накопителя на случайных операциях достигает 60’000 IOPS.

На следующих графиках приведены сравнительные показатели производительности RAID-массивов из 8-ми жестких дисков и 8-ми SSD-накопителей.

Приведены данные для четырех различных типов RAID-массивов: RAID 0, RAID 1, RAID 5 и RAID 6.

Чтобы не перегружать текст техническими подробностями, информацию о методике тестирования мы поместили в конце статьи.

Из диаграмм видно, что применение SSD-накопителей повышает производительность дисковой подсистемы сервера на операциях произвольного доступа от 20 до 40 раз. Однако широкому использованию SSD-накопителей мешают следующие серьезные ограничения.

Во-первых, современные SSD-накопители имеют небольшую емкость. Максимальная емкость жестких дисков (3TB) превосходит максимальную емкость серверных SSD-накопителей (300GB) в 10 раз. Во-вторых, SSD-накопители примерно в 10 раз дороже жестких дисков, если сравнивать стоимость 1GB дискового пространства. Поэтому построение дисковой подсистемы из одних только SSD-накопителей в настоящее время применяется довольно редко.

Однако можно использовать SSD-накопители в качестве кэш-памяти RAID-контроллера. О том, как это работает и что дает, давайте поговорим подробнее.

Дело в том, что даже в довольно большой дисковой серверной подсистеме емкостью в десятки терабайт объем «активных» данных, то есть данных, которые используются наиболее часто, относительно невелик. Например, если Вы работаете с базой данных, которая хранит записи за длительный период времени, активно использоваться скорее всего будет только небольшая часть данных, которая относится к текущему временному интервалу. Или если сервер предназначен для хостинга Интернет-ресурсов, большая часть запросов будет относиться к небольшому числу наиболее посещаемых страниц.

Таким образом, если эти «активные» (или «горячие») данные будут находиться не на «медленных» жестких дисках, а в «быстрой» кэш-памяти на SSD-накопителях, производительность дисковой подсистемы возрастет на порядок. При этом Вам не нужно заботится о том, какие данные должны быть размещены в кэш-памяти. После того, как в первый раз контроллер прочитает данные с жесткого диска, он оставит эти данные в кэш-памяти SSD и повторное чтение будет выполняться уже оттуда.

Более того, кэширование работает не только при чтении, но и при записи. Любая операция записи будет записывать данные не на жесткий диск, а в кэш-память на SSD-накопителях, поэтому операции записи также будут выполняться на порядок быстрее.

Практически механизм кэширования на SSD-накопителях может быть реализован на любом шести-гигабитном RAID-модуле или RAID-контроллере Intel второго поколения на базе микроконтроллера LSI2208: RMS25CB040, RMS25CB080, RMT3CB080, RMS25PB040, RMS25PB080, RS25DB080, RS25AB080, RMT3PB080. Эти RAID-модули и контроллеры применяются в серверах Team на базе процессоров Intel E5-2600 и E5-2400 (платформа Intel Sandy Bridge).

Чтобы использовать режим SSD-кэширования, необходимо установить на RAID-контроллер аппаратный ключ AXXRPFKSSD2. Кроме поддержки SSD-кэширования, этот ключ также ускоряет работу контроллера с «чистыми» SSD-дисками, когда они используются не в качестве кэш-памяти, а как обычные накопители. В этом случае можно достичь производительности на операциях случайного чтения-записи в 465’000 IOPS (режим FastPath I/O).

Давайте посмотрим на результаты тестирования производительности все того же массива из восьми жестких дисков, но уже с использованием четырех SSD-накопителей в качестве кэш-памяти и сравним их с данными этого массива без кэширования.

Мы выполнили тестирование для двух вариантов организации SSD-кэш. В первом варианте 4 SSD-накопителя были объединены в RAID-массив нулевого уровня (R0), а во-втором случае из этих 4-х SSD-накопителей был образован зеркальный массив (R1). Второй вариант немного медленнее на операциях записи, зато он обеспечивает резервирование данных в SSD-кэш, поэтому предпочтительнее.

Интересно, что производительность чтения и записи практически не зависит от типа «основного» RAID-массива жестких дисков, а определяется только скоростью работы SSD-накопителей кэш-памяти и типом ее RAID-массива. Более того, «кэшированный» RAID 6 из жестких дисков на операциях записи оказывается быстрее, чем «чистый» RAID 6 из SSD-накопителей (29’300 или 24’900 IOPS против 15’320 IOPS). Объяснение простое — фактически мы измеряем производительность не RAID 6, а RAID 0 или RAID 1 кэш-памяти, а эти массивы быстрее на записи даже при меньшем числе дисков.

В качестве кэш-памяти можно использовать и один SSD-накопитель, однако мы рекомендуем этого не делать, поскольку не обеспечивается резервирование данных кэш-памяти. В случае выхода такого SSD-накопителя из строя, целостность данных будет нарушена. Для SSD-кэширования лучше использовать как минимум два SSD-накопителя, объединенный в RAID-массив первого уровня («зеркало»).

Надеемся, что информация, изложенная в данной статье, поможет Вам в выборе эффективной конфигурации дисковой подсистемы сервера. Кроме того, необходимую техническую консультацию всегда готовы оказать наши менеджеры и инженеры.

Серверная платформа — Team R2000GZ
Расширитель SAS-портов Intel RES2CV360 36 Port Expander Car
RAID-контроллер — Intel RS25DB080 с ключом AXXRPFKSSD2
HDD — 8 дисков SAS 2,5″ Seagate Savvio 10K.5 300GB 6Gb/s 10000RPM 64MB Cache
SSD — 8 или 4 накопителя SSD SATA 2.5″ Intel 520 Series 180GB 6Gb/s

Тестирование выполнялось при помощи программы Intel IO Meter.

Для каждого варианта аппаратной конфигурации выбирались оптимальные настройки кэш-памяти контроллера.

Объем виртуального диска для тестирования — 50GB.

Такой объем был выбран для того, чтобы тестируемый диск мог полностью поместится в SSD-кэш.

Прочие параметры:
Strip Size — 256KB.
Размер блока данных для последовательных операций — 1MB.
Размер блока данных для операций случайного доступа — 4 KB.
Глубина очереди — 256.

 

тестирование Андрей Леонтьев
текст Дмитрий Командный
08.10.2012

Добавить комментарий

Закрыть меню