Tmpfs для временных файлов: чек-лист перед продакшеном
Tmpfs ускоряет работу с временными файлами, но хранит их в памяти и может превратить всплеск нагрузки в нехватку RAM или OOM. Перед запуском проверьте размер, права, лимиты контейнера, поведение при перезагрузке и то, что именно приложение пишет в этот каталог.
Tmpfs может ускорить работу с временными файлами, но его лимит — не отдельный запас памяти: данные занимают RAM, а при нехватке система может использовать swap. Если приложение внезапно записывает больше обычного, последствиями могут стать ошибки записи, вытеснение других процессов или OOM. Ниже — чек-лист для Linux и критерии, по которым tmpfs можно допускать в продакшен.
Сначала определите, что именно вы кладёте в tmpfs
Tmpfs подходит для данных, которые можно заново создать и потерять при перезагрузке: временных выгрузок, промежуточных результатов, кэша или файлов для обмена между процессами. Это не постоянное хранилище: содержимое исчезает после размонтирования и обычно после перезагрузки.
Сначала проверьте поведение приложения, а не только размер каталога в спокойный день. Выясните максимальный объём временных данных при пакетной операции, параллельных запросах и повторной обработке после сбоя. Важна и длительность жизни файлов: несколько небольших файлов, которые быстро удаляются, и крупные архивы, оставшиеся на часы, создают разный профиль нагрузки.
Ставьте лимит по худшему ожидаемому сценарию, а не по среднему размеру каталога. И оставляйте системе запас памяти для процессов, которым нельзя отказать в RAM.
Tmpfs1 — файловая система в памяти. В Linux она может использовать как оперативную память, так и swap; установленный размер ограничивает объём файловой системы, но не резервирует этот объём заранее.
Чек-лист перед запуском
- Подтвердите, что данные действительно временные. Перезапустите тестовый сервис и проверьте, может ли он восстановить нужные файлы или создать их заново. Если потеря файла нарушает целостность операции, tmpfs для него не подходит.
- Посчитайте пиковый объём. Включите в расчёт одновременные задания, частично записанные файлы и задержку удаления старых. Проверьте расчёт на нагрузочном тесте и при штатном восстановлении после ошибки. Результат должен укладываться в выбранный лимит с запасом для остальных потребителей памяти.
- Задайте верхнюю границу. Не полагайтесь на значение по умолчанию: в Linux размер tmpfs обычно ограничен половиной физической памяти, если размер явно не задан. Этот лимит не означает, что память уже занята, но без собственной границы приложение может получить слишком большую файловую систему относительно допустимого бюджета хоста.
- Проверьте оба уровня ограничений. На хосте смотрите доступную память и swap; в контейнере — лимит памяти и поведение при его достижении. Tmpfs не создаёт дополнительную память поверх лимита контейнера. Убедитесь, что запись не приводит к OOM или отказу соседних процессов.
- Настройте владельца и режим доступа. Каталог должен быть доступен только нужному пользователю и группе. Проверьте права уже от имени процесса приложения, а не из интерактивной оболочки администратора.
- Проверьте заполнение и нехватку inode. Свободные байты не гарантируют, что файловую систему нельзя исчерпать большим количеством мелких файлов. На тесте воспроизведите оба сценария и убедитесь, что приложение корректно обрабатывает отказ записи.
- Проверьте жизненный цикл монтирования. После перезагрузки, перезапуска контейнера и выкладки убедитесь, что каталог смонтирован до старта приложения. Сам каталог должен существовать и иметь ожидаемые права, а приложение — не записывать файлы в обычную файловую систему, если монтирование не поднялось.
- Добавьте наблюдаемость. Отслеживайте занятое место и количество inode в точке монтирования, доступную память, swap и события OOM. Порог оповещения задайте ниже лимита так, чтобы успеть отреагировать до отказа записи.
Сравните tmpfs с другими вариантами
Выбор зависит не от того, что «быстрее вообще», а от цены отказа и характера доступа. Для временных данных, которые нельзя потерять даже после перезапуска, tmpfs не подходит без отдельного механизма сохранения.
| Вариант | Что получаете | Чем платите | Подходит, если |
|---|---|---|---|
| Tmpfs | Файловый интерфейс и данные в памяти, с возможным использованием swap | Расход памяти; содержимое пропадает при размонтировании | Файлы временные, а объём ограничен и наблюдаем |
| Обычная файловая система | Данные переживают перезагрузку при корректной записи | Место на диске и дисковые операции | Файлы нужны после рестарта или важнее предсказуемая RAM |
| Кэш приложения | Политика хранения может учитывать смысл данных | Нужно настроить и проверить поведение конкретного кэша | Приложению не обязательно нужен файловый интерфейс |
Проверьте настройки и поведение при отказе
Для разового теста можно создать отдельную точку монтирования и задать лимит явно. Команда ниже использует каталог /mnt/app-tmp и ограничение 512 мегабайт; перед запуском проверьте, что каталог предназначен для этого теста и что у вас есть права администратора.
sudo mkdir -p /mnt/app-tmp
sudo mount -t tmpfs -o size=512M,mode=0700 tmpfs /mnt/app-tmp
df -h /mnt/app-tmp
df -i /mnt/app-tmp
Это временное монтирование для проверки, а не готовая конфигурация для постоянного сервиса. После команды df должна показать tmpfs и заданную ёмкость; df -i поможет проверить доступные inode. Если приложение запускается не от вашего пользователя, отдельно проверьте права и владельца так, как их увидит сервис.
До выкладки воспроизведите отказ записи: заполните тестовую точку до лимита и проверьте, что приложение сообщает об ошибке, закрывает незавершённую операцию и не оставляет повреждённый результат. Не проверяйте это на каталоге с реальными данными.
Где подход ломается
- Объём растёт незаметно. Старые файлы не удаляются или параллельных задач становится больше. Задайте срок жизни файлов, контроль занятого объёма и оповещение до достижения лимита.
- Лимит tmpfs принимают за отдельную квоту RAM. Он ограничивает файловую систему, а не резервирует память. Сопоставьте его с бюджетом памяти процесса, хоста или контейнера.
- Сервис стартует раньше монтирования. Файлы попадают на обычный диск в каталог с тем же путём. Проверьте порядок старта и наличие ожидаемого монтирования перед запуском приложения.
- Данные оказались не такими уж временными. После рестарта пропадает файл, который нужен для продолжения операции. Перенесите его на постоянное хранилище или сделайте потерю безопасной.
- Не хватает места для множества мелких файлов. Свободное пространство ещё есть, но исчерпаны inode. Измеряйте оба показателя и воспроизводите в тесте реальный профиль файлов.
Что делать дальше
Перед релизом зафиксируйте лимит tmpfs, ожидаемый пик, допустимый сценарий потери данных и владельца каталога. Затем проверьте три вещи на тестовой среде: заполнение до лимита, перезапуск сервиса и перезагрузку хоста или контейнера. В продакшене следите за занятостью tmpfs, доступной памятью, swap и событиями OOM. Если вы не можете объяснить, как сервис восстановится после потери этих файлов, сначала решите этот вопрос, а потом переносите каталог в tmpfs.
1 «Виртуальная файловая система» здесь означает файловую систему, содержимое которой хранится в памяти, а не на обычном диске; при необходимости Linux может использовать swap.
Логотип и фирменный стиль: Три концепции разного характера, палитра с обоснованием, проверка на читаемость в малом размере и в один цвет.
Спросить за 60 ₽Источники: Linux kernel documentation: tmpfs, mount(8) — Linux manual page
Частые вопросы
Tmpfs всегда занимает половину оперативной памяти?
Что произойдёт, если tmpfs заполнится?
Файлы в tmpfs переживут перезагрузку?
Можно ли использовать tmpfs в контейнере?
Tmpfs гарантирует, что данные не попадут в swap?
Нужно ли отдельно следить за количеством файлов?
Материал носит информационный характер и подготовлен редакцией «Агентуры». Он не является офертой, рекламой или индивидуальной консультацией. Упомянутые продукты, компании и торговые знаки принадлежат их правообладателям. Перед принятием решений, влекущих юридические или финансовые последствия, обратитесь к профильному специалисту.