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