Но, one more thing, как говорят любители фруктов
Чуть глубже изучив ситуацию, оказалось, что не все так проприетарно в вопросе многоуровневости и кеширования накопительной подсистемы в SOHO. По крайней мере, в среде Windows собрать в кучу кэш в ОЗУ, SSD и HDD можно попробовать.
Для этого существует платная, но с пробным периодом, программа от разработчика RAM-диска, рассмотренного выше. Это PrimoCache от Romex Software. Посмотреть можно по ссылке. Ключевой момент — никаких аппаратных привязок нет. Работает на любом компьютере, где есть ОЗУ и системный накопитель. Если системный накопитель — жесткий «винт», есть твердотельный диск и немного ОЗУ, то можно собрать это все в достаточно интересную многоуровневую систему. Это не значит, что нужно бежать и собирать, но ознакомиться для общего развития вполне стоит.
Для понимания возможностей давайте посмотрим на системный диалог — там на одном скриншоте видны основные нюансы работы.
Важной особенностью программы является наличие окна статистики, которое нам ответит на вопросы, которые остались неосвещенными выше по тексту, но, тем не менее, являются очень значимыми для полного понимания сути кэширования в накопителях.
Специально для этого материала я заранее установил рассматриваемую программу на домашнем ноутбуке на базе Core i3-2328M, 16 ГБ RAM, 250 ГБ HDD и 16 ГБ SSD. Характер нагрузки — офисно-домашний: несколько браузеров с десятками вкладок в каждом, мессенджеры, видео, музыка, офисные приложения. Все это загружено одновременно и почти никогда не закрывается. Нет игр, рендера, пережатия видео. Типичная SOHO-машина на старом процессоре. Старом, но не ржавом (с). С жестким диском в качестве системного он не мог даже полностью принять нагрузку на себя, т.к. скорость доступа к данным на диске была так себе. На ночь компьютер уходит в гибернацию.
В систему был добавлен SSD 16 ГБ на Phison S9 — т.е. без какого-либо DRAM-буфера — специально для целей кэширования и оценки его качества.
Аптайм приведенного скриншота составляет 100 дней. Для статистики вполне достаточно, как мне кажется. Давайте приступим к изучению.
Сверху указано текущее задание, кликнув по нему можно попасть в настройки конкретного задания. О них позже. Заданий может быть несколько.
Внизу слева в первом квадрате мы узнаем, что кэш-задание активно. Оно в конкретном случае состоит из 4 гигабайт кэша L1 — первого уровня. Это означает, что из 16 гигабайт памяти я отвел ровно четыре строго для целей кэширования. Размер можно выбрать любой. Четыре лично мне оказалось достаточно, но чем больше — тем лучше. Если в настройках выбрано кеширование как чтения, так и записи, то все, что с точки зрения ОС ходит с и на диск пройдет через эти 4 ГБ. Причем можно настроить время, через которое данные, отправленные на запись, покинут этот буфер в сторону диска. Время можно задать любое вплоть до бесконечности. Т.е. если оно будет так настроено, то данные, попавшие в буфер будут храниться там бессрочно, пока не будут замещены новыми. Если новых поступлений не будет, то у вас всегда там будет копия актуальных данных. Достаточно неплохо это все работает даже с 1–2 гигабайтами, отведенными из ОЗУ, но чем больше — тем больше данных будут доступны мгновенно. По сути, это RAM-диск, где крутятся актуальные данные.
Далее мы узнаем, что под L2-кэш отведено 13+ гигабайт. Это означает, что почти все 16 ГБ SSD я отвел под кэш жесткого диска на SSD. Оставлено немного неразмеченного места для упрощения работы контроллера при полном заполнении. В теории программа поместит в этот кэш КОПИИ популярных данных где-то на второе-третье обращение. Первично они будут прочитаны в кэш в ОЗУ с медленного «винта», но если вскоре к ним поступят новые обращения, то чтение произойдет из ОЗУ-кэша, а сами эти данные будут задублированы на SSD. Таким образом, при последующих обращениях, когда из ОЗУ-кэша данные будут вытеснены, их чтение произойдет не с медленного жесткого диска, а из копии в L2-кэше SSD. Т.е. с точки зрения системы и пользователя чтение будет проведено со скоростью SSD. Много или мало 13 гигабайт под кэш мы узнаем позже, но размер может быть любой. Его можно даже задать из системного SSD, на котором под это отвести раздел для кэширования «файлопомойки».
Storage — название конкретного кэширующего пространства. Их может быть много, например, под каждое задание отдельный кэш-раздел. Поэтому имя и прописано.
Block Size — размер блока в кэш задании. Чем меньше — тем лучше, но немного растет нагрузка на процессор (я этого не замечаю), а главное — растет нижний параметр Overhead. Это расход системной памяти на процесс кэширования. Чем меньше размер блока — тем больше расход. На 8 килобайтном блоке и 4 гигабайтах в ОЗУ это 308 мегабайт на обслуживание.
Strategy — у меня там стоит запись и чтение, но можно выбрать что-то одно и тогда только выбранная операция будет проходить через кэш в ОЗУ и SSD.
Deffer-Write — срок отложенной записи на физический диск. Если приходит запрос на запись, то таковая сначала пройдет в кэш в ОЗУ. Система будет думать, что запись произведена, но фактически данные до диска еще не дойдут. Сделано это для того, чтобы не тормозить работу системы медленным жестким диском — ведь с него в это время может что-то читаться. Отложенная запись подразумевает, что реальная запись пройдет позже и не ранее указанного времени. При этом фактически к диску пойдет обращение в момент, когда он может быть вообще в простое. Важно то, что запись пойдет пакетом с глубиной запроса более 1, т.к. задача-то сформирована. А даже тормозные жесткие диски такие задачи выполняют не на таких уж и плохих скоростях. Т.е. даже если были сгенерированы запросы на запись большого количества мелких файлов, то к моменту фактической записи это будет не рандоманя толпа, а последовательная очередь, что очень по-разному выглядит в бенчмарках. Если кэшировать так какой-нибудь Samsung Pro 970, то запись пройдет вообще почти мгновенно.
Mode — режим работы кэша. Это детали, которые рассмотрим позже.
Options — FlushSleep означает, что перед переходом в сон из кэша в ОЗУ все незаписанные данные будут фактически записаны на накопитель. При просыпании весь кэш в ОЗУ будет на месте. Это мера предосторожности на случай потери питания во сне.
Prefetch — режим сохранения кэша в ОЗУ на диск перед перезагрузкой или выключением. Если включено, то после перезапуска всё кэш-задание будет смонтировано в ОЗУ и по итогу весь набор типичных кэшированных данных будет доступен для чтения со скоростью ОЗУ. Сохраняется на жестком диске.
Правее у нас окно статистики, которая очень важна.
Итак, за 100 дней было подано запросов на чтение 754 гигабайт, при этом из кэшей прочитано 733! Т.е. в моем профиле работы попадание в кэш почти 97%. Это означает, что 97% данных были или в кэше в ОЗУ или на SSD. Всего 3% было прочитано с медленного жесткого диска или 22 гигабайта за 100 дней. Вероятно, это весь объем данных, с которыми я работал за это время, плюс надо сделать поправку на прошлые запуски кэша. Он мог подтянуть префетчем прошлую сессию, а это до 3 гигабайт, но скорее всего этого не было и 22 — это мой объем реального чтения с жесткого диска.
32,4% всего было прочитано из кэша на SSD. Я думал, будет больше. Т.е. 67,6 где-то процентов прочитано из 4 гигабайт кэша в ОЗУ.
L2-запись показывает, что за все 100 дней программа оценила как актуальные и достойные переноса на SSD около 65 гигабайт, но SSD у меня был только на 16 и поэтому со временем самое неактуальное вытеснялось из этого кэширующего тома. Т.е. будь у меня SSD на 64 гигабайта, то за это время он бы заполнился целиком, разгружая жесткий диск по и так слабенькому чтению. Естественно, что все исходные данные в целости лежат на жестком диске независимо от движения копий по L2-кэшу.
Далее видим группу важных показателей статистки о запросах записи на жесткий диск.
За 100 дней система сгенерировала запросов на запись 411 гигабайт, но до фактической записи дошло всего 61,5%. Это произошло потому, что актуальность записи части данных была утрачена по разным причинам до фактического их переноса из кэша в ОЗУ на физический жесткий диск. Экономия трети записи была бы актуальна, когда у твердотельных накопителей были проблемы с ресурсом. И, вероятно, будет актуальна для накопителей на QLC- и OLC-типах памяти, где каждая перезапись, похоже, будет на счету в случае малых объемов самих накопителей.
Deffered Blocks — текущая очередь на запись в кэше ОЗУ.
Trimmed — не дошедшие до записи.
Prefetch — наработанный кэш в ОЗУ, который был смонтирован при загрузке системы.
Общая логика работы программы выглядит так.
Ну и коротко об эффективности работы с точки зрения популярной и наглядной тестовой утилиты. Слева кэш выключен, справа — включен.
Помните наши три способа выше прочувствовать скорости RAM-диска, из которых мы озвучили лишь два? Надеюсь, вы заметили, что п.3 там не было? Это как раз третий. Браузерный кэш в этом случае будет закэширован в т.ч. в кэш в оперативной памяти, который работает аналогично RAM-диску. Сам браузер с большим количеством окон будет отлично стрелять, т.к. тоже будет закэширован префетчем в кэш в ОЗУ при загрузке ОС. В крайнем случае, он стартует из копии на SSD L2-кэше, ну и кэш самого браузера в худшем случае будет задублирован на L2, что внешне приведет к работе на скорости, идентичной чистому системному SSD. Не запутались где какой кэш?
Как вам увеличение случайной скорости чтения мелких файлов примерно в 1150 раз? Выглядит впечатляюще, но есть один нюанс. Выше в разделе «SSD без кэша не бывает» мы заметили, что «Именно поэтому в ряде популярных тест-утилит скоростей SSD если тестовый образец, сгенерированный утилитой, поместится целиком в такую прокладку и будет тут же прочитан в ходе теста, то эти самые утилиты могут показывать скорость именно быстрой кэш-прокладки, а не основного массива!» Это как раз тот случай. Утилита показывает скорости работы именно кэша, а не основного массива. Т.е. мы фактически видим результаты тестирования скорости работы DDR3, установленной в нашем ноутбуке, часть которой жестко отведена под дисковый кэш и по факту является своего рода RAM-драйвом. Если тестовый пакет данных за пределы кэша не выйдет, то все будет примерно как выше справа, но если выйдет, то показатели устремятся к левому скриншоту. В конкретном случае у меня 4 ГБ из ОЗУ выделено под кэш накопителей, а тестовый образец, как видно – всего 2 гигабайта. Такой выбор был сделан сознательно для иллюстрации ситуации. Чтобы понять, как все будет выглядеть на практике, приведем скриншот с тестовым образцом заведомо более кэша — 8 гигабайт. Замер, опять же, не лабораторный, а чисто индикаторный (точное исследование скоростей в данном материале как задача не ставится, да и сами скорости в этом случае будут сильно зависеть от конкретного железа, например поколения DDR), но по нему видно, что вклад кэша в чтение за его пределами есть, но представляет он собой чисто среднее измерений по всему тестовому заданию. А вот запись такая красивая, т.к. утилита сначала создает тестовый образец и пишет его на накопитель, т.е. к части теста «запись» он, тестовый образец, уже был на целевом накопителе почти целиком заранее, поэтому и цифры такие.
Строго аналогичная ситуация происходит при тестировании отдельных накопителей с DRAM-кэшем и кэширующими SLC-буферами. Тестирование позволяет оценить размеры буферов и прикинуть режимы их работы, но управлять логикой все равно нельзя. Это прерогатива прошивки. И если буфер объемный, то и скорости в процессе работы будут приближены к скорости самого буфера. Мухлеж это или нет со стороны производителей — решать вам, а наша задача вас ознакомить с физической и логической сутью происходящего для самостоятельного принятия обоснованных объективной информацией решений.
Как бы там ни было, но все это очень позитивно сказывается на пользовательском опыте и отзывчивости системы в целом. Т.е. вполне реально оставить системным даже жесткий диск при наличии хотя бы 16 гигабайтного твердотельного накопителя под кэш, причем совершенно любого, т.к. если у вас системным — SSD, а под файлы или игры все еще жесткий диск, то можно на системном накопителе выделить область для кеширования HDD и таким образом закэшировать его. Это удобно для игр, т.к. в кэше будет храниться текущая игра, а когда пользователь начнет играть в другую, то она заместит в кэше старую. Если же кэша будет достаточно, то там будут задублировано все, что физически поместится, ведь как видно из схемы вверху все данные по умолчанию будут проходить кэширование. Единственным нюансом будет то, что первичное чтение некоторых данных будет происходить с медленного жесткого диска. Но, как мы увидели выше, их немного в типичном пользовательском сценарии. Кэшируется даже файл подкачки Windows, он же «своп».
Кстати кэширующим накопителем PrimoCache позволяет установить и Optane, т.к. за пределами своей экосистемы он видится как обычный NVMe-накопитель в системе. Т.е. может быть назначен кэширующим со всеми «плюшками» его скорости. Intel расщедрилась и, в отличии от прошлых решений, позволила пользователю вкусить скорости Optane таким пробником, а могли бы и не оставить такой форточки.
Важный момент — чтение из кэша идет уже на стадии загрузки ОС, так что загрузка частично проходит из быстрого твердотельного накопителя даже в случае с системным SSD. Т.е., например, Optane можно ускорять даже Samsung 970 Pro в сценарии работы с мелкими файлами.
И напоследок подчеркну — никто не заставляет иметь сегодня системным жесткий диск. Но даже если он не системный, а просто есть, то его имеет смысл кэшировать и тогда на него вполне можно будет опереться в случае объемных данных для работы или игр и не считать совсем уж рудиментом в системе. Причем закэшировать можно как частью системного SSD, так и любым сторонним, установленным специально для этой цели — благо цены позволяют.
Все это приведено в строго исследовательских целях повышения отдачи от имеющегося железа. И было бы просто замечательно, если бы что-то хотя бы отдаленно подобное предлагалось как часть настроек ОС. Шаг в эту сторону сделали Samsung и Crucial, but more is needed…
Какие главные выводы из прочитанного:
- Кэширование — актуальный процесс, встречающийся повсеместно: от процессора до самого медленного накопителя. Кэшируют все, всё и везде. Кто не кэширует — тот обманывает.
- В современных условиях больших объемов доступной оперативной памяти и дешевых SSD можно и нужно организовывать кэширование любыми доступными средствами. Даже если у вас системным диском крутой Samsung 970 Pro и жесткий диск под хранилище — имеет смысл выделить несколько гигабайт твердотельного диска под кэш HDD. Или даже отдельный самый дешевый SSD для этих целей. Вряд ли у кого-то будет активных данных больше, чем на 100–200 гигабайт разом. А самый дешевый твердотельный диск сегодня стоит недорого и до конца года, видимо, будет дешеветь. Ну и сам 970 Pro вполне возможно закешировать чем-то более быстрым типа Optane и тогда приход позитива от обладания крутыми «железками» будет трансформирован в реальное повышение скорости работы с мелочью даже на топовых из адекватных по цене накопителях.
- Совершенно непонятно, почему подходы PrimoCache или аналогичные не организованы хотя бы базово в части управления в Windows? Конечно, там есть базовое кэширование, но эффективность его работы разительно отличается от предлагаемого сторонним ПО. Да и логику работы настраивать никак не предлагается.
- Аппаратные гибриды в случае открытой архитектуры и п.2 банально нужны еще меньше, чем в период их расцвета, т.е. чуть менее чем никак, т.к. все тематические задачи кэширования совершенно реально организовать прикладным ПО на уровне драйверов. Разве что какие-то ну уж очень узкоспециализированные «железки» под совсем нетипичные задачи могут быть нужны. Мы сейчас в основном о Windows, но в других ОС все это тоже давно присутствует в том или ином виде.
- В Enterprise все уже давно реализовано.
Может я это все придумал, и концепция нежизнеспособна?
Может это самообман и CrystalDiskmark неадекватен? Может это вообще никому не нужно при текущих ценах на SSD и завтра все забудут о жестких дисках? Но вспомним Блока:
Умрешь — начнешь опять сначала
И повторится все, как встарь:
Ночь, ледяная рябь канала,
Аптека, улица, фонарь.
К чему Блок? А вот к чему — Intel совсем недавно выпустил в продажу… гибрид! Внезапненько так. H10 называется. Коротко об изделии на слайде:
Если кто не в курсе — это аппаратная склейка из специфической QLC-памяти, закешированной молниеносным Optane, на одном NVMe-накопителе. Помните же — QLC тормозная на запись и это надо как-то закостыливать. «Оптаном», например.
Ничего не напоминает? Не новые ли это технологичные проприетарные грабли, на которые уже наступали? Не похоже ли это на гибриды, которые мы уже отвидели, но на новом уровне? Почему вообще без DRAM-буфера? Не выделит ли комплектное ПО еще и кэш в ОЗУ перед Optane? Почему работает только со специфическим драйвером, на избранных системах, а не «из коробки» в любых?
Обратите внимание на соотношение «Оптана» и QLC в растворе: 16+256, 32+512, 32+1024. Т.е. в Intel посчитали, что 16 гигабайт кэша на четверть терабайта накопителя достаточно. Это сильно похоже на наш сценарий в PrimoCache, но я-то 16 гигабайтный SSD за копейки для теста брал из бомжатских соображений, а Intel что — боится итогового ценника, если цифры осовременить?
Занимательно, что в товарном образце, в отличие от маркетингового мусора выше, DRAM таки просматривается вполне определенно.
«Без одежды» выглядит так. Раздевали в Storagereview.
Неужели опомнились в последний момент? Или это был маневр по обману конкурентов отсутствием чипа буфера на ранних стадиях? Или без DRAM рулить адресацией в таких сочленениях тяжеловато?
Кстати, вполне вероятно, что конкуренты ответят лошадиными объемами DRAM-буферов в своих решениях на OLC, т.к. QLC уже более-менее оформлены в изделиях, а Optane им никто не продаст. Напомним, что все это происходит на падении рынка полупроводников и перед открытием китайскими товарищами новых мощностей.
Т.е. ставить DRAM будут везде (вендоры не снизят поставки, чтобы не потерять долю рынка перед китайцами, а производители конечных товаров, пользуясь ситуацией, могут нарастить объемы памяти в устройствах почти при тех же ценах ну или снизить цены в ритейле еще сильнее), но не в Intel. Для страховки от неприятностей таки увидим в перспективных конкурирующих решениях еще и батарейки — ведь в случае чего гигабайта четыре из DRAM-кэша надо будет дописать успеть. Но это конфабуляции о будущем. Вы же помните, что в этой части мы конфабулируем?
В прошлый раз мы писали о пересекающихся гарантия SSD и НЖМД. Сделай Microsoft настраиваемое кэширование, то их мож(д)но было бы продавать kit-ами, но это уже фантазии и без допинга особого рода нам не попасть в фазу креативного мЫшления маркетологов.
По сути все вышеописанное не столько конкурирующие технологи, сколько взаимодополняющие, как видим. Далеко не все ресурсы традиционных технологий в полной мере освоены. Более широкий выбор позволяет более гибко подходить к конфигурированию под конкретные задачи и самые интересные решения, в т.ч. программного плана, надеюсь, еще впереди.
Титры
Спасибо дочитавшим до конца более 90000 знаков с пробелами. Теперь вы знаете больше. Свои отзывы и предложения прошу оставлять в комментариях. Возможно, я что-то не осветил или кто-то с чем-то не согласен, и мы вместе повысим образовательный уровень наш и тех, кто эту статью найдет в поиске в будущем.
P.S. В части более бытового использования рассмотренной технологической концепции заметим, что в вашем домашнем обратноосмотическом фильтре воды низкая производительность фильтрующей мембраны... закэширована накопительным баком.
Пока longread готовился к публикации, благая весть поступила от Intel в виде анонса следующего этапа продвижения кэширющих Optane — модулей М15 под PCI-E 4.0. Максимальный объем теперь составляет 64 гигабайта, что уже ближе к реальности. Но самое главное — обещают рост скорости по мелкоблочке раза в два! Т.е. мегабайт до 500–600 в секунду. Это будет очень интересно не только протестировать, но и просто установить систему и узреть чистое сияние прогресса. Важно при этом другое — о железных изменения в части контроллера или самой памяти не сообщается, а просто за счет PCI-E 4.0 скорость мелкоблочки так возрасти не могла, разве что из-за распараллеливания нагрузки. Т.е. самое интересное по теме у нас впереди и оно уже становится более-менее доступно в ритейле.