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

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

/dev/shmgeçici bir dosya depolama dosya sistemidir, yani, destek deposu için RAM kullanan tmpfs . IPC'yi kolaylaştıran ortak bir bellek uygulaması olarak işlev görebilir .

Wikipedia'dan :

Son 2.6 Linux çekirdeği, / dev / shm'yi ramdisk biçiminde paylaşılan bellek olarak, daha özel olarak / etc / default / tmpfs içinde tanımlanmış bir limitli 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 olarak kullanıldığı Fedora ve Ubuntu dağıtımlarında varsayılan olarak bulunur.             ^{(Vurgu eklendi.)}

/tmpNeredeyse tüm Unix ve Linux dağıtımları tarafından takip edilen Dosya Sistemi Hiyerarşisi Standardında tanımlanan geçici dosyaların yeridir .

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ışı yerine kullanabilirsiniz/dev/shm/tmp .

Sorularınıza cevap vermek için: Hayır, her zaman /dev/shmhazır bulunmaya güvenemezsiniz , kesinlikle hafızaya sarılmış makinelere değil. Kullanmak /tmpiçin çok iyi bir nedeniniz yoksa kullanmalısınız /dev/shm.

Unutmayın, ayrı bir montaj yerine dosya sisteminin bir /tmpparçası olabilir /ve bu nedenle gerektiği gibi büyüyebilir. Boyutu /dev/shmsistemdeki aşırı RAM ile sınırlıdır ve bu nedenle bu dosya sistemindeki boş alanın kalması daha olasıdır.

Azalan tmpfsolasılık düzeninde :

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

Linux'a özgü bir tmpfs mountpoint'i tmpfs olabilecek taşınabilir bir tanımlanmış dizine karşı sorduğunuzdan (sysadmin'inize ve dağıtımınız için neyin varsayılan olduğuna bağlı olarak), sorunuzun diğer yanıtların farklı şekilde vurguladığı iki yönü vardır:

1. Bu rehberleri ne zaman kullanmalı, iyi uygulamalara dayanarak
2. Tmpfs kullanmak uygun olduğunda

İyi uygulamalar

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

• Şüphe duyduğunuzda, kullanın /tmp.
• /var/tmpRam'a kolayca sığmayabilecek büyük veriler için kullanın .
• /var/tmpYeniden başlatmaları engellemek için yararlı olan (önbellek gibi) veriler için kullanın .
• Aramanın /dev/shmyan etkisi olarak kullanın shm_open(). Amaçlanan kitle, sınırsız olarak üzerine yazılmış arabelleklerdir. Yani bu, içeriği değişken 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, mktempprogram TMPDIRortam değişkenini onurlandırıyor .

Pragmatik baskı:

Kullan /dev/shmo tmpfs kullanmak önemlidir zaman /var/tmpdeğil önemlidir başka ne zaman, /tmp.

TMPF'ler üstündür

fsynctmpfs'de operasyon dışıdır. Bu çağrı, eğer kendinizi tmpfs (veya eatmydata) kullanarak bulursanız (IO) performansının bir numaralı düşmanıdır (ve bunu önemsiyorsanız uzun ömürlüdür)) sadece fsync'i yenmek için, o zaman siz (veya zincirdeki başka bir geliştirici) yanlış bir şey yapıyorsunuzdur. 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, burada bir SSD'ye sahip olmanın en büyük yararlarından bazılarının olduğu - işlem alanında, herhangi bir nezih SSD, bir eğirme diskinin alabileceği şeyle karşılaştırıldığında bu dünya dışı bir performans sergileyecektir (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ında derecelendirilenler). Bu yüzden sakının,

Saçma bir hikaye duymak ister misin? İlk fsyncdersim: Sürekli değişen bir formata düzenli aralıklarla bir sürü Sqlite veritabanını (test penceresi olarak tutulan) yükseltmeyi 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, veri tabanlarımı paralel olarak yükselttim (8 paralel işlemden beri 8 çekirdekli CPU ile kutsandım). Ancak öğrendiğim gibi, hiçbir şekilde paralelleştirme hızlanmadı (hiç de hafif bir vuruş olmadı ) çünkü süreç tamamen IO'ya bağlıydı. Çok komik bir şekilde, yükseltme çerçevesini her veritabanını kopyalayan /dev/shm, oraya yükselten ve diske geri kopyalayan bir betiğe sarmak 100 kat daha hızlıydı (yine de paralel olarak 8). Bir bonus olarak, PC kullanılabilir de veritabanlarını yükseltirken.

Tmpfs uygun olduğunda

Tmpf'lerin uygun kullanımı, gereksiz uçucu veri yazılmasını önlemektir. Normal bir dosya sisteminde sonsuza kadar ayarlamak gibi geri yazma etkin bir şekilde devre dışı bırakılması /proc/sys/vm/dirty_writeback_centisecs.

Bunun performansla çok az ilgisi var ve bunun başarısız olması fsync'i kötüye kullanmaktan çok daha küçük bir endişe kaynağı: 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 zamanının ne kadar uzun olduğunu belirliyor - 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 (eğer onu tmpfs'de tutmayı düşünürseniz daha iyi olur), yine de pagecache'ye varacaksı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ı sayfalarına yazılmadan önce sayfalarında ( kirli sayfalar olarak) yaşayabilir . Tabii ki zorlamadıkça fsync.

Nerede tmpfs sux

Soğuk verileri tutmak . Takas dosyalarının değiş tokuş edilmesinin normal bir dosya sistemi kadar verimli olduğunu düşünmeye istekli olabilirsiniz, ancak bunun olmamasının birkaç nedeni var:

• 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 maliyeti: Değişim dışarı . Tmpfs sayfaları kirli - anında bırakılabilen dosya destekli temiz sayfaların aksine, sayfa önbellekten çıkarılacak bir yere (takas etmek için) yazılmaları gerekiyor . 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.

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ı kullanan 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 olduklarını 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 kullanmıyorsanız ve var olduğundan (standart değildir) olduğundan ve makinenizde yeterli bellek + takası olduğundan emin olursunuz.

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.

Eğer varsa bilmiyorum, çünkü bir dosya sistemi tmpfs garanti ihtiyacınız olduğunda (yukarıda Linux 2.6 ve için) / dev / SHM kullanmalıdır Başka zaman olduğu yapabilirsiniz diske yazma.

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 uyarmaya 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 RAM'e yazmayı tercih eder, böylece potansiyel olarak tam bir disk veya ölü / ölmekte olan donanım hakkında bir uyarı gönderebilir.

/ 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 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ünün bunun için özel bir tmpfs sürümü 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.

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ğ transferinde 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. Ancak, normal RAM kullanımı sabittir. Yani bunu gerçekten 2GB veya daha az olan bir cihazda yapamazsınız. Paragrafı abartılı hale getirmek için RAM'de sistemin bile iyi raporlamadığı şeyler vardır.