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

<p>когда я должен использовать <code>/dev/shm/</code> и когда я должен использовать <code>/tmp/</code>? могу ли я всегда полагаться на то, что они оба в unices?</p>

<p><code>/dev/shm</code> - это временная файловая система хранения файлов, т.е. <a href="http://en.wikipedia.org/wiki/tmpfs">tmpfs</a> , которая использует ram для резервного хранилища. он может функционировать как реализация разделяемой памяти, которая облегчает <a href="http://en.wikipedia.org/wiki/inter-process\_communication">ipc</a> .</p><p><strong> <a href="http://en.wikipedia.org/wiki/shared\_memory">из википедии</a> : </strong></p><blockquote> <p>последние версии ядра linux 2.6 начали предлагать/dev/shm в качестве разделяемой памяти в виде виртуального диска, более конкретно, в качестве общедоступного каталога, который хранится в памяти с определенным ограничением в/etc/default/tmpfs.<strong>/dev/shm поддержка совершенно необязательна в конфигурационном файле ядра. </strong>он включен по умолчанию в дистрибутивы fedora и ubuntu, где он наиболее широко используется приложением pulseaudio.<sup>(акцент добавлен.)</sup></p> </blockquote><p> <a href="http://en.wikipedia.org/wiki//tmp"><code>/tmp</code></a> - это место для временных файлов, как определено в <a href="http://en.wikipedia.org/wiki/filesystem\_hierarchy\_standard">стандарте иерархии файловой системы</a> , за которым следуют почти все дистрибутивы unix и linux.</p><p>поскольку ram значительно быстрее дискового хранилища, вы можете <a href="http://www.cyberciti.biz/tips/what-is-devshm-and-its-practical-usage.html">использовать <code>/dev/shm</code> вместо <code>/tmp</code> для повышения производительности</a> , если ваш процесс требует интенсивного ввода-вывода и широко использует временные файлы.</p><p>чтобы ответить на ваши вопросы: нет, вы не всегда можете рассчитывать на присутствие <code>/dev/shm</code>, конечно, не на машинах, ограниченных в памяти. вы должны использовать <code>/tmp</code>, если у вас нет веских причин для использования <code>/dev/shm</code>.</p><p>помните, что <code>/tmp</code> может быть частью файловой системы <code>/</code> вместо отдельного монтирования и, следовательно, может расти по мере необходимости. размер <code>/dev/shm</code> ограничен избытком ram в системе, и, следовательно, у вас больше шансов исчерпать место в этой файловой системе.</p>

<p>в порядке убывания вероятности <code>tmpfs</code>:</p><pre><code>┌───────────┬──────────────┬────────────────┐ │ /dev/shm │ always tmpfs │ linux specific │ ├───────────┼──────────────┼────────────────┤ │ /tmp │ can be tmpfs │ fhs 1.0 │ ├───────────┼──────────────┼────────────────┤ │ /var/tmp │ never tmpfs │ fhs 1.0 │ └───────────┴──────────────┴────────────────┘ </code></pre><p>так как вы спрашиваете о специфичной для linux<em> tmpfs </em>точка монтирования в сравнении с портируемым каталогом, который<em> может </em>быть tmpfs (в зависимости от вашего системного администратора и того, что по умолчанию для вашего дистрибутива), ваш вопрос имеет два аспекта: какие другие ответы подчеркнули по-другому:</p><ol> <li>когда использовать эти каталоги, основываясь на<em> хорошая практика </em></li> <li>когда уместно использовать tmpfs</li> </ol><hr><h2>хорошая практика</h2><p>консервативное издание (смесь условных обозначений из <a href="https://en.wikipedia.org/wiki/filesystem\_hierarchy\_standard">fhs</a> и общего пользования):</p><ul> <li>в случае сомнений используйте <code>/tmp</code>.</li> <li>используйте <code>/var/tmp</code> для больших данных, которые не всегда легко помещаются в оперативную память.</li> <li>используйте <code>/var/tmp</code> для данных, которые полезно хранить при перезагрузке (например, кеш).</li> <li>используйте <code>/dev/shm</code> как побочный эффект вызова <code>shm\_open()</code>. предполагаемая аудитория - это ограниченные буферы, которые бесконечно перезаписываются. так что это для долгоживущих файлов, содержание которых изменчиво и не очень велико.</li> <li>если вы все еще сомневаетесь, предоставьте пользователю возможность переопределения. например, программа <code>mktemp</code> учитывает переменную среды <code>tmpdir</code>.</li> </ul><p>прагматичное издание:</p><p>используйте <code>/dev/shm</code>, когда важно использовать tmpfs, <code>/var/tmp</code>, когда это важно, иначе <code>/tmp</code>.</p><h2>где tmpfs превосходит</h2><p><code>fsync</code> не работает на tmpfs. этот системный вызов является врагом номер один по производительности (io) (и долговечности флэш-памяти, если вы заботитесь об этом), хотя, если вы обнаружите, что используете tmpfs (или <a href="https://www.flamingspork.com/projects/libeatmydata/">eatmydata</a> ) просто для победы над fsync, тогда вы (или некоторые другие) разработчик в цепочке) делаю что то не так. это означает, что транзакции с устройством хранения данных неоправданно точны для ваших целей - вы явно готовы пропустить некоторые точки сохранения для повышения производительности, поскольку вы сейчас дошли до крайности, саботируя их все - редко лучший компромисс. кроме того, именно здесь, в стране производительности транзакций, есть некоторые из самых больших преимуществ наличия ssd - любой приличный ssd собирается работать вне этого мира по сравнению с тем, что может взять вращающийся диск (7200 об/мин = 120 гц). , если к нему обращаются больше всего), не говоря уже о картах флэш-памяти, которые сильно различаются по этому метрике (не в последнюю очередь потому, что это компромисс с последовательной производительностью, которой они оцениваются, например рейтинг класса sd-карт). так что будьте осторожны, разработчики с невероятно быстрыми твердотельными накопителями, не заставляйте своих пользователей в этом случае использования!</p><p>хотите услышать смешную историю? мой первый <code>fsync</code> урок: у меня была работа, которая заключалась в регулярном «обновлении» набора баз данных sqlite (хранящихся в виде тестовых сценариев) до постоянно меняющегося текущего формата. инфраструктура «upgrade» запускает несколько сценариев, каждый из которых выполняет по крайней мере одну транзакцию, для обновления одной базы данных. конечно, я обновлял свои базы данных параллельно (8 параллельно, так как у меня был мощный 8-ядерный процессор). но, как я выяснил, не было никакого ускорения распараллеливания (скорее небольшое<em> попадание </em>), потому что процесс был полностью io \_ привязан. весело, обертывание инфраструктуры обновления в сценарий, который копировал каждую базу данных в <code>/dev/shm</code>, обновлял ее там и копировал обратно на диск, было примерно в 100 раз быстрее (по-прежнему с 8 параллельно). в качестве бонуса пк был<em> годен к употреблению </em>тоже при обновлении баз данных.</p><h2>где уместно использовать tmpfs</h2><p>надлежащее использование tmpfs состоит в том, чтобы избежать ненужной записи изменчивых данных. эффективное отключение<em> writeback </em>, например, установка <code>/proc/sys/vm/dirty\_writeback\_centisecs</code> в бесконечность на обычной файловой системе.</p><p>это очень мало связано с производительностью, и ее сбой - гораздо меньшая проблема, чем злоупотребление fsync: тайм-аут обратной записи определяет, насколько лениво обновляется содержимое диска после содержимого кэша страниц, а по умолчанию 5 секунд - длительное время для компьютера. - приложение может перезаписывать файл так часто, как ему хочется, в pagecache, но содержимое на диске обновляется только один раз каждые 5 секунд. если приложение не форсирует это с помощью fsync, то есть. подумайте, сколько раз приложение может вывести небольшой файл за это время, и вы поймете, почему поиск каждого из них будет гораздо большей проблемой.</p><h2>с чем tmpfs не может помочь</h2><ul> <li>читай производительность. если ваши данные горячие (что лучше, если вы сохраните их в tmpfs), вы все равно попадете на кеш страниц. разница в том, что когда вы не нажимаете на кеш страниц; если это так, перейдите к пункту «где tmpfs sux» ниже.</li> <li>краткосрочные файлы. они могут прожить всю свою жизнь в кэше страниц (как<em> dirty </em>pages) еще до того, как их выписать. если, конечно, вы не вызовете это с помощью <code>fsync</code>.</li> </ul><h2>где tmpfs sux</h2><p>хранение<em> холодно </em>данные. может возникнуть соблазн думать, что обслуживание файлов из подкачки так же эффективно, как и для нормальной файловой системы, но есть несколько причин, почему это не так:</p><ul> <li>самая простая причина: нет ничего, что современные устройства хранения данных (будь то жесткие диски или флэш-диски) любят больше, чем чтение довольно последовательных файлов, аккуратно организованных соответствующей файловой системой. обмен в блоках 4 кб вряд ли улучшит это.</li> <li>скрытая стоимость: обмен<em> выход </em>. страницы tmpfs являются<em> грязными </em>- они должны быть где-то записаны (подкачаны) для удаления из кэша страниц, в отличие от файла с резервной копией<em> clean </em>pages, которые можно мгновенно удалить. это дополнительное наказание на запись для всего остального, что конкурирует за память - влияет на что-то другое в другое время, чем использование этих страниц tmpfs.</li> </ul>

<p>хорошо, вот реальность.</p><p>и tmpfs, и обычная файловая система являются кешем памяти на диске.</p><p>tmpfs использует память и пространство подкачки, поскольку в качестве резервного хранилища файловая система использует определенную область диска, и ни один из них не ограничен в размере, который может иметь файловая система, вполне возможно иметь 200 гб tmpfs на машине с менее чем гб озу, если у вас достаточно пространства подкачки.</p><p>разница в том, когда данные записываются на диск. для tmpfs данные записываются только, когда память переполняется или данные вряд ли скоро будут использованы. otoh большинство обычных файловых систем linux спроектированы так, чтобы всегда иметь более или менее согласованный набор данных на диске, поэтому, если пользователь потянет за вилку, он не потеряет все.</p><p>лично я привык иметь операционные системы, которые не выходят из строя, и системы ибп (например, аккумуляторы для ноутбуков), поэтому я думаю, что файловые системы ext2/3 слишком параноидальны с интервалом контрольных точек 5-10 секунд. файловая система ext4 лучше с 10-минутной контрольной точкой, за исключением того, что она обрабатывает пользовательские данные как второй класс и не защищает их. (ext3 то же самое, но вы не замечаете это из-за 5-секундной контрольной точки)</p><p>эта частая проверка означает, что ненужные данные постоянно записываются на диск, даже для/tmp.</p><p>таким образом, в результате вам нужно создать пространство подкачки, настолько большое, насколько это необходимо для вашего/tmp (даже если вам нужно создать файл подкачки), и использовать это пространство для монтирования tmpfs нужного размера в/tmp.</p><p>никогда не используйте/dev/shm.</p><p>если вы не используете его для очень маленьких (вероятно, mmap'd) ipc файлов, и вы уверены, что он существует (это не стандарт), и на машине более чем достаточно памяти + доступно подкачка.</p>

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

<p>в другой раз вы должны использовать/dev/shm (для linux 2.6 и выше), когда вам нужна гарантированная файловая система tmpfs, потому что вы не знаете, можете ли вы<em> можете </em>записать на диск.</p><p>система мониторинга, с которой я знаком, должна записывать временные файлы при создании отчета для отправки на центральный сервер. на практике гораздо более вероятно, что что-то предотвратит запись в файловую систему (либо из-за недостатка места на диске, либо из-за сбоя raid-массива система перешла в аппаратный режим только для чтения), но вы все равно сможете хромать, чтобы предупредить о чем, если что-то закручивает всю доступную память так, что tmpfs будет непригодным для использования (и коробка не будет мертвой). в подобных случаях система мониторинга предпочитает записывать в ram, чтобы потенциально иметь возможность отправлять оповещения о заполненном диске или о мертвом/умирающем оборудовании.</p>

<p>в perl, имеющем минимум 8 гб на любой машине (все работают под управлением linux mint), я считаю, что я считаю хорошей привычкой делать сложные алгоритмы на основе db\_file (структура данных в файле) с миллионами операций чтения и записи с использованием/dev/указатель курса корабля</p><p>на других языках, не имея повсюду повсеместно, чтобы избежать запусков и остановок при передаче по сети (работая локально над файлом, расположенным на сервере в атмосфере клиент-сервер), используя пакетный файл какого-либо типа, я скопирую весь файл (300-900 мб) сразу в/dev/shm, запустите программу с выводом в/dev/shm, запишите результаты обратно на сервер и удалите из/dev/shm</p><p>естественно, если бы у меня было меньше оперативной памяти, я бы этим не занимался. обычно файловая система в/dev/shm считывается как половина вашей доступной оперативной памяти. однако обычное использование ram является постоянным. таким образом, вы действительно не можете сделать это на устройстве с 2 гб или меньше. чтобы превратить перефразирование в гиперболу, в ram часто есть вещи, о которых даже система не сообщает хорошо.</p>

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