Ответы:
/dev/shmвременная файловая система хранения файлов, т.е. tmpfs , которая использует оперативную память для резервного хранилища. Он может функционировать как реализация общей памяти, которая облегчает IPC .
Последние версии ядра Linux 2.6 начали предлагать / dev / shm в качестве разделяемой памяти в виде виртуального диска, более конкретно, в качестве общедоступного каталога, который хранится в памяти с определенным ограничением в / etc / default / tmpfs. Поддержка / dev / shm совершенно необязательна в конфигурационном файле ядра. Он включен по умолчанию в дистрибутивы Fedora и Ubuntu, где он наиболее широко используется приложением Pulseaudio. (Акцент добавлен.)
/tmpэто расположение для временных файлов, как определено в стандарте иерархии файловой системы , за которым следуют почти все дистрибутивы Unix и Linux.
Поскольку оперативная память значительно быстрее дискового хранилища, вы можете использовать ее /dev/shmвместо /tmpповышения производительности , если ваш процесс требует интенсивного ввода-вывода и широко использует временные файлы.
Чтобы ответить на ваши вопросы: Нет, вы не всегда можете рассчитывать на /dev/shmприсутствие, конечно, не на машинах, ограниченных для памяти. Вы должны использовать, /tmpесли у вас нет очень веских причин для использования /dev/shm.
Помните, что /tmpможет быть частью /файловой системы вместо отдельного монтирования, и, следовательно, может расти по мере необходимости. Размер /dev/shmограничен избыточной оперативной памятью в системе, и, следовательно, у вас больше шансов исчерпать пространство в этой файловой системе.
/dev/shm. /dev/shmявляется ли память (tmpfs) резервной копией диска (swap). /var/tmpэто память (дисковый кеш), поддерживаемая диском (файловая система на диске). На практике производительность примерно одинакова (tmpfs имеет небольшое преимущество, но его недостаточно). /tmpможет быть tmpfs или нет, в зависимости от того, как его настроил администратор. Нет веских причин для использования /dev/shmв ваших сценариях.
/tmpэто нормальное расположение (с $TMPDIRпереопределением). Выбор между /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 (в зависимости от вашего системного администратора и того, что по умолчанию для вашего дистрибутива), ваш вопрос имеет два аспекта, которые другие ответы подчеркнули по-разному:
Консервативное издание (смесь конвенций от FHS и общего пользования):
/tmp./var/tmpдля больших данных, которые не могут легко поместиться в оперативной памяти./var/tmpдля данных, которые полезно хранить при перезагрузке (например, кеш)./dev/shmв качестве побочного эффекта вызова shm_open(). Предполагаемая аудитория - это ограниченные буферы, которые бесконечно перезаписываются. Так что это для долгоживущих файлов, содержание которых изменчиво и не очень велико.mktempпрограмма учитывает TMPDIRпеременную среды.Прагматичное издание:
Используйте, /dev/shmкогда важно использовать tmpfs, /var/tmpкогда это важно, иначе /tmp.
fsyncне работает на tmpfs. Этот системный вызов является врагом номер один по производительности (IO) (и долговечности флэш-памяти, если вы заботитесь об этом), хотя, если вы обнаружите, что используете tmpfs (или eatmydata)) просто чтобы победить fsync, вы (или другой разработчик в цепочке) делаете что-то не так. Это означает, что транзакции с устройством хранения данных неоправданно точны для ваших целей - вы явно готовы пропустить некоторые точки сохранения для повышения производительности, поскольку вы сейчас дошли до крайности, саботируя их все - редко лучший компромисс. Кроме того, именно здесь, в стране производительности транзакций, есть некоторые из самых больших преимуществ наличия SSD - любой приличный SSD собирается работать вне этого мира по сравнению с тем, что может взять вращающийся диск (7200 об / мин = 120 Гц). , если к нему обращаются больше всего), не говоря уже о картах флэш-памяти, которые сильно различаются по этому метрике (не в последнюю очередь потому, что это компромисс с последовательной производительностью, которой они оцениваются, например рейтинг класса SD-карт). Так что будьте осторожны,
Хотите услышать смешную историю? Мой первый fsyncурок: у меня была работа, которая заключалась в регулярном «обновлении» нескольких баз данных Sqlite (хранящихся в виде тестовых сценариев) до постоянно меняющегося текущего формата. Инфраструктура «upgrade» запускает несколько сценариев, каждый из которых выполняет по крайней мере одну транзакцию, для обновления одной базы данных. Конечно, я обновлял свои базы данных параллельно (8 параллельно, так как у меня был мощный 8-ядерный процессор). Но, как я выяснил, не было никакого ускорения распараллеливания (скорее, небольшой удар ), потому что процесс был полностью связан с вводом-выводом. Весело, обертывание инфраструктуры обновления в сценарий, который копировал каждую базу данных /dev/shm, обновлял ее там и копировал обратно на диск, было примерно в 100 раз быстрее (по-прежнему с 8 параллельно). В качестве бонуса ПК можно было использовать тоже при обновлении баз.
Надлежащее использование tmpfs состоит в том, чтобы избежать ненужной записи изменчивых данных. Эффективное отключение обратной записи , например установка /proc/sys/vm/dirty_writeback_centisecsбесконечности в обычной файловой системе.
Это очень мало связано с производительностью, и ее сбой - гораздо меньшая проблема, чем злоупотребление fsync: тайм-аут обратной записи определяет, насколько лениво обновляется содержимое диска после содержимого кэша страниц, а по умолчанию 5 секунд - длительное время для компьютера. - приложение может перезаписывать файл так часто, как ему хочется, в pagecache, но содержимое на диске обновляется только один раз каждые 5 секунд. Если приложение не форсирует это с помощью fsync, то есть. Подумайте, сколько раз приложение может вывести небольшой файл за это время, и вы поймете, почему поиск каждого из них будет гораздо большей проблемой.
fsyncконечно.Хранение холодных данных. Может возникнуть соблазн думать, что обслуживание файлов из подкачки так же эффективно, как и для нормальной файловой системы, но есть несколько причин, почему это не так:
mount -t tmpfs "jarno is great" /mnt/jarnoесли хотите! В-третьих, размер по умолчанию составляет половину объема ОЗУ - держу пари, у вас 4 ГБ ОЗУ.
Хорошо, вот реальность.
И tmpfs, и обычная файловая система являются кешем памяти на диске.
Tmpfs использует память и пространство подкачки, поскольку в качестве резервного хранилища файловая система использует определенную область диска, и ни один из них не ограничен в размере, который может иметь файловая система, вполне возможно иметь 200GB 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.
1>/dev/null 2>&1. Я бы сделал это несколько тысяч раз, чтобы tmpfs был бы хорош. Однако если бы я выпустить скрипт, на который я не могу полагаться, что tmpfs используется, так /tmpкак я думаю, что это не так часто. Если это более распространено, /dev/shmто это лучше для меня. Но я ищу рекомендации относительно переносимости и т. д.
В другой раз вы должны использовать / 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 ГБ или меньше. Чтобы превратить перефразирование в гиперболу, в оперативной памяти часто есть вещи, о которых даже система плохо сообщает.
/dev/shmсуществует, использовать его, если он есть, или отступить/tmp. Это звучит хорошо?