Зачем нужен буферный кэш

Обновлено: 02.07.2024

Буквально несколько дней назад на моём подопытном стенде побывали два накопителя торговой марки Crucial - BX500 120GB и BX300 120GB . Что наиболее интересно в данном предложении - это возможность сравнить быстродействие двух накопителей в максимально равных условиях. Оба этих накопителя построены на основе контроллера SMI2258 и микросхем памяти 3D TLC типа производства Micron Technologies, выполненых по 64-х слойной технологии, но есть небольшая разница - вся аппаратная разница между двумя этими устройствами заключается в наличии в модели BX300 микросхемы DDR3-типа, которую контроллер использует в качестве оперативной памяти, храня в ней информацию о расположении файлов в ячейках памяти. Обычно такая микросхема имеет ёмкость из расчёта 1 Мегабайт на 1 Гигабайт ёмкости устройства, т.е. в данном частном случае в накопителе Crucial BX300 120GB установлена микросхема DDR3 ёмкостью 128 Мегабайт.

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

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

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

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

Альтернативное средство оценки быстродействия показывает ровным счётом тоже самое - разве что в данном случае используется бОльшее число потоков - 64, что ещё бОльшим образом нагружает "мозги" контроллера накопителя. Прирост производительности при записи здесь составляет порядка 10% (всё-таки при равном контроллере наибольшие издержки несёт именно контроллер и микросхемы памяти), а вот при чтении - прирост составляет почти 85%. Вот что значит "держать перед собой оглавление" - наличие быстрого индексного поиска позволяет работать на максимальной скорости самого "читателя".

Что ещё интересно - накопитель с DRAM буфером имеет время доступа при чтении и записи практически одинаковое, а вот у накопителя без DRAM буфера это время различается в 5 . раз.

Имитационные тесты тоже заметно благоволят более дорогому устройству, давая ему от 3 до 15% преимущества.

В сухом остатке заканчивать статью фразой "ну вот видите, я же говорил" довольно глупо, но по-другому и не получается. Буфер оперативной памяти в дополнение к имеющейся оперативной памяти в самом контроллере позволяет заметно ускорить работу всего устройства в наиболее "узких" и тяжёлых местах; когда накопитель нагружен одновременными задачами чтения и записи, сгенерированными разными программами. На мой взгляд, наиболее востребованная функция накопителя при использовании в качестве места хранения программ, использующих файловые базы данных.

Устройство буферного кэша

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

Есть 3 варианта размера страниц:

Буферный кэш занимает большую часть общей памяти.

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

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

Алгоритм вытеснения

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

В PostgreSQL реализован алгоритм вытеснения страниц из буфера при котором в кэше остаются самые часто используемые страницы.

Журнал предзаписи (WAL)

После сбоя наша база становится рассогласованной. Какие-то страницы менялись и были записаны, другие не успели записаться.

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

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

Почему запись в WAL эффективнее чем запись самой страницы? При записи страницы памяти на диск она пишется в произвольное место, это место еще нужно выбрать, подготовить для записи и начать запись. А запись в журнал ведется одним потоком и с этим потоком нормально справляются и обычные жёсткие диски и ssd.

WAL защищает всё что попадает в буферный кэш:

страницы таблиц, индексов;
статусы транзакций.

WAL не защищает:

временные таблицы;
нежурналируемые таблицы.

Производительность WAL

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

В асинхронном режиме postgresql работает быстрее, но вы можете потерять некоторые данные при сбое.

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

Следующие параметры отвечают за режим работы WAL:

Контрольная точка

Сброс данных при контрольной точке не проходит моментально, это бы сильно нагрузило наш сервер. Чтобы не было пиковых нагрузок сброс идет примерно 50% времени от времени между контрольными точками. Например, контрольные точки делаются каждую минуту, тогда сброс осуществляют плавно в течении 30 секунд. Это регулируется и вы можете установить например 90% времени.

Контрольная точка также уменьшает размер необходимого дискового пространства. Так как весь журнал WAL не нужен, его можно периодически подрезать.

Отдельный серверный процесс контрольных точек автоматически выполняет контрольные точки с заданной частотой. Эту частоту можно настроить следующими параметрами:

Значения по умолчанию: 5 минут и 1 Гбайт, соответственно. Если после предыдущей контрольной точки новые записи WAL не добавились, следующие контрольные точки будут пропущены, даже если проходит время checkpoint_timeout. Также можно выполнить контрольную точку принудительно, воспользовавшись SQL-командой CHECKPOINT.

Уменьшение значений checkpoint_timeout и max_wal_size приводит к учащению контрольных точек. Но появляется дополнительная нагрузка на сервер.

Процессы, связанные с буферным кэшем и журналом

Уровни журналов

Практика

В журнале WAL каждая запись имеет номер LSN (Log Sequence Number). С помощью функции pg_current_wal_lsn() можно посмотреть номер текущей записи:

У нас вышло 138 KB! Так много получилось из за создания таблички, создание 1000 строк почти не нагрузит WAL.

Физически журнал хранится в файлах по 16 МБ в отдельном каталоге (PGDATA/pg_wal). На журнал можно взглянуть не только из файловой системы, но и с помощью функцию pg_ls_waldir():

Посмотреть на выполняемые процессы сервера postgres можно так:

К процессам, обслуживающим буферный кэш и журнал, можно отнести:

checkpointer;
background writer;
walwriter;

Теперь давайте остановим сервер корректно и посмотрим в лог файл:

Как видим сервер просто открыл соединения на сокете и tcp порту 5432 и начал работу.

Теперь завершим работу сервера некорректно, используя опцию immediate:

Как видим журнал изменился! Перед тем, как начать принимать соединения, СУБД выполнила восстановление (automatic recovery in progress).

Предыдущий цикл был посвящен изоляции и многоверсионности PostgreSQL, а сегодня мы начинаем новый — о механизме журналирования (write-ahead logging). Напомню, что материал основан на учебных курсах по администрированию, которые делаем мы с Павлом pluzanov, но не повторяет их дословно и предназначен для вдумчивого чтения и самостоятельного экспериментирования.

Этот цикл будет состоять из четырех частей:

Буферный кеш (эта статья); — как устроен и как используется при восстановлении; и фоновая запись — зачем нужны и как настраиваются; — уровни и решаемые задачи, надежность и производительность.

, как ее понимают стандарт и PostgreSQL; — что творится на физическом уровне; ; ; ; (vacuum); (autovacuum); .

В процессе работы часть данных, с которыми имеет дело СУБД, хранится в оперативной памяти и записывается на диск (или на другой энергонезависимый носитель) отложенным образом. Чем реже это происходит, тем меньше ввод-вывод и тем быстрее работает система.

Но что произойдет в случае сбоя, например, при выключении электропитания или при ошибке в коде СУБД или операционной системы? Все содержимое оперативной памяти будет потеряно, а останутся лишь данные, записанные на диск (при некоторых видах сбоев может пострадать и диск, но в этом случае поможет лишь резервная копия). В принципе можно организовать ввод-вывод таким образом, чтобы данные на диске всегда поддерживались в согласованном состоянии, но это сложно и не слишком эффективно (насколько я знаю, только Firebird пошел таким путем).

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

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

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

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

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

Но вернемся к буферному кешу СУБД.

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

расположение на диске страницы, находящейся в буфере (файл и номер блока в нем);
признак того, что данные на странице изменились и рано или поздно должны быть записаны на диск (такой буфер называют грязным);
число обращений к буферу (usage count);
признак закрепления буфера (pin count).

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

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

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

Если нужная страница найдена в кеше, процесс должен «закрепить» буфер, увеличив счетчик pin count (несколько процессов могут сделать это одновременно). Пока буфер закреплен (значение счетчика больше нуля), считается, что буфер используется и его содержимое не должно «радикально» измениться. Например, в странице может появиться новая версия строки — это никому не мешает благодаря многоверсионности и правилам видимости. Но в закрепленный буфер не может быть прочитана другая страница.

Может получиться так, что необходимая страница не будет найдена в кеше. В этом случае ее необходимо считать с диска в какой-либо буфер.

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

Механизм вытеснения основан на том, что при каждом обращении к буферу процессы увеличивают счетчик числа обращений (usage count) в заголовке буфера. Таким образом те буферы, которые используются реже остальных, имеют меньшее значение счетчика и являются хорошими кандидатами на вытеснение.

Алгоритм clock-sweep перебирает по кругу все буферы (используя указатель на «следующую жертву»), уменьшая на единицу их счетчики обращений. Для вытеснения выбирается первый же буфер, который:

имеет нулевой счетчик обращений (usage count),
и не закреплен (нулевой pin count).

После того, как буфер найден, с ним происходит следующее.

Буфер закрепляется, чтобы показать остальным процессам, что он используется. Помимо закрепления используются и другие средства блокировки, но подробнее об этом мы поговорим отдельно.

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

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

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

Как это принято в PostgreSQL, существует расширение, которое позволяет заглянуть внутрь буферного кеша.

Создадим таблицу и вставим в нее одну строку.

Что окажется в буферном кеше? Как минимум, в нем должна появиться страница, на которую добавлена единственная строка. Проверим это следующим запросом, в котором мы выбираем только буферы, относящиеся к нашей таблице (по номеру файла relfilenode), и расшифровываем номер слоя (relforknumber):

Так и есть — в буфере одна страница. Она грязная (isdirty), счетчик обращений равен единице (usagecount), и она не закреплена ни одним процессом (pinning_backends).

Теперь добавим еще одну строку и повторим запрос. Для экономии букв мы вставляем строку в другом сеансе, а длинный запрос повторяем командой \g .

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

И после обращения к странице на чтение счетчик тоже увеличивается.

А если выполнить очистку?

Очистка создала карту видимости (одна страница) и карту свободного пространства (три страницы — минимальный размер этой карты).

Размер кеша устанавливается параметром shared_buffers. Значение по умолчанию — смехотворные 128 Мб. Это один из параметров, которые имеет смысл увеличить сразу же после установки PostgreSQL.

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

Из каких соображений выбирать подходящее значение?

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

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

Стандартная рекомендация — взять в качестве первого приближения 1/4 оперативной памяти (для Windows до версии PostgreSQL 10 рекомендовалось выбирать размер меньше).

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

Обязательно посмотрите доклад Николая Самохвалова на PgConf-2019: "Промышленный подход к тюнингу PostgreSQL: эксперименты над базами данных"

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

Например, можно изучить распределение буферов по степени их использования:

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

Можно посмотреть, какая доля каких таблиц в нашей базе закеширована и насколько активно используются эти данные (под активным использованием в этом запросе понимаются буферы со счетчиком использования больше 3):

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

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

надо повторять несколько раз: цифры будут меняться в определенных пределах;
не надо выполнять постоянно (как часть мониторинга) из-за того, что расширение кратковременно блокирует работу с буферным кешем.

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

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

Для последовательного чтения (sequential scan) больших таблиц (размер которых превышает четверть буферного кеша) выделяется 32 страницы. Если в процессе чтения таблицы другому процессу тоже потребуются эти данные, он не начинает читать таблицу сначала, а подключается к уже имеющемуся буферному кольцу. После окончания сканирования он дочитывает «пропущенное» начало таблицы.

Давайте проверим. Для этого создадим таблицу так, чтобы одна строка занимала целую страницу — так удобнее считать. Размер буферного кеша по умолчанию составляет 128 Мб = 16384 страницы по 8 Кб. Значит, в таблицу надо вставить больше 4096 страниц-строк.

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

После перезагрузки прочитаем всю таблицу:

И убедимся, что табличными страницами в буферном кеше занято только 32 буфера:

Если же запретить последовательное сканирование, то таблица будет прочитана по индексу:

В этом случае буферное кольцо не используется и в буферном кеше окажется вся таблица полностью (и почти весь индекс тоже):

Похожим образом буферные кольца используются для процесса очистки (тоже 32 страницы) и для массовых операций записи COPY IN и CREATE TABLE AS SELECT (обычно 2048 страниц, но не больше 1/8 всего буферного кеша).

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

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

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

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

Раньше расширение могло только читать определенные таблицы в буферный кеш (или только в кеш ОС). Но в версии PostgreSQL 11 оно получило возможность сохранять актуальное состояние кеша на диск и восстанавливать его же после перезагрузки сервера. Чтобы этим воспользоваться, надо добавить библиотеку в shared_preload_libraries и перезагрузить сервер.

Поле рестарта, если не менялось значение параметра pg_prewarm.autoprewarm, будет автоматически запущен фоновый процесс autoprewarm master, который раз в pg_prewarm.autoprewarm_interval будет сбрасывать на диск список страниц, находящихся в кеше (не забудьте учесть новый процесс при установке max_parallel_processes).

Сейчас в кеше нет таблицы big:

Если мы предполагаем, что все ее содержимое очень важно, мы можем прочитать ее в буферный кеш с помощью вызова следующей функции:

Список страниц сбрасывается в файл autoprewarm.blocks. Чтобы его увидеть, можно просто подождать, пока процесс autoprewarm master отработает в первый раз, но мы инициируем это вручную:

Число сброшенных страниц больше 4097 — сюда входят и уже прочитанные сервером страницы объектов системного каталога. А вот и файл:

Теперь снова перезапустим сервер.

И сразу после запуска наша таблица снова оказывается в кеше.

Это обеспечивает тот же самый процесс autoprewarm master: он читает файл, разделяет страницы по базам данных, сортирует их (чтобы чтение с диска было по возможности последовательным) и передает отдельному рабочему процессу autoprewarm worker для обработки.

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

Принцип работы жесткого диска

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

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

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

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

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

Что такое кэш

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

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

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

Догадались почему? Правильно, из-за ограниченного количества циклов перезаписи информации на HDD.

Как посмотреть размер буфера

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

Оптимальные размеры для различных задач

Возникает закономерный вопрос: какая буферная память лучше для домашнего компьютера и что дает это в практическом плане? Естественно, желательно побольше. Однако на юзера накладывают ограничение уже сами производители винчестеров: например, хард с 128 Мб буферной памяти обойдется по цене существенно выше средней.

Именно на такой объем кэша я рекомендую ориентироваться, если вы хотите собрать игровой комп, который не устареет уже через пару лет. Для задач попроще можно обойтись и попроще характеристиками: домашнему медиацентру с головой хватит и 64 Мб. А для компьютера, который используется сугубо для серфинга в интернете и запуска офисных приложений и простеньких флеш-игр, вполне достаточно и буферной памяти объемом 32 Мб.

В качестве «золотой середины» могу порекомендовать винчестер Toshiba P300 1TB 7200rpm 64MB HDWD110UZSVA 3.5 SATA III – здесь средний размер кэша, но емкости самого жесткого диска вполне достаточно для домашнего ПК. Также для полноты картины рекомендую ознакомиться с публикациями о лучших производителях жестких дисков и рейтинге HDD, а также, какие разъемы бывают на жестких дисках.

Читайте также: