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