Kapan saya harus menggunakan /dev/shm/ dan kapan saya harus menggunakan /tmp/?

/dev/shm adalah sistem file penyimpanan file sementara, yaitu, tmpfs, yang menggunakan RAM sebagai backing store. Ini dapat berfungsi sebagai implementasi memori bersama yang memfasilitasi IPC.

Dari Wikipedia:

Build kernel Linux 2.6 baru-baru ini telah mulai menawarkan /dev/shm sebagai memori bersama dalam bentuk ramdisk, lebih khusus lagi sebagai direktori yang dapat ditulis dunia yang disimpan dalam memori dengan batas yang ditentukan di /etc/default/tmpfs. /dev/shm support sepenuhnya opsional dalam file konfigurasi kernel. Ini disertakan secara default di distribusi Fedora dan Ubuntu, yang paling banyak digunakan oleh aplikasi Pulseaudio.

/tmp adalah lokasi untuk file-file sementara sebagaimana didefinisikan dalam Filesystem Hierarchy Standard, yang diikuti oleh hampir semua distribusi Unix dan Linux.

Karena RAM jauh lebih cepat daripada penyimpanan disk, Anda dapat menggunakan /dev/shm bukannya /tmp untuk peningkatan kinerja, jika proses Anda intensif I/O dan banyak menggunakan file sementara.

Untuk menjawab pertanyaan Anda:Tidak, Anda tidak dapat selalu mengandalkan /dev/shm hadir, tentu saja tidak pada mesin yang kekurangan memori. Anda harus menggunakan /tmp kecuali jika Anda memiliki alasan yang sangat bagus untuk menggunakan /dev/shm .

Ingat bahwa /tmp dapat menjadi bagian dari / sistem file alih-alih mount terpisah, dan karenanya dapat tumbuh sesuai kebutuhan. Ukuran /dev/shm dibatasi oleh kelebihan RAM pada sistem, dan karenanya Anda cenderung kehabisan ruang pada sistem file ini.

Dalam urutan menurun tmpfs kemungkinan:

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

Karena Anda bertanya tentang tmpfs khusus Linux mountpoint versus direktori yang didefinisikan secara portabel yang mungkin be tmpfs (bergantung pada sysadmin Anda dan apa default untuk distro Anda), pertanyaan Anda memiliki dua aspek, yang ditekankan oleh jawaban lain secara berbeda:

1. Penggunaan yang tepat dari berbagai direktori tmp
2. Penggunaan tmpfs yang tepat

Penggunaan yang tepat dari berbagai direktori tmp

Berdasarkan Standar Hirarki Sistem File kuno dan apa yang dikatakan Systemd tentang masalah ini.

• Bila ragu, gunakan /tmp .
• Gunakan /var/tmp untuk data yang harus tetap ada saat reboot.
• Gunakan /var/tmp untuk data besar yang mungkin tidak mudah masuk ke dalam RAM (dengan asumsi bahwa /var/tmp memiliki lebih banyak ruang yang tersedia – biasanya asumsi yang adil).
• Gunakan /dev/shm hanya sebagai efek samping dari pemanggilan shm_open() . Audiens yang dituju adalah buffer terbatas yang ditimpa tanpa henti. Jadi ini untuk file berumur panjang yang isinya tidak stabil dan tidak terlalu besar.
• Jelas jangan gunakan /dev/shm untuk file yang dapat dieksekusi (dalam bentuk apa pun), seperti yang biasa dipasang noexec .
• Jika masih ragu, sediakan cara bagi pengguna untuk menimpa. Untuk sedikit kejutan, lakukan seperti mktemp dan hormati TMPDIR variabel lingkungan.

Di mana tmpfs unggul

Penting untuk mengatakan bahwa di mana tmpfs benar-benar unggul, di atas segalanya, adalah menyembunyikan bug kinerja yang sangat signifikan pada disk yang berputar. Jadi jika memperbaikinya adalah pilihan, ini tentu saja penggunaan tmpfs yang tidak tepat :

fsync adalah no-op di tmpfs. Syscall ini memberi tahu OS untuk menghapus cache halamannya yang terkait dengan file, terus ke bawah untuk menghapus cache tulis dari perangkat penyimpanan yang relevan, sambil memblokir program yang mengeluarkannya dari membuat kemajuan sama sekali - penghalang tulis yang sangat kasar . Ini adalah alat yang diperlukan di dalam kotak hanya karena protokol penyimpanan tidak dibuat dengan mempertimbangkan transaksi. Dan caching ada di tempat pertama untuk memungkinkan program melakukan jutaan penulisan kecil ke file tanpa memperhatikan seberapa lambat sebenarnya menulis ke perangkat penyimpanan - semua penulisan yang sebenarnya terjadi secara asinkron, atau hingga fsync disebut, yang merupakan satu-satunya tempat kinerja tulis dirasakan langsung oleh program.

Jadi jika Anda menemukan diri Anda menggunakan tmpfs (atau eatmydata) hanya untuk mengalahkan fsync, maka Anda (atau pengembang lain dalam rantai) melakukan kesalahan. Ini berarti bahwa transaksi ke perangkat penyimpanan tidak perlu dihaluskan untuk tujuan Anda – Anda jelas ingin melewati beberapa titik penyimpanan untuk kinerja, karena Anda sekarang telah melakukan sabotase ekstrem untuk semuanya – jarang kompromi terbaik. Selain itu, di sini, di bidang kinerja transaksi, di mana beberapa manfaat terbesar memiliki SSD adalah – SSD apa pun yang bernilai tinggi akan bekerja di luar dunia ini dibandingkan dengan apa yang dapat dilakukan oleh disk berputar (7200 rpm =120 Hz, jika tidak ada orang lain yang mengaksesnya). Kartu memori flash juga sangat bervariasi pada metrik ini (ini merupakan tradeoff dengan kinerja berurutan, dan peringkat kelas kartu SD hanya mempertimbangkan yang terakhir). Jadi berhati-hatilah, developer dengan SSD super cepat, jangan memaksa pengguna Anda menggunakan kasus penggunaan ini!

Ingin mendengar cerita konyol? fsync pertama saya pelajaran:Saya memiliki pekerjaan yang melibatkan "peningkatan" secara rutin sekumpulan database Sqlite (disimpan sebagai kasus uji) ke format saat ini yang selalu berubah. Kerangka kerja "peningkatan" akan menjalankan banyak skrip, masing-masing membuat setidaknya satu transaksi, untuk memutakhirkan satu basis data. Tentu saja, saya memutakhirkan basis data saya secara paralel (8 secara paralel, karena saya diberkati dengan CPU 8 inti yang hebat). Tapi seperti yang saya ketahui, tidak ada percepatan paralelisasi sama sekali (agak hit ) karena prosesnya sepenuhnya terikat IO. Lucunya, membungkus kerangka pemutakhiran dalam skrip yang menyalin setiap basis data ke /dev/shm , memutakhirkannya di sana, dan menyalinnya kembali ke disk seperti 100 kali lebih cepat (masih dengan 8 secara paralel). Sebagai bonus, PC itu dapat digunakan juga, saat memutakhirkan basis data.

Di mana tmpfs sesuai

Penggunaan tmpfs yang tepat adalah untuk menghindari penulisan data volatil yang tidak perlu. Menonaktifkan penulisan secara efektif , seperti menyetel /proc/sys/vm/dirty_writeback_centisecs hingga tak terbatas pada sistem file biasa.

Ini tidak ada hubungannya dengan kinerja, dan kegagalan ini adalah masalah yang jauh lebih kecil daripada menyalahgunakan fsync:Batas waktu penulisan kembali menentukan seberapa malas konten disk diperbarui setelah konten pagecache, dan default 5 detik adalah waktu yang lama untuk komputer – aplikasi dapat menimpa file sesering yang diinginkan, di pagecache, tetapi konten di disk hanya diperbarui setiap 5 detik sekali. Kecuali jika aplikasi memaksanya dengan fsync, yaitu. Pikirkan tentang berapa kali aplikasi dapat menghasilkan file kecil saat ini, dan Anda tahu mengapa menyinkronkan setiap file akan menjadi masalah yang jauh lebih besar.

Tmpfs tidak dapat membantu Anda

• Kinerja baca. Jika data Anda panas (yang lebih baik jika Anda mempertimbangkan untuk menyimpannya di tmpfs), Anda tetap akan menekan pagecache. Perbedaannya adalah saat tidak menekan pagecache; jika demikian, buka "Where tmpfs sux", di bawah.
• File berumur pendek. Ini dapat menjalani seluruh hidupnya di cache halaman (sebagai kotor halaman) sebelum pernah ditulis. Kecuali jika Anda memaksanya dengan fsync tentu saja.

Di mana tmpfs sux

Menjaga dingin data. Anda mungkin tergoda untuk berpikir bahwa melayani file dari swap sama efisiennya dengan sistem file normal, tetapi ada beberapa alasan mengapa tidak demikian:

• Alasan paling sederhana:Tidak ada yang lebih disukai oleh perangkat penyimpanan kontemporer (baik itu harddisk atau flash) selain membaca file yang cukup berurutan yang diatur dengan rapi oleh sistem file yang tepat. Bertukar dalam blok 4KiB sepertinya tidak akan memperbaiki hal itu.
• Biaya tersembunyi:Menukar keluar . Halaman tmpfs kotor — mereka harus ditulis di suatu tempat (untuk bertukar) untuk diusir dari pagecache, sebagai lawan dari file yang didukung clean halaman yang dapat dijatuhkan secara instan. Ini adalah hukuman tulis tambahan pada semua hal lain yang bersaing untuk mendapatkan memori – memengaruhi hal lain pada waktu yang berbeda dari penggunaan halaman tmpfs tersebut.

Oke, inilah kenyataannya.

Baik tmpfs dan sistem file normal adalah cache memori melalui disk.

Tmpfs menggunakan memori dan ruang swap karena mendukung penyimpanan sistem file menggunakan area disk tertentu, ukuran sistem file juga tidak terbatas, sangat mungkin untuk memiliki tmpfs 200GB pada mesin dengan ram kurang dari satu GB jika Anda memiliki ruang swap yang cukup.

Perbedaannya terletak pada saat data ditulis ke disk. Untuk tmpfs, data HANYA ditulis ketika memori terlalu penuh atau data kemungkinan tidak akan segera digunakan. Sistem file Linux OTOH yang paling normal dirancang untuk selalu memiliki kumpulan data yang kurang lebih konsisten pada disk sehingga jika pengguna mencabut steker, mereka tidak kehilangan segalanya.

Secara pribadi, saya terbiasa memiliki sistem operasi yang tidak crash dan sistem UPS (misalnya:baterai laptop) jadi menurut saya sistem file ext2/3 terlalu paranoid dengan interval checkpoint 5-10 detik. Sistem file ext4 lebih baik dengan pos pemeriksaan 10 menit, kecuali memperlakukan data pengguna sebagai kelas dua dan tidak melindunginya. (ext3 sama tetapi Anda tidak menyadarinya karena pos pemeriksaan 5 detik)

Pemeriksaan yang sering ini berarti bahwa data yang tidak perlu terus ditulis ke disk, bahkan untuk /tmp.

Jadi hasilnya adalah Anda perlu membuat ruang swap sebesar yang Anda butuhkan /tmp (bahkan jika Anda harus membuat file swap) dan menggunakan ruang itu untuk memasang tmpfs dengan ukuran yang diperlukan ke /tmp.

JANGAN PERNAH menggunakan /dev/shm.

Kecuali, Anda menggunakannya untuk file IPC yang sangat kecil (mungkin mmap'd) dan Anda yakin itu ada (ini bukan standar) dan mesin memiliki lebih dari cukup memori + swap yang tersedia.