Накопители — завершение. Longread об актуальных аспектах кэширования в дисковой подсистеме

Disclaimer — в материале некоторые описания процессов и их логики приведены в адаптированном виде, тогда как в жизни все несколько сложнее, но в общем примерно так, как описано.

Часть1
Часть2

В прошлых материалах мы установили, что благодаря научно-техническому прогрессу сегодня в массовом сегменте SOHO хранения данных доступны, в основном, две технологии: электромеханические или традиционные накопители на жестких магнитных дисках (они же НЖМД, HDD, винчестеры, винты и прочие вариации с производными), а также инновационные безмеханические твердотельные накопители (они же SSD, твердотельники и т.п.).

I want to believe

Заметим, что накопители в текущем их понимании (как и вся современная компьютерная индустрия), а твердотельные накопители — так тем более, своим появлением и эволюцией обязаны развитию полупроводниковых технологий как таковых. Последние показали значительный прогресс, внезапно, в 1947 году. Аккурат после события, вошедшего в популярную культуру под названием Розуэльского инцидента. По мнению конспирологов тогда, 8 июля, недалеко от одноименного населенного пункта в небе заглох и натурально упал на Землю НЛО, который был отбуксирован эвакуатором в Зону 51, где крайне засекреченные ботаны, а в последствии и полумифический Боб Лазар в их числе, под подпиской о неразглашении путем восстановительной инженерии майнили внеземные технологии под прикрытием доблестной армии США. Якобы строго после этого вся полупроводниковая промышленность и пошла на взлет.

Сюжет портят два нюанса: около 1920-х годов в последующем советский физик Олег Лосев уже закладывал первые дециметры бетона в фундамент этой темы, а на рубеже 1947–48 годов американские и немецкие физики во Франции независимо друг от друга «запилили» опытные образцы того, что потом станет транзисторами. Так что дело шло своим чередом и в меру воздействия внешних факторов, среди которых инопланетян к тому моменту не числилось.

Когда ботаны маршируют

В общем, развитие машинной обработки информации выдвигало серьёзные требования к вопросам упорядочивания этого процесса. Ручной ввод данных и фиксация результатов становился все более архаичным и реально тормозил процессы, которые вычислительная техника должна была ускорять. Известна история, что в ходе разработок первых экземпляров советского ядерного оружия, конкурирующие научные группы могли отказаться от машинного времени на тогдашних «компьютерах» в пользу включения в команду виртуозных математиков — с ними процесс сложных расчетов мог идти на практике быстрее, чем с использованием ЭВМ. Конечно, в точности расчетов и стабильности скорости их выполнения человек тягаться с машиной не мог уже тогда, но инфраструктура доступа к вычислительным мощностям была почти что в зародыше и поэтому живой математик в команде в отдельных случаях ценился выше.

Человеко-компьютерное взаимодействие

Поэтому вопросы ввода-вывода нужно было как-то не только автоматизировать, но и делать это интенсивным научным способом — ведь результат машинной обработки в одном процессе мог одновременно становиться исходными данными для следующего или быть запрошенным произвольно во времени в будущем. Уже здесь мы понимаем, что существуют некие данные, которые используются машиной чаще других, а иногда и вообще могут быть востребованным постоянно. Вводить же каждый раз одни и те же исходные данные руками с позиций дня сегодняшнего выглядит несколько диковато, но тогда иного пути не было. За словом «оператор» тогда стояла очень трудоемкая и кропотливая работа. Поэтому идея хранить наиболее популярную информацию, команды и т.п. на наиболее быстрых участках носителей была очевидной. Реализация этой идеи в будущем получит общеупотребительное название — кэширование, а сами области хранения с высокими скоростями обмена и малым временем доступа будут известны в широком смысле как кэш. Запомним — нам это знание сегодня понадобится.

Музеефикация

В таких условиях традиционные для начала компьютерной эры технологии становились уже очень не очень. Электростатические запоминающие трубки на 0,5 килобайта, перфолента, магнитные барабаны на целых 10 килобайт — все это когда-то решало поставленные задачи, но устаревало как морально, так и физически на фоне того, что все актуальней становилась задача не только надежного хранения предыдущих расчетов и прочих данных, но и удобного оперативного доступа к ним.

С магнетизмом на то время все было несколько более понятно, нежели с неведомыми еще транзисторами, и в 50-е появились прообразы жестких дисков, концептуально родственные современным. Совсем, правда, не похожие внешне на то, о чем вы читали в предыдущих обзорах, но тем не менее. Приведем пару классических картинок от JEDEC для ориентации в пространстве и времени. Слева накопитель IBM на 5 мегабайт, а справа — уже на целых 250 мегабайт. Прогресс за 20 лет в 50 раз. Правда, тележка все еще нужна.

Идея оказалась жизнеспособной, как мы можем констатировать с высоты 2019-то года, и в прямом смысле завертелось… Естественно, что такая радость на начальных этапах никак не могла стоить дешево и быть доступной даже каждому второму НИИ, не было единых подходов к использованию вне рамок конкретных вычислительных машин и т.п., но главное — концепция в материале стартовала и желающие уже могли сами определить насколько финансово и управленчески будет востребован их продукт, чтобы позволить себе такие технологии, ну или просить под них бюджетные средства. Правда, был еще имидж, когда сам факт обладания новейшими технологиями делал из держащего в руках, например, дорогущий фотоаппарат — фотографа в глазах окружающих.

Уголок состоятельных кротов

Чисто для справки можно свериться с информацией на Jcmit.net. Там указано, что стоимость 1 (одного) мегабайта в накопителе машины IBM 305 была равна 9200 USD. «Охренеть!» — заявит читатель и будет несколько не прав. Дело в том, что вечнозеленый американский доллар тоже подвержен инфляции, которая с 56-го года для него составляет где-то 824%. Т.е. в финансовых понятиях дня сегодняшнего (или статистически — на конец 2018 года), те 9200 долларов по покупательной способности соответствуют сегодняшним примерно 86 000 USD. Таким образом, весь 5-мегабайтник в 1956 стоил сегодняшних 320 000 долларов — вот теперь можно оценить стоимость инноваций тогда и сегодня. Интересующиеся могут посмотреть уровень инфляции за определенный промежуток времени.

Ну и полирнем информацию о динозавре тем, что его аренда компаниям обходилась в 3200 USD в месяц, т.е. примерно 30000 сегодняшним. Да — чуждая нам практика лизинга или аренды (хоть это немного разные вещи, но тем не мене похожие) там позволяла пользоваться дорогущими изделиями «здесь и сейчас», а не копить на них годами, выпрашивая кредиты у банкиров с консервативным, в плане инноваций, мировоззрением. Сделали таковых около 1000 штук, что намекает.

ОЗУ

Аналогом более-менее оперативной, в нашем понимании, памяти были магнитные барабаны на 3200 знаков, а совсем уж оперативная память описывалась 100 знаками по 6 бит — такой себе транзитный буфер. Барабаны крутились на 6000 оборотах в минуту — почти дизельпанк. При этом самой IBM понятие RAM — Random Access Memory — тогда виделось иначе, и RAM представлялся как сам вышеописанный жесткий диск.

К слову, формально все верно — доступ, в отличие от перфокарт, таки рандомный, т.е. случайный, но сегодня под RAM обычно понимают таки память оперативную. Однако с позиций сегодняшнего мы можем констатировать, что такое название было в некотором смысле пророческим, и мы к этому еще вернёмся. Кстати сам IBM 305 назывался RAMAC — Random Access Method of Accounting and Control. Инструкция по ссылке.

Термодинамика данных

Очевидно, что для архивного хранения данных все это явно не подходило как минимум по цене (дешевле было реально итоги записывать ручкой), а использовалось в основном для оперативной работы с относительно актуальной информацией преимущественно внутри машины. Но, тем не менее, что-то надо было сохранять на будущее с менее частым использованием. Забегая вперед заметим, что таковое вытеснялось впоследствии на магнитную ленту, которая, кстати, как носитель информации подъехала существенно позже, хотя технологически была известна с 30-х годов.

Таким образом, мы подходим к мысли о разной степени востребованности и актуальности данных. Но мы также понимаем, что чем оперативнее можно работать с носителем, тем такой носитель в общем случае дороже. Как правило, чем быстрее — тем меньше объемом и дороже. И наоборот. Соответственно распределение данных имеет смысл осуществлять на типы носителей сообразно степени востребованности информации.

Конечно в идеальном, сферическивакуумном случае иметь бы возможность процессору работать с накопителем напрямую, как и проистекало из определения RAM тогда и трактовки этого понятия сегодня. Но скорости современных накопителей еще не достигли нужных высот при больших объёмах и при реализации такого подхода процессор, простаивая, будет «ждать» накопитель. Поэтому при вычислениях и работе с информацией мы до сих пор имеем посредников — ведь, как правило, в единицу времени весь массив архивной информации нам не нужен, да и процессоры не в состоянии все и разом переварить. Поэтому работа идет порционно, транзитом из менее быстрых видов памяти в более быстрые.

Соответственно по частоте востребованности в работе и частоте изменений данные условно делят на холодные/теплые/горячие. Картинку позаимствуем у господина К.Савелли.

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

Иерархическая система компьютерной памяти

Но дело в том, что действительно быстрые типы памяти стоят дорого и сегодня. Масштабы, конечно, несколько иные, но суть — та же. Рассмотрим картинку.

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

Далее у нас идет основной посредник между быстрым процессором и тормозным хранилищем — оперативная память, оно же RAM в сегодняшней терминологии. Это быстрая, но энергозависимая память произвольного доступа. Пока энергозависимая, т.к. Intel все грозится напугать общественность энергонезависимой ОЗУ и даже объявила в этом году некие продукты. Как оно будет в жизни — посмотрим. А пока ОЗУ — это основной посредник. Организация работы с ним во времени претерпевала изменения, а поколения меняются достаточно часто. Но для наших целей последнее имеет второстепенное значение. Куда важнее, что в обычный десктоп уже можно проинсталлировать 128 гигабайт нашей прелести, хотя редкие игры используют сегодня больше 16 гигабайт. Об этом мы еще поговорим и это крайне важно. Причем важно безотносительно поколений памяти, скоростей, типов чипов, планок и т.д. Она просто очень быстрая по сравнению со всем последующим, но медленнее процессорной памяти.

Ниже по пирамиде у нас группа энергонезависимых накопителей, проранжированных по скорости. Обобщённо назовем их SSD, HDD и ленты. Существуют и иные подключаемые и роботизированные способы хранения, но в рамках этой публикации мы их выносим за скобки.

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

Зачем мы это рассмотрели?

Причины две:

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

Итак, в общем случае некие данные будут считаны с накопителя, обработаны процессором в единстве с ОЗУ и его внутренней памятью, и возвращены для дальнейших действий, где обратная запись будет далеко не типичным событием. Т.е. оперативная память это, в некотором смысле, кэш тормозного накопителя.

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

Но о каких же скоростях сегодня идет речь на практике?

Начнем с самого быстрого – внутрипроцессорной памяти, она же процессорный кэш. Ввиду расположения наиболее близко к ядру/ядрам здесь имеем минимальные задержки и максимальные скорости. Внутрипроцессорный табель о рангах памяти состоит из регистров и того, что отражается в спецификациях как кэш. Последний, в зависимости от приближенности к «императору», т.е. ядру, бывает трех уровней: L1 — самый крутой, самый быстрый, но маленький, L2 — менее крутой и быстрый, но побольше, L3 — помедленней и побольше, но все равно радикально быстрее ОЗУ. В многоядерных процессорах кэш может быть как закреплённым за ядрами в конкретном объёме, так и динамически распределяемым. Ввиду размеров хранятся там всякие инструкции, служебные данные и тому подобное.

Вот тут сайт уже показывает, как модно говорить, мейнстримовые цифры Intel Core i9-9900K по этому поводу.

Это конечно не лабораторный замер и до конца непонятно как именно AIDA получает эти цифры, которые в реальности расчетно должны быть поменьше, но порядки и динамику развития технологий они в целом отражают. L1-память в данном случае, если верить тесту, способна читаться со скоростью 2,34 терабайта (!) в секунду. Т.е. если изготовить типовой накопитель в 250 ГБ из такой «нереальной» памяти, то прочитать его целиком за секунду можно будет около 10 раз без учета задержек на вынос коробки из склада, т.е. задержек доступа. Это примерно тот идеал, о котором мы и IBM писали выше, но он пока недостижим в промышленных объемах по вменяемым ценам (да и в реальности скорости лучших L1-кэшей с учетом задержек будут раза в 3–4 меньше указанных) и поэтому есть нижеописанные костыли.

Далее у нас идет оперативная память (ОЗУ, RAM). Она прошла долгий путь не в одно поколение, работает на разных частотах с различными таймингами. Конкретные изделия помогут выбрать на Overclockers.ua, мы же обратим внимание, что, согласно спецификации, примерный сегодняшний мейнстрим в виде DDR4-3200 в теории способен пропустить 25 гигабайт в секунду.

Далее следуют приснопамятные SSD, где особняком стоит Optane (о нем — отдельно). Лучшие SSD способны прочитать 3500 мегабайт в секунду последовательно и 50–60 мегабайт в секунду случайных данных. Говоря предметно, все эти тысячи последовательного чтения-записи на практике востребованы мало. Единственным действительно важным показателем твердотельных дисков является истинная скорость работы со случайными данными и малыми глубинами запросов.

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

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

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

Трон SSD отобрал у HDD — т.е. у традиционных жестких дисков, которые в быту на случайных операциях были на порядки (т.е. в 10, 100 и даже 1000 раз) медленнее SSD.

Следующие далее ленточные и прочие накопители в рамках данного материала мы не относим к классу архивных и в рамках данного материала не рассматриваем по причине отсутствия актуальности.

Средняя температура по больнице в части задержек приведена ниже с данными для сравнения. Спасибо Jonas Bonér за цифры.

Таким образом, наиболее близкая к процессорным ядрам память способна гонять терабайты в секунду. С удалением от ядер показатели падают, но все равно внутри процессора — внушительны. Практической значимости в этих цифрах не так много, как хотелось бы, хотя бы по причине того, что объемы этой сверхбыстрой памяти — мизерны. Как мы упоминали — умей человечество изготавливать накопители таких скоростей, то и никакого деления на процессорный кэш, ОЗУ, SSD, HDD и т.п. не было бы нужно. Но не умеем. Пока, во всяком случае.

Что же такое кэш и как его правильно бояться

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

Все это прямо проецируется на ситуацию с накопителями. Современные операционные системы с разной степенью успешности кешируют данные с использованием оперативной памяти. И если таковой достаточно и алгоритмы кэширования написаны параллельными руками, то, будучи разово загруженной, условная программа второй раз запускалась почти мгновенно именно потому, что запускалась не с медленного диска, а фактически из копии основных файлов в ОЗУ. ОЗУ же, как мы помним, работает куда быстрее лучших SSD. При дальнейших запусках указанной программы система будет сначала смотреть, что там осталось в кэше, в ОЗУ и только потом пилить диск. Здесь мы видим визуализацию описанного выше кэширования данных с медленного диска в быструю оперативную память. Благодаря алгоритмам ее часть становится кэшем для накопителя. Основная проблема здесь в том, что первично данные надо медленно считать с медленного же накопителя в энергозависимую память, т.е. после перезагрузки все пройдет по этому же сценарию. Прямо как А. Блок:

Ночь, улица, фонарь, аптека,
Бессмысленный и тусклый свет.
Живи еще хоть четверть века —
Все будет так. Исхода нет.

Умрешь — начнешь опять сначала
И повторится все, как встарь:
Ночь, ледяная рябь канала,
Аптека, улица, фонарь.

Блок на «оверах» это, конечно, неэхотажно, но тем не менее.

Особым моментом в данном случае является работа с массивами мелких файлов. Если повезло и они закэшированы (т.е. ранее прочитаны и находятся в быстрой памяти), то скорость работы с ними будет крайне высокой, а для отдельных задач это основной вид нагрузки. Правда, ровно до момента, пока весь этот массив после обработки не пойдет на запись и тут уже последствия зависят от типа физического носителя. Так, например, запись в лоб массива мелких файлов на жесткий диск вызовет у последнего очередь. Запомним этот момент — мы к нему еще вернемся.

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

В случае записи на медленный накопитель кэширование позволяет писать не в лоб, а фоново и отсрочено. Данные группируются и записываются по конечному адресу незаметно для пользователя. Внешне это выглядит как будто запись фактически завершена, но по факту до медленного диска пакет данных дойдет позднее. Если кэш, т.е. память под него — большой, то вытеснить данные на медленный накопитель можно вообще через десятки секунд, а то и минут (с минутами есть нюансы — важно чтобы операция фактически завершилась до, например, пропадания питания; именно поэтому «флэшки» в общем случае выдирать из портов произвольно нельзя, т.к. если было включено кэширование записи, то это приведет к утере недописанных данных) в моменты, когда такой медленный накопитель будет простаивать. При этом будет накоплен хороший пакет на запись и таковая будет осуществлена с... большой глубиной очереди. Хоть где-то эти цифры из тестов пригодились! Если система активно читает медленный диск и одновременно должна писать на него, то используя кэширование записи в оперативной памяти можно продолжать чтение, вытесняя данные из кэша в физическую запись в те моменты, когда это удобно. Например, чтение прекратилось и диск может полностью посвятить несколько секунд записи накопленного пакетного задания на максимальной скорости. Ранее это вызвало бы несварение у блока головок медленного диска и общее торможение системы, т.к. она бы «ждала» завершения процессов, а теперь все происходит последовательно в процедурном смысле, не мешая друг другу в общем случае. Это называется write-back политика кэширования.

Получается, если алгоритмы удачно разместят в кэше ОЗУ элементы ПО, то, по сути, мы будем работать с ОЗУ как с накопителем?

В некотором смысле да. И это совершенно не новость. Еще в MS-DOS было можно штатным ramdrive.sys отвести часть ОЗУ под логический диск с буквой, записать туда нужные данные и работать с ними на недостижимой для физических накопителей скорости. Проблемы было ровно две. Во времена DOS далеко не все располагали достаточным количеством ОЗУ для таких затей и по выключению питания фейковый «диск» обнулялся, т.к. ОЗУ-то у нас пока еще энергозависимая. В остальном можно было запустить игру и не наблюдать тормозов подгрузки уровней — лютый жир того времени. Обычно люди все же работали с RAM-диска, а не играли.

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

Итак, для среды Windows существует не менее дюжины программ, которые могут создать в ОЗУ логический диск и работать с ним внешне для пользователя как с физическим. Скорости будут соответствующие ОЗУ. Разные реализации ПО несколько по-разному в итоге работают в плане скорости, но эту разницу можно ощутить разве что в бенчмарках. Да, создаем RAM-диск и делаем замер, после — офигеваем от скоростей. Это очень круто и удобно для тех, у кого работа упирается в возможности физических дисков.

Проблему энергонезависимости решают далеко не все, но решают. Так пара программных RAM-драйвов от SuperSpeed и Romex умеют не только создавать RAM-диск с буквой типа X:, но еще и сохранять его содержимое перед перезагрузкой на реальный диск и после перезагрузки и монтирования в системе этого Х: RAM-диска восстанавливать сохраненное содержимое прошлой сессии на него. Нечто вроде гибернации, но работает вполне нормально. Если исключить из ситуации перезагрузку, которая на практике бывает нечасто, а когда бывает, то в это время люди пошли пить чай (условно), то все выглядит как наличие в системе ультрабыстрого накопителя для любых нужд в виде обычного диска с буквой в проводнике. Хорошие RAM-диски умеют и с гибернацией системы корректно работать. Поэтому если вам критична скорость работы с накопителем, а задачи позволяют приобрести нужное железо, то при учете современных типовых 128 гигабайт ОЗУ, которые можно штатно поставить на массовые материнские платы, такое решение по производительности уйдет далеко вперед от любых физических накопителей, доступных сегодня.

Но почему проблемы «почти» решены?

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

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

Здесь надо сделать отступление и вспомнить, что и похожие цели освоить и проблемы энергонезависимости решить уже пытались в т.ч. и железно.

Их знали только в лицо

Понимая, что достичь скоростей работы с ОЗУ на физических дисках было невозможно, разработчики из Platipus (Австралия!) явили миру мутагенное чудовище Qik в 2000-м году. PCI, до 8 гигабайт SDRAM, лошадиные цены — 12 000 USD за 4 ГБ версию.

Чуть позже разработчики из Gigabyte представили свою вариацию на эту тему — i-RAM. Железка имела слоты для ОЗУ и реально батарейку для обеспечения энергонезависимости. В итоге получался физический 4 ГБ RAM-диск на базе четырех DIMM с поддержкой DDR-400, который не обесточивался при перезагрузке.

Но не i-RAM единым, как говорится. Еще более экзотический девайс выкатили хлопцы из ALLONE. Называлось это — Cloud Disk Drive 101, и сделано было по аналогичной концепции, но под ноутбучную память DDR3-1600.

Особым цинусом затеи была идея бекапа на SD-карты! В случае пропадания питания контроллер резервировал содержимое, питаясь от батарейки, на шесть SD-карт в RAID-5!

Работало примерно вот так. Нас интересует именно 4К случайная нагрузка с глубиной запроса 1, т.к. это основная практическая нагрузка в SOHO-реальности. Обратите внимание — с ростом глубины запроса производительность не росла. Видимо по причине того, что это все же DRAM.

Для любителей «50 оттенков твердотельного» я приготовил отдельный кадр на базе рассматриваемого изделия. Наслаждайтесь.

А мы продолжим.

ACard's ANS-9010 Serial ATA RAM disk – физический RAM-драйв с двумя секциями под память, умеющий представлять их в RAID-0 для пущего профиту. Батарейка в наличии. CF для бекапа на борту. 21 минута на резервирования 32 гигабайт и 14 минут на восстановление в DIMM.

К слову, если владелец мог разжиться дорогущими модулями DDR2 на 8 ГБ, то вся конструкция давала аж 64 гигабайта почти энергонезависимого накопителя с реально неплохими для своего времени скоростями работы. Все это упаковывалось в, страшно подумать, место в системном блоке для 5,25 дисковода.

Работало как-то так. В конфигурации с 32 гигабайтами памяти стоило 1200 долларов! Детально можно почитать здесь.

А вот так аналог выглядел у Apacer.

А еще были Hyperdrive за тысячи долларов и продолжения от Allone в виде ioRAM3 и mark1.

Сама задумка была очень неплохой — получить возможность работать энергонезависимо с невиданными для традиционных «хардов» скоростями, но цены, разношерстные реализации, отсутствие распространения даже в среде энтузиастов, цены я называл? и последующее наступление ставшими отраслевым стандартом SSD вытеснили эти изделия на периферию истории.

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

Переходный период

В общем, в какой-то момент в прошлом стало очевидно, что прямая работа с жесткими дисками (а иных в эти былинные времена и не было-то) стала уж очень степенным занятием и с этим надо было что-то делать, т.к. на практике не все ОС и не всегда, в принципе, умели эффективно работать с кэшированием. Было решено оснащать «винты» буферами из DRAM. Размеры были по сегодняшним меркам — смешные, поэтому и работало так себе, но лучше, чем ничего. Так, например, вся читаемая НЖМД дорожка помещалась в буфер независимо от того, какая часть реально читается — вдруг и соседние данные понадобятся. Конечно на совсем мелочи эффект был, но кто же серьезно будет смотреть на кэш-память в целых 64 мегабайта сегодня? Главный вопрос – что мешало организовать этот буфер в системном ОЗУ и побольше? Ладно, во времена, когда каждый мегабайт ОЗУ был на вес золота, но сейчас продолжают делать жесткие диски с похожими буферами. Это и кэшем-то с сегодняшними объёмами серьезно не назовешь. Да и по факту он скорее содержит адресные данные для быстрой обработки, нежели пользовательскую информацию. Поэтому при росте объемов дисков этот мизерный кэш увеличивать было жизненно необходимо, иначе тормоза только на стадии адресации были бы эпические.

Время шло, общие системные возможности росли, а НЖМД не особо ярко прогрессировали в плане скоростей. Т.е. рост, конечно, какой-то был, но такой, что его даже в рекламу было неудобно выносить. С объёмами хранения все шло сильно лучше, а вот со скоростями глобально — печалька.

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

Гонки на костылях

В 2005-м году Intel представила технологию Intel Turbo Memory. Идея заключалась в том, что на мат. плату ноутбука с тормозным традиционным винчестером компания предлагала устанавливать в miniPCI-E модуль из целого гигабайта (позже — аж двух) флэш-памяти.

По сути это был аналог твердотельного накопителя. На уровне драйверов и чипсета этот модуль должен был использоваться для переноса на него части популярных данных, например, используемых в ходе загрузки ОС, с тормозного накопителя и в дальнейшем такие данные должны были в первую очередь читаться с быстрого твердотельного накопителя, а не с HDD. В итоге загрузка с использованием костыля из гигабайта флэша происходила ощутимо быстрее по причине лучших характеристик на чтение флэш-модуля. Использование технологии предполагалось не только для ускорения загрузки, но и для прочих данных. Т.е. это жизнеспособная технически реализация программно-аппаратного кэширования медленного жесткого диска в более быстрый и, главное, энергонезависимый флэш. Поэтому-то запуск и ускорялся. На практике дело было неоднозначным — у некоторых пользователей загрузка наоборот замедлялась.

Идея была не сказать, что инновационной по сути — выше вы прочитали, что концепция кэширования была известна давно. Но Intel впервые в широкой практике применила инновации в сфере накопителей и это кое-как работало. Особенно учитывая, что в ноутбуках 2005-года теоретическим потолком объема оперативной памяти были 4 гигабайта, а на практике сплошь и рядом хорошо если 1–2. В такой ситуации костыль из гигабайта флэша смотрелся совсем не как бедный родственник, но… Но это Intel, а значит были и особенности, ставшие впоследствии граблями. Дело в том, что концепция была дважды аппаратно зависимой. Во-первых, все это было завязано строго на конкретные чипсеты, начиная с 965-го в ноутбуках, а во-вторых — сам флэш-модуль был проприетарным и как гигабайтный накопитель самой системой не виделся. Да, от представления идеи до продукта прошло почти 2 года и железки были строго для внутриплатформенного использования.

Ах да, для десктопов было представлено аналогичное решение с интерфейсом PCI Express x1.

Для любителей нестандартных подходов можно было сделать даже так:

Где-то мы это еще увидим.

А пока мы вспомним, что аналогичные концепции пытались эксплуатировать в Microsoft Vista в виде технологии ReadyDrive. Идейно это мало отличалось от Intel Turbo Boost, но работало, по отзывам, кривовато. Для ускорения загрузки и восстановления после гибернации предполагалось использовать внешний флэш силами ОС.

Отдел маркетинга Microsoft тогда же продвигал отдельную технологию — ReadyBoost. Она существует по сей день и более-менее работает. Суть ее заключается в том, что если у вас есть свободное место на скоростном накопителе, например, на быстрой «флэшке» в USB 3.0, то система предложит отвести часть этого свободного места для кеширования работы ОС. Естественно такая затея будет иметь хоть какой-то смысл только в том случае, если лишнее свободное место у вас имеется на носителе, который в общем быстрее системного. Для этого при настройке работы свободного накопителя для ReadyBoost будет оценена его производительность и сделан вывод — имеет смысл его использовать в текущих условиях или нет. Так быстрая «флэшка» в системе с HDD может дать некоторый прирост отзывчивости при размещении на ней технологией ReadyBoost каких-то часто употребимых данных, но она же в системе с SSD будет бесполезной. Основной упор технологии на практике приходился на ноутбуки и нетбуки с малым количеством ОЗУ и системными жесткими дисками. Кэширование системных данных с помощью относительно быстрых «флэшек» и SD-карточек позволяло несколько сгладить нехватку оперативной памяти и соответствующую этому «пилежку» файла подкачки на и без того тормозном системном накопителе.

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

Хотелось бы отметить, что это совсем не значит, что ее «потанцевал» был концептуально исчерпан. Напротив — как мы увидим в дальнейшем — пути развития были, но Microsoft по непонятным причинам их проигнорировала, несмотря на достаточно неоднозначную реализацию кеширования как такового штатными средствами своих ОС даже в случае внушительных объемов оперативной памяти.

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

Где еще можно встретить кэширование?

Здесь надо сделать небольшое отступление на тему идеи кэширования в популярном ПО. Идея эксплуатируется «аж гай шумит». Ведь если ПО оперирует какими-то повторяющимися данными, то размещение их копий в быстрой памяти будет сильно повышать отзывчивость ПО для пользователя по сравнению с «пилежкой» обычного диска любого типа. Если за дело возьмутся ОС и само ПО вместе, то эффекта можно добиться, размещая кэш (как данные) в кэше (как носителе), адресованном в ОЗУ. Такая вот тавтология — под кэшем понимают как сами популярные данные относительно какого-то приложения или процесса, задублированные в быстрой памяти, так и саму эту быструю память, как часть общей памяти. Но мы помним, что для наблюдения эффективности от этого процесса данные сначала надо прочитать с медленного источника для дублирования в быструю память. Если быстрая память при этом энергозависима, то будет как выше по Блоку — т.е. чтение каждую перезагрузку. Но если относительно быстрая память энергонезависима, то сделать это придется лишь раз и в дальнейшем только валидировать актуальность размещенного там. Медленные же источники могут быть в принципе любыми в т.ч. и сетевыми. Т.е. условное ПО может для работы тянуть что-то из сети с неизвестными пингами, т.е. задержками, а может разово сделать копию запрашиваемого и если данные в сети и локальные в кэше окажутся одинаковыми по контрольным суммам, то вполне вероятно, что прочитать их «по месту» будет надёжнее и быстрее, а что изменилось или новое — загрузить дополнительно или даже параллельно. Таким образом, задача из смеси типичных элементов и новых данных может загружаться в несколько потоков — стабильные данные из локального источника в виде кэша, а новые — из сети. Узнали? Да — типичная страница новостей, где элементы интерфейса меняются редко, а сам по себе контент не такой уж и тяжелый.

Т.е. если наш браузер умеет в кэш, то он когда-то прочитает некую страницу и запишет ее в свой локальный кэш (в оперативной памяти или накопителе). При следующем ее запросе она будет поделена на данные, которые не изменились и все остальное. В итоге повторная загрузка, если страница статична, может пройти вообще целиком из кэша, если браузер получит уведомление, что с последнего посещения изменений не было. На n-ый раз страницу можно перенести из кэша в ОЗУ в кэш на накопителе и таким образом сильно улучшить скорость ее последующего отображения даже после перезагрузки, вместо чтения из сети.

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

Браузинг под кэшем

В реальности все браузеры умеют в кэш. Для примера рассмотрим мой случай с Opera. В разделе «меню-справка-о программе» можно найти прямую ссылку на место хранения кэша «Оперы». У всех «хромиумов» это будет аналогично, а у «нехромиумов» примерно так же с незначительными отличиями. Так вот ссылка эта для моей «Оперы» для разработчиков выглядит так C:/Users/Z/AppData/Local/Opera Software/Opera Developer/Cache (у себя поправьте название профиля). По ней можно узнать, что в кэш у меня «Опера» записала аж 400 мегабайт на сессию из 130 активных вкладок. Там конечно есть данные и из прошлых вкладок, но для общей ориентации в вопросе нам достаточно этого. Этого и осознания того, что состоит он почти из 1900 файлов.

400 мегабайт и 1900 файлов дадут нам вот примерно такой средний размер файла в сформированном кэше.

«Хромиум» пишет кэш не файлами напрямую, а разделяя данные вот таким собственным образом.

Зачем я привел эти скрины? А затем, что работа типичного браузера со своим локальным кэшем на энергозависимом накопителе это постоянная работа со случайными мелкими файлами. И нередко тормоза при открытии любимой страницы могут быть обусловлены тем, что часть ее читается из локального кэша на НЖМД, когда Windows 10 решила внепланово отстучать товарищу майору. Т.е. диск будет загружен работой полностью и весь мир подождет. Логику вопросов приоритетности чтения с кэша на HDD в век широкополосного интернета у меня не спрашивайте. Даже банальный монитор ресурсов покажет, что «Опера» постоянно что-то пишет и читает. Более глубокое изучение вопроса покажет тысячи постоянных обращений. Внезапно «Опера» оказывается неслабо зависима от дисковой подсистемы. Это то самое популярное ПО, о котором мы сейчас и поговорим — браузеры есть у всех читающих этот текст и работают они сегодня более-менее аналогично.

А кто у нас умеет хуже всех в рандомную нагрузку работой с мелкими файлами? Правильно — жесткий диск. Хуже всех, но данные могут быть таки сохранены, что, собственно, и объясняет, зачем же вообще кэш размещать на тормозном носителе. Сеть может быть и недоступна. Или плохо доступна. А местами она так вообще доступна очень и очень медленно. Это мы разбалованы 100-мегабитными и даже гигабитными каналами в каждую квартиру, а у людей все бывает гораздо хуже.

А кто умеет в радомную нагрузку с мелкими файлами лучше? Конечно же SSD. Именно потому, что практически ВСЯ офисно-домашняя нагрузка это практически аналогичная работа с мелкими файлами, SSD и показывают такие чудеса субъективного ускорения работы системы, будучи установленными в относительно старые компьютеры и ноутбуки.

А кто же умеет лучше всех? Правильно — ОЗУ, но в ОЗУ установить сам браузер, перенести туда профиль пользователя или кэш штатными средствами ОС нельзя. А нештатными — вполне можно и даже нужно для просмотра того, как это работает. Чтобы понять, как это все может шевелиться, даже на древних системах, есть три способа.

Первые два:

• Установить железный RAM-диск в качестве накопителя, увидеть его в системе как пустой диск и проинсталлировать туда браузер целиком. Тогда он будет весь работать фактически из ОЗУ. И хорошо, надо сказать, будет работать — мгновенно запускаться и переключаться между вкладками! Все упрется в прямом смысле слова в возможности процессора. Но таких чудесатых вундервафель сегодня почти не найти, да и поустаревали они, и поэтому мы переходим к следующему пункту.
• Имея в системе пару свободных гигабайт оперативной памяти для эксперимента скачать программный RAM-диск и провести процедуру из п.1. Программный — это ПО, которое создаст в среде Windows (в нашем случае) за счет части ОЗУ виртуальный накопитель и проассоциирует его с реальной буквой диска в списке существующих. Для системы это будет выглядеть вполне настоящим накопителем, хотя на практике это будет всего лишь хитрый драйвер со сложной логикой трансляции адресов физической памяти. Программных RAM-дисков масса, но я советовал бы ознакомиться с двумя — SuperSpeed RamDisk Plus и Primo Ramdisk. Важной особенностью этих программ является способность сохранять содержимое RAM-диска на физический накопитель при перезагрузке и дальнейшее монтирование такого образа назад при запуске системы. Т.е. для пользователя такой RAM-диск по сути выглядит обычным накопителем. Да, в дальнейшем на таком своеобразном накопителе можно запустить какой-нибудь CrystalDiskmark и сильно удивиться результату. Обе программы имеют пробные полнофункциональные версии, что позволит легально их изучить. На дату написания статьи сайт SuperSpeed почему-то недоступен, но Primo Ramdisk можно скачать по ссылке.

Устанавливается и настраивается все очень просто. Диалог настройки выглядит примерно так:

Важной особенностью программы является тот факт, что если у вас, например, 32-битная ОС, но есть возможность поставить физически больше, чем 3 ГБ оперативной памяти, то RAM-диск можно будет разместить в этой недоступной для ОС памяти. Туда, например, в таком случае можно будет подкинуть и файл подкачки Windows. Называется это невидимая память по терминологии программы.

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

Промежуточные итоги

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

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

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

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

Мгновение гибридов в истории

Примечательно, что некоторые серии этих изделий были просто физически двумя почти независимыми накопителями в одном корпусе, но с одним разъемом интерфейса. Т.е., в общем-то, их можно было смело скручивать изолентой и эффект был бы тот же. Называется это SSHD Dual Drive. В аналогии с телефонами и камерами это выглядело бы примерно так.

В качестве примера можно привести WD Black Dual Drive WD1001X06X — он реально состоит из двух фактических накопителей, скрученных винтами.

Получать все плюшки от недогибрида предлагалось с помощью дополнительного ПО своими руками. Т.е. можно было для ReadyBoost назначить отдельный накопитель в составе такого типо гибрида, т.к. все потроха виделись системой как два отдельных накопителя, но даже такое видение происходило не без танцев с бубном. Идея, прямо скажем, нишевая и для широких масс, любящих решения, работающие «из коробки» — неподходящая.

Конечно, не могли не появиться варианты, где флэш использовался для кэширования механической части более-менее по-человечески. Какие-нибудь аж 8 гигабайт флэша пользователю были не видны и утилизировались прошивкой и контроллером гибрида по понятным только им алгоритмам. Хотя общая идея была ясна — часточитаемое задублируется во флэш (а то и перенесется), а контроллер будет следить за актуальностью находящегося там. Может, что и из записи там тоже задержится.

В качестве примера приведем Seagate Desktop SSHD ST2000DX001 — два магнитных терабайта, 8 твердотельных флэш гигабайт и 64 мегабайта DRAM в одном кузове.

Работает это все несколько лучше, чем типичный жесткий диск. Как мы помним, обычные HDD уже давно оснащались DRAM-буфером. Правда его размер был обычно маленьким и на нагрузках, хоть как-то отличающихся от простоя, толку от него было немного. Вот здесь WD в 2019-м году не улыбаясь рассказывает коротко о преимуществах жестких дисков с буферами от 2 (ого!) до 64 мегабайт. Главный вывод: чем кэш-буфер больше — тем лучше. Хоть это верно, правда, чем он больше, тем мощнее надо быть контроллеру в общем случае.

На этом фоне не может не возникнуть вопрос — почему же на многотерабайтных механических «винтах» кэш-памяти кот наплакал? Ну какие же могут быть 64 мегабайта у диска с лошадиным временем отклика сегодня? Ну, даже 256?

В этом ключе твердотельная кэш-память внутри гибридов выглядела идейно неплохо, но на практике это все работало (и работает) слабенько по сравнению с чистыми твердотельниками по такими причинам: даже 8 гигабайт твердотельного кэша в гибриде — маловато будет.

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

В общем, чисто по Блоку — Бессмысленный и тусклый свет.

И замах, т.е. идея хорошая: вроде и концепция правильная заложена, и иерархия построена, и обслуживать пользователю никак не надо, и вникать нет необходимости в нюансы работы — поставил и забы(и)л, но удар, т.е. реализация — в штангу.

SSD без кэша не бывает

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

Случайно читать относительно быстро (50–60 мегабайт в секунду у лучших представителей SSD) можно прямо из массива с поправкой на крутость контроллера (здесь мы не останавливаемся, но тема контроллеров накопителей требует отдельного изучения — по сути, это сегодня уже многоядерные специализированные процессоры в составе «дисков», особенно твердотельных, и от их производительности и возможностей прямо зависят скорости работы накопителя) и канальность. Увеличить это можно только либо развивая твердотельные технологии, в т.ч. по части контроллеров, в сторону типа 3DXpoint, где можно читать случайно со скоростями до 300 (!) мегабайт в секунду, либо… предварительно кешируя прочитанное в более быструю память, т.е. в системную оперативную или собственный DRAM-буфер такого накопителя, которые, опять же, большими бывают нечасто и объемы DRAM-буферов обычно растут с рабочими объемами и… ценами же. Происходит так потому, что DRAM в SSD (да и в обычных HDD немного иначе, но тоже) используется в основном опять же для служебных данных типа таблиц соответствия (адресации) и т.п. Мы же помним, что логическому адресу данных, который «понимает» ОС, контроллером присвоится физический адрес внутри носителя, где движение данных происходит постоянно, но для внешнего мира адреса не меняются благодаря работе контроллера, как посредника между внутренним массивом и внешними контрагентами, которые вообще никак не подозревают, что там происходит внутри SSD в ходе TRIM и прочих процессов. Поэтому, кстати, при выходе контроллера из строя восстановить с SSD, состоящего из более чем одного чипа памяти, данные практически невозможно т.к. только контроллер «знает», опираясь на указанную таблицу, что и куда он распределял по твердотельному массиву. Т.е. рост объема DRAM-буфера — прямое следствие роста рабочего объема накопителя при заданной производительности контроллера. Нет, частично там что-то и из данных может задержаться, но это не точно. Типично сегодня можно встретить гигабайт DRAM-буфера на терабайт твердотельного накопителя. Как конкретно он используется и распределяется прошивкой — опять же широкой общественности неизвестно. Можно пытаться восстановить логику по результатам целевого тестирования, но смысл в этом будет только исследовательский, т.к. управлять ей не предлагается.

Со случайной записью картина аналогичная — быстро и случайно записать в массив не получится в общем случае. Поэтому запись тоже кэшируется — данные попадают сначала в самую быструю память, т.е. в кэш-буфер, и потом фоново переносятся в основной массив. Если DRAM-буфер задействован и заканчивается или его вообще не предусмотрели конструкцией, то в твердотельных дисках отводится часть основного массива, который, работая в быстром однобитном режиме, принимает входящий трафик сначала на себя, а потом, например, во время простоя или слабой нагрузки, фоново внутри накопителя без участия пользователя переписывает все свое содержимое в основной массив, усиливая показатели записи. Сегодня такое внутреннее кэширование осуществляется как фиксированными областями, работающими в быстром SLC-режиме, так и динамическими — вплоть до 40+ гигабайт у Samsung 860 QVO на терабайт тормозной QLC и 80 (!) гигабайт — на 2 ТБ модель. Обычные люди называют это кэшированием записи. Маркетологи Samsung преподносят это как специальную технологию TurboWrite! Видимо где-то на повороте потерялись слова мега, х1000 и прочие маркетинговые eye-стопперы. Ну, либо они оставлены на будущее.

Благодаря такому кэшированию, если базовый массив что в SDD, что тем более в HDD, относительно тормозной, то в случае объемной записи пользователь может благодаря местами огромной (до 80 гигабайт) быстрой «прокладке» вообще не ощутить медленности основной памяти накопителя. Вы часто пишите ходом более 40 гигабайт? Я — нет. И вы, уверен, в основном тоже. Поэтому все текущие операции будут происходить в быстрой памяти кэш-прокладки и лишь потом фоново переноситься на медленный массив для хранения.

Вы только что прочитали заготовку рекламной компании OLC SSD. Ой, я это вслух?

Важная деталь — если чтение записанного будет запрошено у накопителя системой ДО момента переноса данных из кэш-посредника в основную память, то такое чтение произойдет из кэша с соответствующей высокой скоростью. Если кэш будет в DRAM, что маловероятно, но, тем не менее, то обратное чтение будет осуществлено фактически со скоростью близкой к оперативной памяти, но в массе для SSD это кэш, где из основного массива, как упоминалось, выделяется часть для работы в быстрых режимах SLC. Все эти нюансы не предлагается настраивать пользователю. А зря.

Именно поэтому в ряде популярных тест-утилит скоростей SSD если тестовый образец, сгенерированный программой, поместится целиком в такую прокладку и будет тут же прочитан в ходе теста, то эти самые утилиты могут показывать скорость именно быстрой прокладки, а не основного массива! Некоторые производители, зная любовь тестировщиков к таким утилитам и логику работы самих утилит, закладывают в логику работы прошивок такое обращение с типичными тестовыми зданиями, что в ходе теста исследователь видит скорость именно кэша и сильно радуется нерелевантным по сути цифрам. Такой себе аналог дизельгейта. Можно сказать — мухлюют.

Здесь появляется дилемма. С одной стороны это непоказательно по очевидным причинам — тестируется же накопитель, а не его кэш! С другой — если за пределы кэша еще надо ухитриться выйти, то какая разница, какая там скорость за его пределами, если ее мы никогда почти не увидим?

С третьей стороны — во многих накопителях есть еще и DRAM-буфер из ОЗУ-подобной памяти (на самом деле это она в виде отдельных чипов и есть) и какой вклад именно она, если в конкретном случае таки присутствует, дает в показатели тестирования — тоже отдельный вопрос методики подведения итогов.

Важное читать здесь

Главный вывод — никаких чистых жестких или твердотельных дисков не существует. Везде, абсолютно везде существует иерархические системы памяти с кешированием как записи, так и чтения. Разница лишь в том, как конкретно это реализовано. Твердотельные накопители, в общем, сильно быстрее традиционных жестких дисков, но и там и там все устроено концептуально похоже. Конкретные же решения формируются под воздействием рыночных факторов (например, размер DRAM-буфера может быть обусловлен сегодняшними ценами на чипы памяти) и доступности тех или иных технологий производителю, а так же… психологии.

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

Кстати о неслышимых частотах, если с психоаккустикой теоретически все более-менее понятно, то, например, в автомобильных моно-усилителях, заточенных на низкие частоты, нередко присутствует функция subsonic — это фильтр, отсекающий частоты ниже порога, который физически слышим и может быть воспроизведен конкретной головкой. Купирование лишней нагрузки позволит улучшить работу сабвуфера в диапазоне целевой нагрузки без ущерба для слушателя. Конечно, звукофилы возразят, что это не true и инфразвук нужно прочувствовать почками и в целом будут технически правы, но 99,(9)% слушателей разницы не ощутят ничем и ушами в первую очередь.

Теория идеального накопителя

Но вернемся к нашим накопителям и пирамиде. Идеальному накопителю бы работать со скоростью внутрипроцессорной памяти и быть большим и энергонезависимым, и тогда все остальное можно было бы просто отнести в музей, но до этого счастливого момента пройдут десятилетия, если не века. Самой же процессорной памятью мы управлять не можем снаружи никак. Оперативная память пока еще энергозависима. Intel обещает с этим что-то делать, но результаты мы пока пощупать не можем. Поэтому использовать ее мы можем и должны при сегодняшних колоссальных технически доступных объемах традиционным сегодня же способом, т.е. помимо основной функции еще и в качестве кэша накопителей. По сути, операционные системы это делать умеют, но получается не очень эффективно. Далее идут в общем виде SSD, которые пока на солидных объемах все еще недешевы (хотя цены и падают) с проблемами длительного хранения, условного износа, растущей битности и утончающихся техпроцессов — еще немного и космическое излучение начнет в прямом смысле мешать электронам правильно сидеть по дуплам твердотельной памяти. Следом видим огромные по объемам энергонезависимые магнитные жесткие диски, способные хранить данные десятилетиями, но медленные и подверженные механическому износу, боящиеся вибраций и тепла. Дальше по иерархии идти смысла нет. Идеального накопителя не существует. Его пытались сделать и пример мы видели выше, но первый блин оказался комом и дальше инженеры не пошли на фоне дешевеющих SSD. И уже, видимо, не пойдут.

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

Как мы увидели в начале — все данные можно условно поделить на холодные, теплые и горячие по критерию востребованности пользователем. Поэтому, в первом приближении нам бы избавиться от обычного «винта», но объемные SSD – дорогие, а хранить архивы в облаках затея сомнительная, т.к. я еще не видел ни одного юридического документа, где была бы предметно описана не только ответственность облачного провайдера за потерю пользовательских данных, но и прямая обязанность обеспечить их гарантированную сохранность. Даже в странах с развитой правовой системой получить компенсацию за утерю таких данных от провайдера будет сложно, т.к. все упрется в денежную оценку пропажи, которая может иметь нематериальную ценность (например, семейный фотоархив). И все. В идеале иметь прямой контракт с провайдером с описанием условий хранения и конкретной ответственностью, но это утопия для широкого круга лиц. Конечно современные технологии хранения сводят вероятность безвозвратных потерь к низким значениям – все дублируется многократно с избыточностью, но это и стоит недешево. С другой стороны, если какие-то условные злоумышленники в ходе воображаемого террористического акта разрушат целиком недецентрализированный дата-центр провайдера облачного хранения, то с концами будут утеряны не только все данные, но и возможность компенсаций, т.к. подобного рода события в большинстве случаев являются форс-мажором. Имущество провайдера, конечно, скорее всего, будет застраховано, но клиенты — нет. Или будет предложена такая финансовая модель защиты интересов клиента, что проще и дешевле будет обставиться NAS, подкинуть их с постоянным IP в онлайн за NAT и не париться. И я это вполне серьезно на фоне того, что даже банки не несут ответственности за пропажи из ячеек.

В пересчете на гигабайт и сроки хранения традиционные жесткие диски пока недосягаемы для SSD, а на подходе 40 гигабайтные монстры в 3,5-дюймовом стандартом корпусе. Сотки тоже не за горами. В общем, отказываться от традиционного HDD для холодного хранения тем, кому это надо, смысла особого нет. У друзей-дизайнеров огромные архивы работ, которые хоть и сданы заказчикам, но удалять их мало кто решится. У кого-то семейные архивы. У кого-то видео, RAW и т.п.

Т.е. базой будет технологически традиционный жесткий диск.  Опять по Блоку:

Живи еще хоть четверть века —
Все будет так. Исхода нет.

Далее таковой бы закэшировать на чтение и запись прокладкой побыстрее. Идеально бы чем-то вроде оперативной памяти, но ее нужно будет много, а стоить она в этих объемах будет дорого. А еще энрегонезависимость. Поэтому из вменяемого сегодня доступна память твердотельная. Т.е. по иерархии выше нам бы поставить SSD, через который транзитом данные бы отсрочено оседали на холодом жестком диске и на который можно было бы автоматически дублировать популярные данные типа системных файлов ОС, браузеров и прочее, которые читаются хотя бы раз в неделю-месяц. Если данные не востребованы, то с такого SSD они удаляются, оставаясь на холодном винте. А если вы пару недель-месяц не обращались к файлу, то следующее его прочтение с медленного винта с одновременным копированием на SSD кэш проблемой быть никак не должен. Будете с ним работать — он будет читаться с быстрого SSD, измените — изменится и на HDD, не будете с ним работать — он останется на жестком диске, освободив место на SSD. Примерно так и были задуманы SSHDD, но 8 гигабайт явно мало. Да и неплохо бы иметь возможность эту кэширующую прокладку менять произвольно на лучшую из доступных пользователю.

При всех замечательных особенностях SSD они сами нуждаются в прокладке и памяти еще боле быстрой. Типичный подход решения вопроса — DRAM-буфер. Решение актуальное, но маленькое и в основном служебное. И, опять же, недоступное к расширению под конкретные нужды. Гигабайт на терабайтном SSD более-менее неплохо, но в мейнстриме-то накопители поменьше с меньшими кэш-буферами. Поэтому в идеале для нашего сферического накопителя иметь внешний буфер на основе ОЗУ-подобной памяти, доступной к произвольному конфигурированию под конкретные нужды. Тут на ум приходит рассмотренный выше аппаратный RAM-драйв — там и скорости были бы и прочее. Но для современных типов памяти таковых на рынке 0,5 штуки (да, я встречал одно решение, но именно одно и очень редкое и дорогое) да и по-хорошему — аппаратный RAM-диск уже не нужен. Его время было тогда, когда чипсеты не поддерживали много ОЗУ, а сегодня 128 гигабайт можно почти в каждую SOHO плату с 4 слотами поставить, а завтра это цифра удвоится. Серверное железо мы выносим за скобки данной статьи сознательно.

Если были и есть аппаратные RAM-драйвы, то почему бы сегодня софтверно не отвести часть ОЗУ под дисковый кэш? Технически и программно в этом нет никаких проблем, но производители последней ОС почему-то не задумываются об этом, предлагая штатное кэширование, которое нельзя конфигурировать и которое работает по нераскрытым алгоритмам.

Таким образом, теоретический и воображаемый идеал на все случаи = ОЗУ+SSD+HDD + динамическое распределение данных по актуальности.

И чем это принципиально лучше Seagate SSHD выше по тексту?

Как минимум тем, что новых SSHD уже не будет. Их жизненный цикл начался в 2007 году, когда Seagate и Samsung представили решения со 128 и 256 мегабайтами флэша. А закончился фактически в 2013-м с выпуском WD Black SSHD с 24 гигабайтами флэша. Сегодня перспектив дальнейшего их развития не видно никаких, а открытая архитектура современного компьютера позволяет реализовать описанную выше концепцию на типичных розничных компонентах в конфигурации под любой кошелек. В портативную технику городить все это вообще давно нет смысла — там SSD обеспечит и скорость, и компактность, и вибронезависимость, а в десктоп что-то плотно упаковывать тоже бессмысленно, когда везде middle-tower.

Внимательно изучив ситуацию становится очевидно, что описанное по факту уже реализовано в нескольких похожих ипостасях. Выше мы читали про Intel Turbo Boost с проприетарным кэширующим модулем. В 2011 опять же Intel представила Smart Response Technology. Опять же проприетарную технологию, привязанную к чипсетам, которая позволяла использовать для кэширования жестких дисков до 64 гигабайт подключенного SSD.

Про Microsoft ReadyDrive и ReadyBoost написано выше.

С разными особенностями, но можно констатировать, что у Apple похожая технология называется Fusion Drive. В ее рамках складываются объемы доступных накопителей, и данные динамически распределяются по ним в зависимости от востребованности. ОС и важные документы всегда закешированы на более быстром носителе. Но технология сильно закрытая и тоже проприетарная.

Следующий прорыв в области кэширования совершила опять же Intel. В 2015 она сообщила, что изобрела революционную технологию твердотельной памяти 3D Xpoint. Революционную = дорогую. Заявка была такая.

Окажись все правдой, то мы бы сильно приблизились бы к идеалу накопителя — быстрому и объемному RAM, по версии IBM из 50-х. Накопители на этой технологии вышли на рынок под торговой маркой Optane и оказались фантастически быстры. Достаточно сказать, что в основной твердотельной дисциплине — случайном чтении мелких файлов с глубиной запроса 1 — Optane способен показать скорости около 300 мегабайт в секунду. Это минимум в 5–6 лучше ближайших массовых преследователей от Samsung. Таким образом, среди твердотельных накопителей Optane оказался несомненным лидером не только по скоростям, но и, к сожалению, по ценам. В перспективе на этой технологии Intel обещала энергонезависимую оперативную память, что еще более сильно концептуально приближается к идеалу из самого начала статьи. Сегодня таковые объявлены для серверного рынка, но изучить их пока возможности не было.

В связи с тем, что Optane оказался очень быстр и очень дорог, Intel решила предлагать его на рынок в маленьких дозах — NVMe-накопителями по 16 и 32 гигабайта. Еще раз — 16 и32 гигабайта под конец второй декады 21 века. Но предлагала Intel это счастье, в первую очередь, как кэширующий модуль, привязанный к собственному железу в виде чипсетов и процессоров. Т.е. разработчик предполагал, что у клиента, купившего систему 7 поколения Intel, будет системным жесткий диск. Изначально требования были выше по процессорам, но потом были понижены вплоть до Celeron, что намекает на чисто программные ограничения.

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

С учетом скоростей на мелких файлах Optane впору кэшировать лучшие SSD. Идеал виделся как-то так:

Скорость кэширующих модулей примерно такова: фантастика на чтение рандомной мелочи и более-менее на запись. Но запись особо и не важна, т.к. запись дополнительно кэшируется в оперативной памяти. Далее данные попадут на Optane и только потом на жесткий диск или SSD.

По скоростным показателям Optane — лучшая и недосягаемая на рынке кэширующая прокладка между ОЗУ и накопителем, но она, как и TurboMemory в прошлом, привязана к железу, что очень портит картину: ведь купившие новое железо вряд ли позарятся на жесткий диск, как системный.

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

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

Из совсем экзотики на эту тему приведем напоследок два полярных технологических примера.

Твердотельный накопитель из 4 гигабайт SLC NAND с кэшем из 4 гигабайт DDR для PCI Express x1 — вполне себе вариант для кеширования более медленных накопителей, правда, стоил 2000 USD в 2009 году.

И OCZ RevoDrive Hybrid — плата со 128 ГБ MLC, аж двумя контроллерами SandForce SF-2281 и 2,5″ НЖМД на борту с частотой вращения 5400 оборотов в минуту. DRAM-буфера почему-то не предусмотрено вообще никакого, флэш распаян. Системой виделась как два независимых устройства, для сочленения которых с целью кэширования, требовалось внешнее комплектное ПО Dataplex c минимумом настроек. Скручено натурально изолентой, т.е. болтами.

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

Но в связи с Optane и до 128 гигабайт памяти на современных материнских платах таких и подобных гибридов, мы, скорее всего, уже никогда не увидим, как и реалий из фильма, кадр из которого приведен. Музейные экспонаты. Хотя пути Господни неисповедимы, а в IT очень любят работать с оглядкой на религию, особенно в Apple, где маркетологи прямо называются евангелистами, а в свою экосистему пускают через посвящение (iTunes) с усложнением обратного выхода. Но мы отвлеклись.

Возможно, вы не полностью используете возможности своего железа

Отдельно стоит упомянуть достижения некоторых производителей SSD в сфере кэширования. Так Crucial и Samsung поставляют ПО, которое умеет кешировать их изделия за счет части свободной оперативной памяти машины, где они установлены. Происходит это совершенно незаметно для пользователя. В случае с Crucial можно кешировать и HDD SATA, подключенные к машине, где системным диском является изделие Crucial. Называется Momentum Cache. Таким образом, закостыливается маленький объем физического DRAM-кэша в накопителях или его полное отсутствие в дешевых сериях, а также нюансы внутринакопительного кэширования самого по себе. ПО бесплатное и беспроблемное.

А как вообще в миру?

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

Второй проблемой является то, что каждым решением закрыта лишь какая-то часть общей идеальной задачи по кэшированию. Системного решения вопроса именно в SOHO никто не предложил, хотя из представленных концепций прямо проистекает, что каких-то непреодолимых или железных преград в этом вопросе нет.

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

Вот логика.

А вот условный пример трехуровневой «железки».

Здесь же реализовано SSD-кэширование с сохранением наиболее актуальных данных в SSD-кэше.

Т.е. концептуально все имеет решения типа Cache Acceleration Software, но в SOHO их почему-то под открытую архитектуру комплексно и широко не продают.

Но, 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 скорость мелкоблочки так возрасти не могла, разве что из-за распараллеливания нагрузки. Т.е. самое интересное по теме у нас впереди и оно уже становится более-менее доступно в ритейле.