atime без сюрпризов: noatime/relatime для веб‑нагрузки

Если ваш веб‑сервер интенсивно читает статический контент, PHP‑шаблоны, ассеты и файлы кэша, то обновления времени последнего доступа (atime) способны генерировать лишние записи на диск. На современных Linux по умолчанию действует relatime, снижающий накладные расходы, но иногда уместно перейти на noatime или дополнить конфигурацию lazytime. Разберёмся, что реально даёт каждая опция, как проверить текущие настройки mount, как безопасно изменить /etc/fstab и на что смотреть в профиле веб‑нагрузки.

Что такое atime и почему он исторически включён

atime — метка времени последнего доступа к файлу (чтения, выполнения, mmap для чтения и т.п.). В Unix‑мире она использовалась для задач вроде очистки старых файлов, оценки «давности» использования, некоторых резервных копий и утилит; но в веб‑стеке подавляющее большинство инструментов ориентируются на mtime или ctime, а не на atime. Например, ротация логов, компиляция ассетов, валидаторы кэшей, сборщики мусора сессий — почти всегда смотрят на время модификации.

Проблема: каждый доступ к файлу потенциально требует обновить метаданные на носителе. Это увеличивает количество синхронизаций журналов и случайных записей, особенно на HDD и под высокой конкуррентной нагрузкой.

Опции обновления atime: strictatime, relatime, noatime, lazytime

В Linux поведение atime определяется набором опций файловой системы при mount:

• strictatime: обновлять atime при каждом доступе (классическая POSIX‑семантика). Самая дорогая по I/O опция, редко нужна.
• relatime: обновлять atime реже — когда он старее mtime/ctime или прошли сутки с последнего обновления. Это дефолт на большинстве дистрибутивов и компромисс между совместимостью и производительностью.
• noatime: вообще не обновлять atime при чтении. Максимальная экономия записей; подходит, если приложения не зависят от atime. Включает эффект nodiratime, отдельный флаг обычно не требуется.
• lazytime: откладывает запись временных меток на диск и держит их в памяти, сбрасывая при удобном случае (например, при fsync, размонтировании или по таймеру). Комбинируется с другими: relatime,lazytime — частая практика.

В реальном веб‑профиле relatime уже решает 90% проблем избыточных записей. noatime бывает полезен на разделах с интенсивным чтением, где совместимость с ПО, полагающимся на atime, не важна (например, каталоги статического контента, кэши, медиабиблиотеки, снапшоты сборок).

Как проверить текущие mount-опции

Есть несколько корректных способов посмотреть, с какими опциями примонтирована файловая система. Рекомендуемые:

findmnt -no TARGET,OPTIONS /
findmnt -no TARGET,OPTIONS /var/www
cat /proc/mounts | grep ' / '

На современных системах вы увидите среди прочего relatime. Для ext4 это практически стандарт, для XFS — тоже. Если relatime не указан явным текстом, он может быть дефолтом ядра, но findmnt обычно отражает эффективные опции.

Микротест: действительно ли atime обновляется

Можно быстро проверить поведение atime на произвольном файле:

cd /var/www/html
stat index.php
cat index.php > /dev/null
stat index.php

Сравните поля Access в выводе stat. При strictatime время изменится каждый раз. При relatime — изменится не всегда (например, если прошло менее суток и не менялись mtime/ctime). При noatime — не изменится вовсе.

Что выбрать для веб‑нагрузки

Статический контент, ассеты CDN, медиатеки

Для разделов, где преобладает чтение и почти нет записей со стороны приложения, noatime приносит максимум выгоды: меньше журналирования метаданных, меньше конкуренции за очередь I/O, предсказуемее latency для web‑воркеров. Это особенно заметно на HDD и под высокой RPS со множеством мелких файлов (иконки, шрифты, минифицированные JS/CSS).

Код приложений, шаблоны, кэши PHP/Node.js

Как правило, relatime плюс опционально lazytime — безопасный и производительный выбор. Большинство инструментов разработки и рантаймов не опираются на atime. Компиляторы и сборщики проверяют mtime. Кэш PHP‑опкода хранит свои собственные метаданные. lazytime поможет сгладить пики записи метаданных.

Журналы и временные директории

Журналы и ротация логов традиционно завязаны на mtime, поэтому noatime или relatime — нормальная практика. Для временных директорий (/tmp, /var/tmp) лучше посмотреть, не используется ли у вас средство очистки на базе atime (исторически так делал tmpwatch). Если очистка по mtime — смело используйте noatime.

Базы данных и почтовые хранилища

Для СУБД и почтовых серверов у каждого продукта есть свои рекомендации. В веб‑контексте чаще база вынесена на отдельный том с собственными настройками. Если сомневаетесь — оставьте relatime по умолчанию. noatime тут обычно не даёт выигрыша, так как профиль I/O доминирует данными и журналами самой СУБД.

Учтите, что менять mount‑опции сможет только root. На большинстве площадок общего хостинга опции задаются провайдером; полный контроль над файловой системой удобнее получать на VDS. Если администрирование не входит в ваши планы, под веб‑проекты подойдёт управляемый виртуальный хостинг.

Как безопасно изменить /etc/fstab

Перед сменой опций подготовьте план отката и окно изменения.

1. Зафиксируйте текущие эффективные опции.
2. Убедитесь, что критичные сервисы не зависят от atime.
3. Обновите /etc/fstab для нужных точек монтирования.
4. Проверочно выполните mount -o remount без перезагрузки.
5. Проверьте логи, поведение приложений и метрики I/O.

Пример фрагмента /etc/fstab для разделов с веб‑нагрузкой на ext4:

/dev/vda1  /          ext4  defaults,relatime,lazytime,errors=remount-ro  0 1
/dev/vda2  /var/www   ext4  defaults,noatime,nodiratime                   0 2
/dev/vda3  /var/log   ext4  defaults,relatime                             0 2

Обратите внимание: отдельный nodiratime не обязателен, если уже указали noatime; он приведён как иллюстрация. Для XFS синтаксис похожий (в XFS нет nodiratime, но есть noatime/relatime):

/dev/vdb1  /var/www   xfs   defaults,noatime  0 0

Применить без перезагрузки можно так:

mount -o remount,noatime /var/www
mount -o remount,relatime,lazytime /

Проверяем результат:

findmnt -no TARGET,OPTIONS / /var/www

Как вернуться назад

Если обнаружили зависимость от atime, можно оперативно вернуть поведение и перезагрузить позже.

mount -o remount,relatime /var/www
# при необходимости: strictatime — но учитывайте рост нагрузки на I/O
mount -o remount,strictatime /var/www

После временного отката поправьте /etc/fstab и назначьте окно для перезагрузки, если требуется.

Как понять, что выигрыш есть

Ищите снижение фоновых записей и выравнивание latency. Базовый минимум:

• iostat -x 1 10 — наблюдайте await/svctm и долю w/s при read‑heavy запросах.
• pidstat -d 1 — у веб‑воркеров меньше мелких writes на разделы кода и статики.
• vmstat 1 — снижение context switch и page flush пульсаций опосредованно может быть заметно.

В реальных кейсах для разделов со статикой переход на noatime даёт более стабильные хвосты задержек на пиках (p95/p99) за счёт уменьшения конкуренции метаданных с рабочими потоками.

Частые вопросы и подводные камни

Зачем вообще оставлять atime?

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

Нужно ли указывать nodiratime?

Нет, если вы используете noatime — он уже покрывает каталоги. Отдельный nodiratime актуален только при желании тонко выключить обновление atime для каталогов, оставив его для файлов (редкий случай).

Что насчёт lazytime?

lazytime хорошо сочетается с relatime и часто даёт дополнительную выгоду без потери совместимости. Помните, что метки времени будут записаны на диск позже; для инструментов, требующих незамедлительной фиксации времени доступа, используйте явные fsync/sync либо не включайте lazytime на таких путях.

Контейнеры и overlay

Если сервис работает в контейнере, ключевые mount‑опции задаются на хосте для точек, которые вы монтируете в контейнер как bind‑mount. Проверьте эффективные опции на хостовой ФС, а затем внутри контейнера убедитесь, что они действительно видны на соответствующих путях.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Разные файловые системы

ext4 и XFS поддерживают описанные опции напрямую. У других ФС поведение может отличаться по деталям. Дополнительно посмотрите материал про тюнинг ext4/XFS на VDS: системный тюнинг ext4/XFS на VDS.

Практические профили для веб‑серверов

Пример разумного набора вариантов для типичного LEMP‑хоста:

• / (система): relatime,lazytime — компромисс для повседневных задач, без неожиданных эффектов.
• /var/www (код и статика): noatime — максимум производительности на чтении.
• /var/cache (кэши приложений): noatime либо relatime,lazytime — зависит от паттерна записи; если кэш активно перезаписывается, разницы немного.
• /var/log (логи): relatime — предсказуемо и безопасно.

Не забывайте о бэкапах и их взаимодействии с метками времени. Большинство современных инструментов инкрементальных копий используют собственные базы и хэши содержимого. Если вы параллельно настраиваете TRIM/Discard на SSD, пригодится разбор темы TRIM и опции discard.

Чек‑лист внедрения

• Зафиксируйте текущие опции и версию ядра.
• Составьте список путей, где допустим noatime.
• Проверьте, не зависят ли служебные задачи от atime (очистка временных файлов, редкие скрипты мониторинга).
• Измените /etc/fstab, примените mount -o remount.
• Наблюдайте метрики I/O и хвосты задержек под реальной нагрузкой.
• Документируйте решение и добавьте проверку опций в базовую диагностику узла.

Итоги

Для веб‑нагрузки ключевая цель — уменьшить лишние записи метаданных, не потеряв совместимость. relatime уже даёт большую часть выигрыша и безопасен по умолчанию. Там, где приложения точно не используют atime, смело включайте noatime. При необходимости дополните lazytime, чтобы ещё сгладить запись временных меток. Подтвердите эффект замерами и держите под рукой простой откат через mount -o remount и правку /etc/fstab. Так вы получите предсказуемый рост performance без неприятных сюрпризов.