Відповіді:
/dev/shmє тимчасовою файловою системою зберігання файлів, тобто tmpfs , яка використовує оперативну пам’ять для резервного сховища. Він може функціонувати як реалізація спільної пам'яті, що полегшує IPC .
Останні версії 2.6 ядра Linux почали пропонувати / dev / shm як спільну пам'ять у вигляді ramdisk, точніше як всесвітньо доступний каталог, який зберігається в пам'яті з визначеним обмеженням в / 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), яку підтримує диск (своп). /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 │
└───────────┴──────────────┴────────────────┘
Оскільки ви запитуєте про конкретну точку монтування tmpfs для Linux, а не про портативно визначений каталог, який може бути tmpfs (залежно від вашого sysadmin та того, що визначено для вашого дистрибутива), у вашого запитання є два аспекти, на які інші відповіді підкреслюють по-різному:
Консервативне видання (суміш конвенцій 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 (зберігається як тестові шафи) до постійно змінюваного поточного формату. Рамка "оновлення" запускає купу сценаріїв, здійснюючи принаймні одну транзакцію для оновлення однієї бази даних. Звичайно, я модернізував свої бази даних паралельно (8 паралельно, оскільки мене поблажив могутній 8 ядерний процесор). Але, як я з'ясував, прискорення паралелізації не було (швидше, невеликий удар ), оскільки процес був повністю пов'язаний з IO. Весело, загортання рамки оновлення у сценарій, який скопіював кожну базу даних /dev/shm, модернізував її та скопіював її назад на диск, був як у 100 разів швидшим (все ще з 8 паралельно). Як бонус, ПК був корисним також під час оновлення баз даних.
Відповідне використання tmpfs полягає у тому, щоб уникнути зайвого запису летких даних. Ефективно відключення зворотного запису , як установка /proc/sys/vm/dirty_writeback_centisecsна нескінченність на регулярній файлової системи.
Це має дуже мало спільного з продуктивністю, і, якщо цього не зробити, це набагато менший занепокоєння, ніж зловживання fsync: час очікування відтворення визначає, наскільки ліниво оновлюється вміст диска після вмісту сторінки кеш-пам'яті, а за замовчуванням 5 секунд - це довгий час для комп'ютера - програма може перезаписувати файл у сховищі сторінок так часто, як хоче, але вміст на диску оновлюється лише раз на 5 секунд. Якщо додаток не змушує його за допомогою fsync, тобто. Подумайте про те, скільки разів програма може вивести невеликий файл за цей час, і ви бачите, чому синювання кожного окремого буде набагато більшою проблемою.
fsyncзвичайно, не примусиш.Зберігання холодних даних. Можливо, вам сподобається думати, що подання файлів поза свопом так само ефективно, як і звичайна файлова система, але є кілька причин, чому це не так:
mount -t tmpfs "jarno is great" /mnt/jarnoякщо хочете! По-третє, розмір за замовчуванням - це половина обсягу оперативної пам’яті.
Гаразд, ось реальність.
І tmpfs, і звичайна файлова система - це кеш пам'яті на диску.
Tmpfs використовує пам'ять і swapspace, оскільки він підтримує зберігання файлової системи, яка використовує певну область диска, не обмежена розміром, якою може бути файлова система, цілком можливо мати 200 ГБ tmpfs на машині з меншим ГБ оперативної пам'яті, якщо у вас достатньо простору.
Різниця полягає в тому, коли дані записуються на диск. Для tmpfs дані записуються ТІЛЬКИ, коли пам'ять стає занадто повною або дані навряд чи будуть використані незабаром. Найбільш звичайні файлові системи Linux OTOH призначені для того, щоб завжди мати більш-менш послідовний набір даних на диску, тому якщо користувач витягне плагін, вони не втратять усе.
Особисто я звик мати операційні системи, які не виходять з ладу та системи ДБЖ (наприклад, батареї ноутбука), тому я думаю, що файлові системи ext2 / 3 занадто параноїдальні з інтервалом контрольної точки 5-10 секунд. Файлова система ext4 краще з 10-хвилинною контрольною точкою, за винятком того, що вона розглядає дані користувачів як другий клас і не захищає їх. (ext3 те саме, але ви цього не помічаєте через 5-секундної контрольної точки)
Ця часта контрольна точка означає, що зайві дані постійно записуються на диск, навіть для / tmp.
Таким чином, результат - вам потрібно створити розмір простору розміру, який вам потрібен / tmp (навіть якщо вам доведеться створити swapfile) і використовувати цей простір для монтажу 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 Linux Mint), я вважаю, що це гарна звичка робити складні алгоритми на основі DB_File (структура даних у файлі) з мільйонами читання та запису за допомогою / dev / шм
Іншими мовами, не маючи скрізь gigether, щоб уникнути запусків і зупинок у передачі мережі (локально працюючи над файлом, який знаходиться на сервері в атмосфері клієнт-сервер), використовуючи пакетний файл певного типу, я скопіюю весь (300-900MB) файл одразу до / dev / shm, запустіть програму з виведенням у / dev / shm, запишіть результати на сервер та видаліть з / dev / shm
Природно, якби у мене було менше оперативної пам’яті, я б цього не робив. Зазвичай файлова система в пам'яті / dev / shm читається як розмір, що становить половину вашої доступної оперативної пам’яті. Однак звичайне використання оперативної пам’яті є постійним. Таким чином, ви дійсно не могли цього зробити на пристрої з 2 Гб або менше. Щоб перетворити парафрази на гіперболи, часто в оперативній пам'яті трапляються речі, про які навіть система не надто добре повідомляє.
/dev/shmіснує, використовувати його, якщо він є, або резервний/tmp. Це добре звучить?