it-swarm-tr.com

Ne zaman/dev/shm/kullanmalı ve ne zaman/tmp/kullanmalıyım?

Ne zaman /dev/shm/ kullanmalı ve ne zaman /tmp/ kullanmalıyım? Her ikisinde de Unices'da olmalarına her zaman güvenebilir miyim?

126
Deleted

/dev/shm, geçici bir dosya depolama dosya sistemidir, yani, destek deposu için RAM kullanan tmpfs . İPC işlevini kolaylaştıran paylaşılan bellek uygulaması olarak işlev görebilir.

Wikipedia'dan :

En son 2.6 Linux çekirdeği,/dev/shm dosyasını ramdisk biçiminde paylaşılan bellek olarak, daha özel olarak/etc/default/tmpfs içinde tanımlanmış bir sınırla bellekte depolanan dünyaca yazılabilir bir dizin olarak sunmaya başladı./dev/shm desteği, çekirdek yapılandırma dosyasında tamamen isteğe bağlıdır. Pulseaudio uygulaması tarafından en yaygın kullanıldığı Fedora ve Ubuntu dağıtımlarında varsayılan olarak bulunur.(Vurgu eklenmiştir.)

/tmp , Filesystem Hierarchy Standard öğesinde tanımlandığı şekilde geçici dosyaların konumu olup, hemen hemen tüm Unix ve Linux dağıtımlarını takip eder.

RAM, disk depolama alanından önemli ölçüde daha hızlı olduğundan, işleminiz G/Ç yoğunsa ve yoğun olarak geçici dosyalar kullanıyorsa, performans artışı için /dev/shm yerine /tmp kullanabilirsiniz } kullanabilirsiniz.

Sorularınızı cevaplamak için: Hayır, her zaman /dev/shm'nin varlığına güvenemezsiniz, kesinlikle hafızaya bağlı olan makinelere değil. /tmp kullanmak için çok iyi bir nedeniniz yoksa, /dev/shm kullanmalısınız.

/tmp'nun ayrı bir montaj yerine / dosya sisteminin bir parçası olabileceğini ve dolayısıyla gerektiği şekilde büyüyebileceğini unutmayın. /dev/shm'nin boyutu sistemdeki RAM değerinin fazlasıyla sınırlıdır ve bu nedenle bu dosya sisteminde boş yer kalması daha olasıdır.

90
nagul

Azalan tmpfs olasılık derecesinde:

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

Bir Linux özel tmpfs mountpoint hakkında may tmpfs olan (sysadmin'inize ve dağıtımınız için varsayılana bağlı olarak) portatif olarak tanımlanmış bir dizine ilişkin sorular sorduğunuzdan, sorunuzun iki yönü vardır: başka hangi cevapların farklı vurguladıkları:

  1. Bu dizinleri ne zaman kullanacaksınız, iyi uygulamalara göre
  2. Tmpfs kullanmak uygun olduğunda

İyi uygulamalar

Muhafazakar baskı ( FHS ve genel kullanımdaki sözleşmelerin karışımı):

  • Şüphe duyduğunuzda, /tmp öğesini kullanın.
  • Ram'a kolayca sığmayabilecek büyük veriler için /var/tmp öğesini kullanın.
  • Yeniden başlatmalar arasında (önbellek gibi) saklamanın faydası olan veriler için /var/tmp öğesini kullanın.
  • /dev/shm öğesini shm_open() çağrısının yan etkisi olarak kullanın. Amaçlanan kitle, sınırsız olarak üzerine yazılmış arabelleklerdir. Yani bu, içeriği değişken olan ve çok büyük olmayan uzun ömürlü dosyalar içindir.
  • Hala şüpheniz varsa, kullanıcının geçersiz kılması için bir yol kullanın. Örneğin, mktemp programı TMPDIR ortam değişkenini onurlandırır.

Pragmatik baskı:

/dev/shm kullanın, tmpfs, /var/tmp kullanılmıyorsa, önemli değildir, /tmp.

TMPF'ler üstündür

fsync, tmpfs'de no-op'tur. Bu çağrı, (IO) performansının bir numaralı düşmanıdır (ve bunu önemsiyorsanız uzun ömürlüdür), ancak kendinizi sadece fsync'i yenmek için tmpfs (veya eatmydata ) kullanarak bulursanız, o zaman siz (veya başka bir şey) zincirinde geliştirici) yanlış bir şey yapıyoruz. Bu, depolama aygıtına yönelik işlemlerin gereksiz bir şekilde ince amaçlara sahip olduğu anlamına gelir; bu nedenle, artık hepsini sabote etmeye aşırı uçtuğunuzda - nadiren en iyi uzlaşmaya gittiğiniz için, performans için bazı tasarruf noktalarını atlamak için açıkça istekli olursunuz. Ayrıca, bir SSD'ye sahip olmanın en büyük yararlarından bazılarının olduğu - işlem performans alanında, herhangi bir düzgün SSD, bir eğirme diskinin alabileceği şeyle karşılaştırıldığında bu dünya dışında bir şey yapacak (7200 rpm = 120 Hz). eğer başka bir şeye erişmiyorsa, bu metriğe göre büyük ölçüde değişkenlik gösteren flash bellek kartlarından bahsetmeyin (en azından sıralı performansa sahip bir takas olduğu için değil, örneğin SD kart sınıf derecesi ile derecelendirildiği için). Bu nedenle, kullanıcılarınızı bu kullanım durumunun içine zorlamamak için yanan hızlı SSD'li geliştiricilere dikkat edin!

Saçma bir hikaye duymak ister misin? İlk fsync dersi: Sürekli değişen bir formata bir sürü Sqlite veritabanını (testcas olarak tutulur) düzenli olarak "yükseltme" içeren bir işim vardı. "Yükseltme" çerçevesi, bir veritabanını yükseltmek için her biri en az bir işlem yapan birçok komut dosyası çalıştırır. Tabii ki, veritabanlarımı paralel olarak yükselttim (8 paralel işlemden beri 8 çekirdekli CPU ile kutsandım). Ancak öğrendiğim gibi, hiçbir paralelleştirme hızı yoktu (aksine hafif hit ) çünkü işlem tamamen IO sınırlandı. Çok iyi bir şekilde, yükseltme çerçevesini her veritabanını /dev/shm dosyasına kopyalayan, oraya yükselten ve diske geri kopyalayan bir komut dosyasına sarmak, 100 kat daha hızlıydı (yine de 8 paralel). Bir bonus olarak, PC veritabanlarını yükseltirken kullanılabilir olarak da kullanılabilir.

Tmpfs uygun olduğunda

Tmpf'lerin uygun kullanımı, gereksiz uçucu veri yazılmasını önlemektir. Etkili bir şekilde devre dışı bırakmak writeback , normal bir dosya sisteminde sonsuza kadar /proc/sys/vm/dirty_writeback_centisecs ayarını yapmak gibi.

Bunun performansla çok az ilgisi var ve bu başarısızlık, fsync'i kötüye kullanmaktan çok daha küçük bir sorundur: Geri yazma zaman aşımı, disk içeriğinin pagecache içeriğinden sonra ne kadar temkinli olarak güncellendiğini ve bilgisayar için 5 saniyenin varsayılanının ne kadar uzun olduğunu belirler - bir uygulama, sayfa önbelleğinde, istediği sıklıkta dosyanın üzerine yazabilir, ancak diskteki içerik yalnızca her 5 saniyede bir güncellenir. Uygulama fsync ile zorlamadıkça, yani. Bir uygulamanın bu süre içinde kaç kez küçük bir dosya çıktısı alabileceğini düşünün ve her birini neden sindirmenin daha büyük bir sorun olacağını görüyorsunuz.

Hangi TMPF'ler size yardımcı olamaz

  • Performansı oku. Verileriniz sıcaksa (ki bunu tmpfs'de tutmayı düşünürseniz daha iyi olur), yine de pagecache'ye ulaşırsınız. Aradaki fark pagecache'ye vurmamak; bu durumda, aşağıdaki "Where tmpfs sux" bölümüne gidin.
  • Kısa ömürlü dosyalar. Bunlar tüm hayatlarını sayfa yazmadan önce (as dirty pages) yaşayabilir. Tabii fsync ile zorlamadıkça.

Nerede tmpfs sux

Tutulması soğuk veri. Takas dosyalarının değiş tokuş edilmesinin normal bir dosya sistemi kadar verimli olduğunu düşünmeye istekli olabilirsiniz, ancak bunun olmasının birkaç nedeni olabilir:

  • En basit sebep: Çağdaş depolama aygıtlarının (harddisk veya flash tabanlı) düzgün bir dosya sistemi tarafından düzenli bir şekilde düzenlenen oldukça sıralı dosyaları okumaktan daha fazla sevdiği bir şey yoktur. 4KiB bloklarda değiş tokuş yapmanın bu durumu iyileştirmesi mümkün değildir.
  • Gizli maliyet: Değiştirme out . Tmpfs sayfaları dirty - anında yedeklenebilecek clean sayfaların yedeklendiği dosyanın yerine, bir önbellekten çıkarılmak üzere bir yere (takas etmek için) yazılmalıdır. Bu, hafıza için rekabet eden diğer her şey için ekstra bir yazma cezasıdır - bu tmpfs sayfalarının kullanımından farklı bir zamanda başka bir şeyi etkiler.
52
user2394284

Tamam, işte gerçeklik.

Hem tmpfs hem de normal bir dosya sistemi, disk üzerindeki bir bellek önbelleğidir.

Tmpfs, bir dosya sisteminin belirli bir disk alanını kullandığı bir yedekleme deposunda olduğu gibi bellek ve takas alanını kullanır, dosya sisteminin olabileceği boyutta da sınırlı değildir, bir makinede 200 GB'lık bir tmpf'ye sahip olmak, eğer GB GB'den daha az bir RAM'e sahip olmak mümkündür. yeteri kadar takas alanınız var.

Fark, diske veri yazıldığında meydana gelir. Bir tmpfs için, veriler SADECE bellek dolduğunda veya verilerin yakında kullanılması muhtemel olmadığı zaman yazılır. OTOH çoğu normal Linux dosya sistemi diskte her zaman aşağı yukarı tutarlı bir veri setine sahip olacak şekilde tasarlanmıştır, böylece kullanıcı fişini çekerse her şeyi kaybetmez.

Şahsen, çökmeyen işletim sistemlerine ve UPS sistemlerine (örneğin: dizüstü bilgisayar pilleri) alışkınım, bu yüzden ext2/3 dosya sistemlerinin 5-10 saniyelik kontrol noktası aralıklarıyla çok paranoyak olduğunu düşünüyorum. Ext4 dosya sistemi 10 dakikalık bir kontrol noktasıyla daha iyidir, ancak kullanıcı verilerini ikinci sınıf olarak kabul eder ve korumaz. (ext3 aynıdır, ancak 5 saniye kontrol noktasından dolayı farketmiyorsunuz)

Bu sık kontrol işareti, gereksiz verilerin/tmp için bile sürekli olarak diske yazıldığı anlamına gelir.

Sonuç olarak,/tmp'nizin gerek duyduğu kadar büyük bir takas alanı oluşturmanız (bir takas dosyası oluşturmak zorunda olsanız bile) ve bu alanı gerekli boyutta bir tmpfs'yi/tmp'ye monte etmek için kullanmanız gerekir.

ASLA/dev/shm kullanmayın.

Tabi, çok küçük (muhtemelen mmap'd) IPC dosyalar için kullanıyorsanız ve var olduğundan (standart değil) olduğundan ve makinenizde yeterli bellek + takası olduğundan emin olun.

18
Robert

Geçici dosyalar için/tmp/kullanın. Paylaşılan hafızayı istediğiniz zaman/dev/shm/kullanın (örn. Dosyalar üzerinden işlemler arası iletişim).

Orada/tmp/varlığına güvenebilirsiniz, ancak/dev/shm/görece yeni bir Linux olayıdır.

4
Captain Segfault

/ Dev/shm (Linux 2.6 ve üstü için) kullanmanız gereken bir başka zaman, garantili bir tmpfs dosya sistemine ihtiyacınız olduğundadır çünkü eğer diske yazıp yazamayacağınızı bilmiyorsunuz.

Tanıdığım bir izleme sistemi, merkezi bir sunucuya gönderim için raporunu oluştururken geçici dosyalar yazma ihtiyacı duyuyor. Uygulamada bir şeyin bir dosya sistemine yazılmasını engellemesi çok muhtemeldir (disk alanı yetersiz veya altta yatan bir RAID hatası, sistemi salt okunur bir donanım moduna itti), ancak yine de alarm vermeye devam edebilirsiniz bu konuda bir şey mevcut tüm belleği tmpfs kullanılamayacak şekilde (ve kutu ölmeyecek) olacak şekilde spiraller. Bu gibi durumlarda, bir izleme sistemi potansiyel olarak tam bir disk veya ölü/ölü donanım hakkında bir uyarı gönderebilmek için RAM 'e yazmayı tercih edecektir.

1
Japheth Cleaver

Her makinede minimum 8GB olan Perl'de (tümü Linux Nane çalıştıran), milyonlarca okuma ve yazma ile/dev/kullanarak DB_File tabanlı (bir dosyadaki veri yapısı) karmaşık algoritmalar yapmanın iyi bir alışkanlığı olduğunu düşünüyorum. shm

Diğer dillerde, herhangi bir yere sahip olmamak, ağ aktarımında başlama ve durmayı önlemek için (yerel olarak bir istemci-sunucu atmosferinde bir sunucuda bulunan bir dosyada yerel olarak çalışan), bazı türden bir toplu iş dosyası kullanarak kopyalayacağım. tüm (300-900MB) dosyayı bir kerede/dev/shm dosyasına, programı çıktıyla/dev/shm'ye çalıştırın, sonuçları sunucuya yazın ve/dev/shm'den silin

Doğal olarak, daha az RAM'im olsaydı, bunu yapmazdım. Normalde,/dev/shm'nin hafıza içi dosya sistemi mevcut RAM'inizin yarısı kadar bir boyut olarak okur. Bununla birlikte, sıradan RAM kullanımı sabittir. Yani bunu gerçekten 2GB veya daha az olan bir cihazda yapamazsınız. Paragrafı abartma haline çevirmek için, çoğu zaman RAM içinde sistemin bile iyi raporlamadığı şeyler vardır.

0
David Grove

/ dev/shm, paylaşılan sanal bellek sistemine özgü aygıt sürücüleri ve programları için kullanılır.

Sanal belleğe eşlenmesi gereken sanal bellek yığını gerektiren bir program oluşturuyorsanız. Bu ikiye katlanır, böylece bu belleğe güvenle erişebilmek için birden fazla işlem veya iş parçacığına ihtiyacınız varsa.

Gerçek şu ki, sürücü bunun için özel bir tmpfs sürümünü kullanması, onu genel bir tmpfs bölümü olarak kullanmanız gerektiği anlamına gelmez. Bunun yerine, geçici dizininiz için bir tane istiyorsanız, başka bir tmpfs bölümü oluşturmalısınız.

0