Когда я должен использовать /dev/shm/ и когда я должен использовать /tmp/?

В порядке убывания tmpfs вероятность:

┌───────────┬──────────────┬────────────────┐
│ /dev/shm  │ always tmpfs │ Linux specific │
├───────────┼──────────────┼────────────────┤
│ /tmp      │ can be tmpfs │ FHS 1.0        │
├───────────┼──────────────┼────────────────┤
│ /var/tmp  │ never tmpfs  │ FHS 1.0        │
└───────────┴──────────────┴────────────────┘

Поскольку вы спрашиваете о специфичной для Linux точке монтирования tmpfs в сравнении с портируемым каталогом, которыйможет быть tmpfs (в зависимости от вашего системного администратора и того, что по умолчанию для вашего дистрибутива), ваш вопрос имеет два аспекта, которые другие ответы подчеркнули по-разному:

1. Когда использовать эти каталоги, основываясь напередовой практике
2. Когда уместно использовать tmpfs

Хорошая практика

Консервативное издание (смесь конвенций от FHS и общего пользования):

• Если есть сомнения, используйте/tmp,
• использование/var/tmpдля больших данных, которые не могут легко поместиться в оперативной памяти.
• использование/var/tmpдля данных, которые полезно хранить при перезагрузке (например, кеш).
• использование/dev/shmкак побочный эффект вызоваshm_open(), Предполагаемая аудитория - это ограниченные буферы, которые бесконечно перезаписываются. Так что это для долгоживущих файлов, содержание которых изменчиво и не очень велико.
• Если вы все еще сомневаетесь, предоставьте пользователю возможность переопределения. Например,mktempПрограмма чтитTMPDIRпеременная окружения.

Прагматичное издание:

использование /dev/shmкогда важно использовать tmpfs,/var/tmpкогда важно не/tmp,

Где TMPFS превосходит

fsyncне работает на tmpfs. Этот системный вызов является врагом номер один по производительности (IO) (и долговечности флэш-памяти, если вы заботитесь об этом), хотя, если вы обнаружите, что используете tmpfs (или eatmydata) просто для победы над fsync, то вы (или какой-то другой разработчик в цепочке)) делаем что-то не так. Это означает, что транзакции с устройством хранения данных неоправданно точны для ваших целей - вы явно готовы пропустить некоторые точки сохранения для повышения производительности, поскольку вы сейчас дошли до крайности, саботируя их все - редко лучший компромисс. Кроме того, именно здесь, в стране производительности транзакций, есть некоторые из самых больших преимуществ наличия SSD - любой приличный SSD собирается работать вне этого мира по сравнению с тем, что может взять вращающийся диск (7200 об / мин = 120 Гц)., если к нему обращаются больше всего), не говоря уже о картах флэш-памяти, которые сильно различаются по этому метрике (не в последнюю очередь потому, что это компромисс с последовательной производительностью, которой они оцениваются, например рейтинг класса SD-карт). Так что будьте осторожны, разработчики с невероятно быстрыми твердотельными накопителями, не заставляйте своих пользователей в этом случае использования!

Хотите услышать смешную историю? Мой первыйfsyncУрок: у меня была работа, которая заключалась в регулярном "обновлении" нескольких баз данных Sqlite (хранящихся в виде тестовых сценариев) до постоянно меняющегося текущего формата. Инфраструктура "upgrade" запускает несколько сценариев, каждый из которых выполняет по крайней мере одну транзакцию, для обновления одной базы данных. Конечно, я обновлял свои базы данных параллельно (8 параллельно, так как у меня был мощный 8-ядерный процессор). Но, как я выяснил, не было никакого ускорения распараллеливания (скорее, небольшой удар), потому что процесс был полностью связан с вводом-выводом. Весело, завернув инфраструктуру обновления в скрипт, который скопировал каждую базу данных в/dev/shm, обновил его там и скопировал обратно на диск примерно в 100 раз быстрее (все еще с 8 параллелями). В качестве бонуса ПК также можно былоиспользовать при обновлении баз данных.

Где уместно использовать tmpfs

Надлежащее использование tmpfs состоит в том, чтобы избежать ненужной записи изменчивых данных. Эффективное отключение обратной записи, например настройка/proc/sys/vm/dirty_writeback_centisecsдо бесконечности на обычной файловой системе.

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

С чем tmpfs не может помочь

• Читай производительность. Если ваши данные горячие (что лучше, если вы сохраните их в tmpfs), вы все равно попадете на кеш страниц. Разница в том, что когда вы не нажимаете на кеш страниц; если это так, перейдите к пункту "Где tmpfs sux" ниже.
• Краткосрочные файлы. Они могут прожить всю свою жизнь в кэше страниц (как грязные страницы), прежде чем их можно будет записать. Если вы не заставите этоfsyncконечно.

Где tmpfs sux

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

• Самая простая причина: нет ничего, что современные устройства хранения данных (будь то жесткие диски или флэш-диски) любят больше, чем чтение довольно последовательных файлов, аккуратно организованных соответствующей файловой системой. Обмен в блоках 4 КБ вряд ли улучшит это.
• Скрытая стоимость: обмен. Страницы Tmpfs грязные - их нужно где-то записать (подкачать), чтобы исключить из кэша страниц, в отличие от чистых страниц с файловой поддержкой, которые можно мгновенно удалить. Это дополнительное наказание на запись для всего остального, что конкурирует за память - влияет на что-то другое в другое время, чем использование этих страниц tmpfs.

Хорошо, вот реальность.

И tmpfs, и обычная файловая система являются кешем памяти на диске.

Tmpfs использует память и пространство подкачки, поскольку в качестве резервного хранилища файловая система использует определенную область диска, и ни один из них не ограничен в размере, который может иметь файловая система, вполне возможно иметь 200 ГБ tmpfs на машине с менее чем ГБ ОЗУ, если у вас достаточно пространства подкачки.

Разница в том, когда данные записываются на диск. Для tmpfs данные записываются ТОЛЬКО, когда память переполняется или данные вряд ли скоро будут использованы. OTOH большинство обычных файловых систем Linux спроектированы так, чтобы всегда иметь более или менее согласованный набор данных на диске, поэтому, если пользователь потянет за вилку, он не потеряет все.

Лично я привык иметь операционные системы, которые не выходят из строя, и системы ИБП (например, аккумуляторы для ноутбуков), поэтому я думаю, что файловые системы ext2/3 слишком параноидальны с интервалом контрольных точек 5-10 секунд. Файловая система ext4 лучше с 10-минутной контрольной точкой, за исключением того, что она обрабатывает пользовательские данные как второй класс и не защищает их. (ext3 то же самое, но вы не замечаете это из-за 5-секундной контрольной точки)

Эта частая проверка означает, что ненужные данные постоянно записываются на диск, даже для /tmp.

Таким образом, в результате вам нужно создать пространство подкачки, настолько большое, насколько это необходимо для вашего / tmp (даже если вам нужно создать файл подкачки), и использовать это пространство для монтирования tmpfs нужного размера в /tmp.

НИКОГДА не используйте /dev/shm.

Если только вы не используете его для очень маленьких (вероятно, mmap'd) файлов IPC, и вы уверены, что он существует (это не стандарт), и на машине более чем достаточно памяти + доступно подкачка.

Используйте /tmp/ для временных файлов. Используйте /dev/shm/, когда вам нужна общая память (т. Е. Межпроцессное взаимодействие через файлы).

Вы можете положиться на /tmp/, находясь там, но /dev/shm/ - это сравнительно недавно только Linux.

В другой раз вы должны использовать /dev/shm (для Linux 2.6 и выше), когда вам нужна гарантированная файловая система tmpfs, потому что вы не знаете, можете ли вы записать на диск.

Система мониторинга, с которой я знаком, должна записывать временные файлы при создании отчета для отправки на центральный сервер. На практике гораздо более вероятно, что что-то предотвратит запись в файловую систему (либо из-за недостатка места на диске, либо из-за сбоя RAID-массива система перешла в аппаратный режим только для чтения), но вы все равно сможете хромать, чтобы предупредить о чем, если что-то закручивает всю доступную память так, что tmpfs будет непригодным для использования (и коробка не будет мертвой). В подобных случаях система мониторинга будет предпочитать запись в ОЗУ, чтобы потенциально иметь возможность отправлять оповещения о заполненном диске или о неисправном / умирающем оборудовании.

/dev/shm используется для драйверов и программ для конкретных систем с общей виртуальной памятью.

Если вы создаете программу, которая требует кучи виртуальной памяти, которая должна быть сопоставлена ​​с виртуальной памятью. Это удваивается, поэтому, если вам нужно несколько процессов или потоков для безопасного доступа к этой памяти.

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

В PERL, имея минимум 8 ГБ на любой машине (все работают под управлением Linux Mint), я считаю, что я считаю хорошей привычкой выполнять сложные алгоритмы на основе DB_File (структура данных в файле) с миллионами операций чтения и записи с использованием / dev / указатель курса корабля

На других языках, не имея повсюду повсеместно, чтобы избежать запусков и остановок при передаче по сети (работая локально над файлом, расположенным на сервере в атмосфере клиент-сервер), используя пакетный файл какого-либо типа, я скопирую весь файл (300-900 МБ) сразу в / dev / shm, запустите программу с выводом в / dev / shm, запишите результаты обратно на сервер и удалите из / dev / shm

Естественно, если бы у меня было меньше оперативной памяти, я бы этим не занимался. Обычно файловая система в / dev / shm считывается как половина вашей доступной оперативной памяти. Тем не менее, обычное использование оперативной памяти является постоянным. Таким образом, вы действительно не можете сделать это на устройстве с 2 ГБ или меньше. Чтобы превратить перефразирование в гиперболу, в оперативной памяти часто есть вещи, о которых даже система плохо сообщает.