سؤال متى يمكنني استخدام / dev / shm / ومتى يجب علي / tmp /؟


متى يجب علي استخدامها /dev/shm/ ومتى يجب علي ان استخدم /tmp/؟ هل يمكنني دائمًا الاعتماد عليها سواءً على Unices؟


111
2017-09-22 23:26


الأصل




الأجوبة:


/dev/shm هو نظام ملفات تخزين ملفات مؤقت ، على سبيل المثال ، tmpfs، الذي يستخدم ذاكرة الوصول العشوائي لمتجر الدعم. يمكن أن يعمل كتطبيق ذاكرة مشتركة يسهل ذلك IPC.

من ويكيبيديا:

بدأت أحدث إصدارات Linux kernel 2.6 لتقديم / dev / shm كذاكرة مشتركة في شكل ramdisk ، بشكل أكثر تحديدًا كدليل عالمي قابل للكتابة يتم تخزينه في الذاكرة مع حد محدد في / etc / default / tmpfs.    يعد دعم dev / sh / اختياريًا تمامًا داخل ملف تهيئة kernel.   يتم تضمينه افتراضيًا في كل من توزيعات Fedora و Ubuntu ، حيث يتم استخدامه على نطاق واسع بواسطة تطبيق Pulseaudio.   (تم اضافة التأكيدات.)

/tmp هو موقع الملفات المؤقتة كما هو محدد في نظام الملفات التسلسل الهرمي قياسي، والتي يتبعها تقريبا كل توزيعات يونكس ولينكس.

نظرًا لأن ذاكرة الوصول العشوائي أسرع بشكل كبير من تخزين القرص ، يمكنك ذلك استعمال /dev/shm بدلا من /tmp لزيادة الأداء، إذا كانت العملية الخاصة بك هي I / O مكثفة وتستخدم على نطاق واسع الملفات المؤقتة.

للإجابة على أسئلتك: لا ، لا يمكنك الاعتماد عليها دائمًا /dev/shm كونها موجودة ، وبالتأكيد ليس على آلات مربوطة بالذاكرة. يجب عليك استخدامها /tmp ما لم يكن لديك سبب وجيه جدا لاستخدام /dev/shm.

تذكر ذلك /tmp يمكن أن يكون جزءًا من / نظام الملفات بدلا من تركيب منفصل ، وبالتالي يمكن أن تنمو على النحو المطلوب. حجم /dev/shm محدودة من خلال ذاكرة الوصول العشوائي الزائدة على النظام ، وبالتالي من المرجح أن نفاد المساحة على نظام الملفات هذا.


83
2017-09-23 10:18



سوف أستخدمه لإعادة توجيه الإخراج من إخراج الخطأ القياسي للأوامر إلى ملف. ثم سأقرأ هذا الملف ومعالجته. سوف أفعل هذا عدة آلاف من المرات (إنه جزء من حالة بناء الحلقة). اعتقدت أن الذاكرة ستكون لطيفة في هذه الحالة. لكنني أريده أيضًا أن يكون محمولًا. أعتقد أنني سوف تحقق ما إذا كان /dev/shm موجود ، استخدمه إذا كان كذلك ، أو استخدمه /tmp. هل هذا الصوت جيدة؟ - Deleted
وأود أيضًا أن أضيف شيكًا للحد الأدنى للحجم ومستوى الاستخدام الحالي لـ / dev / shm للحيلولة دون ملؤه عن غير قصد. - nagul
تحت Linux 2.6 والإصدارات الأحدث ، لابد من تركيب / dev / shm لمكالمات نظام الذاكرة المشتركة POSIX مثل shm_open () للعمل. بعبارة أخرى ، ستنكسر بعض البرامج إذا لم يتم تركيبها - لذا ينبغي أن تكون. انها ليست مجرد قرص ذاكرة الوصول العشوائي. لذلك يجب عليك التأكد من أن بعض / dev / shm مجاني. - EdH
لا يوجد أي زيادة في الأداء باستخدام /dev/shm. /dev/shm هي الذاكرة (tmpfs) المدعومة من القرص (المبادلة). /var/tmp هو ذاكرة (ذاكرة التخزين المؤقت القرص) مدعومة من القرص (نظام الملفات على القرص). في الممارسة ، والأداء هو نفسه تقريبا (tmpfs له حافة طفيفة ولكن ليس ما يكفي للمادة). /tmp قد يكون tmpfs أو لا يعتمد على كيفية تكوين المسؤول. لا يوجد سبب وجيه للاستخدام /dev/shm في النصوص الخاصة بك. - Gilles
GaretClaborn هناك الكثير من الأسباب الوجيهة لاستخدام الذاكرة المدعومة بالمبادلة ، ولكن تسمى ذاكرة العملية العادية. إذا كنت تستخدم ملفًا ، يطلق عليه نظام ملفات ، وجميع أنظمة الملفات عبارة عن ذاكرة (ذاكرة تخزين مؤقت) ، والتي يتم دعمها مبادلة إذا كان نظام الملفات يشبه tmpfs. عادةً ما يكون تخصيص مساحة القرص بين التبادل ومناطق التخزين الأخرى في حالة المسؤول. إذا كان التطبيق يريد الملفات التي تميل إلى البقاء في ذاكرة الوصول العشوائي ، /tmp هو الموقع الطبيعي (مع $TMPDIR لتجاوز). اختيار لجعل /tmp مدعومة عن طريق المبادلة ، مساحة القرص الأخرى أو لا شيء هو المسؤول. - Gilles


بترتيب تنازلي من tmpfs يكيليهود:

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

لأنك تسأل عن لينكس محددة tmpfs نقطة في مقابل الدليل المحدد للمناطق التي قد أن تكون tmpfs (اعتمادا على مسؤول النظام الخاص بك وما هو الافتراضي لتوزيعة الخاص بك) ، سؤالك لديه جانبين ، والتي أكدت إجابات أخرى بشكل مختلف:

  1. متى تستخدم هذه الأدلة ، على أساس ممارسة جيدة
  2. عندما يكون من المناسب استخدام tmpfs

الممارسات الجيدة

طبعة المحافظ (خليط من الاتفاقيات من FHS والاستخدام الشائع):

  • عندما تكون في شك ، استخدم /tmp.
  • استعمال /var/tmp للبيانات الكبيرة التي قد لا تتناسب بسهولة مع ذاكرة الوصول العشوائي.
  • استعمال /var/tmp للبيانات التي من المفيد أن تبقى عبر إعادة تمهيد (مثل ذاكرة التخزين المؤقت).
  • استعمال /dev/shm كأثر جانبي للاتصال shm_open(). الجمهور المقصود هو المخازن المؤقتة التي لا تنتهي التي يتم الكتابة فوقها. هذا هو للملفات طويلة الأجل التي يكون محتوىها متقلبًا وليس كبيرًا بشكل كبير.
  • إذا كنت لا تزال موضع شك ، فقم بتوفير طريقة للمستخدم لتجاوزها. على سبيل المثال ، mktemp برنامج يكرم TMPDIR متغيرات البيئة.

الطبعة البراغماتية:

استعمال /dev/shm عندما يكون من المهم استخدام tmpfs ، /var/tmp عندما يكون من المهم عدم ، آخر /tmp.

حيث تتفوق tmpfs

fsync هو لا على أساس tmpfs. هذا syscall هو العدو الأول لأداء (IO) (وعمر الفلاش ، إذا كنت تهتم بذلك) ، على الرغم من ذلك إذا وجدت نفسك تستخدم tmpfs (أو eatmydata) فقط لهزيمة fsync ، فأنت (أو بعض المطورين الآخرين في السلسلة) يفعلون شيئًا خاطئًا. ويعني ذلك أن المعاملات التي تتم من خلال جهاز التخزين تكون ذات حبيبات لا داعي لها للغرض الخاص بك - فأنت ترغب بوضوح في تخطي بعض نقاط الادخار للأداء ، لأنك قد وصلت الآن إلى أقصى ما يمكن تخريبه - نادراً ما يكون أفضل حل وسط. أيضا ، هنا في أرض أداء المعاملة حيث بعض من الفوائد الأعظم من وجود SSD - أي SSD لائق سوف ينفذ خارج هذا العالم مقارنة بما يمكن أن يأخذه قرص الغزل (7200 دورة في الدقيقة = 120 Hz ، إذا كان notihing آخر هو الوصول إليه) ، ناهيك عن بطاقات ذاكرة فلاش ، والتي تختلف بشكل كبير على هذا المقياس (على الأقل لأنه هو المقايضة مع الأداء المتسلسل ، وهو ما يتم تقييمها من قبل ، على سبيل المثال تصنيف بطاقة SD بطاقة). لذا احذر ، المطورين الذين لديهم محركات أقراص SSD سريعة ، ليس لإجبار المستخدمين على استخدام حالة الاستخدام هذه!

أريد أن أسمع قصة سخيفة؟ الخاص بي أولا fsync درس: كان لدي وظيفة تنطوي بشكل روتيني على "ترقية" مجموعة من قواعد بيانات Sqlite (المحفوظة كإختبارات) إلى صيغة متغيرة باستمرار. سيعمل إطار "الترقية" على تشغيل مجموعة من النصوص البرمجية ، مما يجعل كل معاملة واحدة على الأقل ، لترقية قاعدة بيانات واحدة. بالطبع ، قمت بترقية قواعد البيانات الخاصة بي بالتوازي (8 في موازاة ذلك ، حيث أنعم على وحدة المعالجة المركزية الأساسية الثمينة). ولكن كما اكتشفت ، لم يكن هناك أي تسارع موازٍ مهما كان نوعًا ما (بل هو طفيف نجاح) لأن العملية كانت بالكامل IO ملزمة. فرحان ، التفاف إطار الترقية في البرنامج النصي الذي نسخ كل قاعدة بيانات ل /dev/shmوترقيته هناك ، ونسخه مرة أخرى إلى القرص كان أسرع 100 مرة (مع 8 متوازي). كمكافأة ، كان جهاز الكمبيوتر صالحة للاستعمال أيضا ، في حين ترقية قواعد البيانات.

حيث tmpfs المناسب

الاستخدام المناسب لل tmpfs هو تجنب الكتابة غير الضرورية من البيانات المتقلبة. تعطيل فعال رد على الرسالة، مثل الإعداد /proc/sys/vm/dirty_writeback_centisecs إلى ما لا نهاية على نظام ملفات منتظم.

هذا له علاقة قليلة بالأداء ، والفشل في ذلك هو مصدر قلق أصغر بكثير من إساءة استخدام fsync: يحدد مهلة writeback محتوى lazily يتم تحديث محتوى القرص بعد محتوى pagecache ، والفترة الافتراضية من 5 ثوان هو وقت طويل لجهاز كمبيوتر - يمكن للتطبيق أن يقوم بالكتابة فوق الملف على النحو الذي يريده ، في pagecache ، ولكن يتم تحديث المحتوى الموجود على القرص مرة واحدة كل 5 ثوانٍ. ما لم يجبر التطبيق من خلال مع fsync ، وهذا هو. فكر في عدد المرات التي يمكن للتطبيق فيها إخراج ملف صغير في هذا الوقت ، وترى لماذا يكون كل واحد منها مشكلة أكبر بكثير.

ما tmpfs لا يمكن أن تساعدك مع

  • قراءة الأداء. إذا كانت بياناتك ساخنة (وهو أفضل إذا كنت تفكر في الاحتفاظ بها في tmpfs) ، فسوف تضغط على صفحة الذاكرة على أية حال. الفرق هو عندما لا تصل إلى الصفحة pagecache؛ إذا كانت هذه هي الحالة ، انتقل إلى "Where tmpfs sux" ، أدناه.
  • ملفات قصيرة الأجل. هذه يمكن أن يعيشوا حياتهم كلها في pagecache (كما قذر الصفحات) قبل أن يتم كتابتها. مالم تجبره fsync بالطبع بكل تأكيد.

حيث tmpfs سوكس

حفظ البرد البيانات. قد تميل إلى الاعتقاد بأن خدمة الملفات خارج المقايضة هي بنفس كفاءة نظام الملفات العادي ، ولكن هناك سببان لعدم وجودها:

  • أبسط الأسباب: لا يوجد أي شيء أن أجهزة التخزين المعاصرة (سواء كان قرصًا صلبًا أو فلاش) تحب أكثر من قراءة الملفات المتسلسلة إلى حد ما التي ينظمها نظام ملفات مناسب. التبادل في 4KiB كتل من غير المرجح أن تتحسن على ذلك.
  • التكلفة الخفية: مبادلة خارج. صفحات Tmpfs هي قذر - يحتاجون إلى أن يكتبوا في مكان ما (للتبديل) ليتم طردهم من صفحة الصفحات ، بدلاً من الملفات المدعومة نظيف الصفحات التي يمكن إسقاطها على الفور. هذه عقوبة إضافية على كل شيء آخر ينافس على الذاكرة - يؤثر على شيء آخر في وقت مختلف عن استخدام تلك الصفحات tmpfs.

43
2018-01-24 21:20



في بلدي أوبونتو 14.04 / ديف / SHM هو الرابط إلى / تشغيل / SHM ، التي لديها نظام الملفات "لا شيء" وفقا لأمر Df. حجم حوالي 2G ، على الرغم من. - jarno
jarno أولاً ، بتقييم عدد نقاط تثبيت tmpfs ، يمكنني استدعاء تفاصيل التنفيذ. ثانيًا ، لا تدع اسم الجهاز يربك - ابحث في / proc / mounts (هذا هو المكان المناسب للنظر) ، وسترى أن النوع هو "tmpfs" بينما جهاز هو ما هو "لا شيء" هنا. نعم ، اسم الجهاز لا يعني شيئا في tmpfs - يمكنك ذلك mount -t tmpfs "jarno is great" /mnt/jarno إذا تحب! ثالثا ، الحجم الافتراضي هو نصف كمية ذاكرة الوصول العشوائي - أراهن أن لديك 4GiB RAM. - user2394284
هل هناك خيار يخصص حجم ذاكرة الوصول العشوائي ثابت والوعود بعدم استخدام المبادلة؟ - palswim
palswim: سيكون ذلك بمثابة ramdisk. لا أرى خيارًا لذلك في tmpfs، بخلاف أن tmpfs 'السابق لا يدعم التبادل. يمكن لعمليات قفل الصفحات الخاصة بهم في ذاكرة الوصول العشوائي ، والذي هو أقل إثارة للجنون من تأمين صفحات tmpfs في ذاكرة الوصول العشوائي ، مع الأخذ في الاعتبار أن القاتل OOM غير قادر على تحرير هذا الأخير ، إذا نفدت الذاكرة. - user2394284


حسنًا ، إليكم الواقع.

كل من tmpfs ونظام الملفات العادي هي ذاكرة مخبأة عبر القرص.

يستخدم tmpfs الذاكرة و swapspace لأنه يدعم تخزين نظام ملفات يستخدم منطقة محددة من القرص ، ولا يقتصر على الحجم الذي يمكن أن يكون عليه نظام الملفات ، فمن الممكن تماما أن يكون tmpfs 200GB على جهاز مع أقل من غيغابايت من ذاكرة الوصول العشوائي إذا لديك ما يكفي من swapspace.

الفرق في عند كتابة البيانات على القرص. بالنسبة إلى tmpfs ، تتم كتابة البيانات فقط عندما تصبح الذاكرة ممتلئة أو البيانات التي من غير المحتمل استخدامها قريبا. تم تصميم نظام OTOH الأكثر طبيعية لنظام ملفات Linux ليتناسب دائمًا مع مجموعة أكثر تناسقًا من البيانات على القرص ، لذلك إذا قام المستخدم بسحب القابس لا يفقد كل شيء.

أنا شخصياً اعتدت على وجود أنظمة تشغيل لا تتعطل وأنظمة UPS (على سبيل المثال: بطاريات الكمبيوتر المحمول) لذلك أعتقد أن أنظمة الملفات ext2 / 3 مصابة بجنون العظمة مع الفواصل الزمنية 5-10 الثانية. نظام الملفات ext4 أفضل مع نقطة تفتيش 10 دقائق ، إلا أنه يعامل بيانات المستخدم كفئة ثانية ولا يحميها. (ext3 هو نفسه ولكنك لا تلاحظه بسبب نقطة تفتيش ثانية 5)

هذا التدقيق المتكرر يعني أن البيانات غير الضرورية يتم كتابتها باستمرار إلى القرص ، حتى لـ / تمة.

لذا فإن النتيجة هي أنك تحتاج إلى إنشاء مساحة مبادلة كبيرة بقدر ما تحتاج إليه / أن تكون (حتى لو كان عليك إنشاء swapfile) واستخدام تلك المساحة لتركيب tmpfs بالحجم المطلوب على / tmp.

أبدا استخدام / ديف / SHM.

ما لم تكن تستخدمه لملفات IPC صغيرة جدًا (ربما mmap'd) وكنت متأكداً من وجودها (إنها ليست قياسية) ويحتوي الجهاز على أكثر من ذاكرة كافية قابلة للتبديل.


16
2017-12-31 17:03



متفق عليه ، باستثناء الاستنتاج ، "NEVER use / dev / shm". تريد استخدام / dev / shm في الحالات التي لا تريد فيها كتابة ملف على القرص على الإطلاق ، وتريد تصغير القرص i / o. على سبيل المثال ، أحتاج إلى تنزيل ملفات zip كبيرة جدًا من خادم FTP ، وإلغاء ضغطها ، ثم استيرادها إلى قاعدة بيانات. أقوم بفك الضغط إلى / dev / shm حتى لا يحتاج محرك الأقراص الصلبة إلى إجراء نصف العملية فقط بالنسبة لكل من فك الضغط وعمليات الاستيراد ، بدلاً من التنقل ذهابًا وإيابًا بين المصدر والوجهة. إنه يسرع العملية بشكل كبير. هذا مثال واحد للكثيرين ، لكنني أوافق على أنه أداة متخصصة. - Nathan Stretch


استخدم / tmp / للملفات المؤقتة. استخدم / dev / shm / عندما تريد ذاكرة مشتركة (على سبيل المثال ، اتصال interprocess عبر الملفات).

يمكنك الاعتماد على / tmp / أن تكون هناك ، ولكن / dev / shm / هو شيء حديث العهد لينكس حديث نسبياً.


4
2017-09-23 00:03



ليس هناك جانب الأداء كذلك؟ كما يتم تركيبها في معظم الأحيان / dev / shm باعتبارها حجم tmpfs وبشكل أساسي قرص ذاكرة الوصول العشوائي؟ - Deleted
يمكنك أيضًا تركيب / tmp كنظام ملفات tmpfs ، أقوم بذلك على netbook لتسريع بعض الأمور عن طريق تقليل عمليات الكتابة إلى SSD (البطيء). هناك عيوب للقيام بذلك ، بالطبع (بشكل رئيسي استخدام ذاكرة الوصول العشوائي ، ولكن نتبووك لديه ذاكرة الوصول العشوائي أكثر بكثير مما يحتاج عموما على أي حال). - David Spillett
بالنسبة لحالتي الخاصة ، سأستخدمها في نوع من الاتصالات العملية. أقوم بتصوير ناتج الخطأ القياسي من تطبيق ما والتصرف على المحتويات (وما زلت أحتاج إلى الإخراج القياسي دون مساس ، لذلك لا يمكنني القيام بأي 1>/dev/null 2>&1. كنت سأفعل هذا عدة آلاف من المرات حتى تكون tmpfs لطيفة. ومع ذلك ، إذا قمت بنسخ البرنامج النصي ، فلا يمكنني الاعتماد على tmpfs المستخدمة /tmp كما أعتقد أنها ليست شائعة. إذا كان أكثر شيوعًا بالنسبة إلى /dev/shm فهذا أفضل بالنسبة لي. ولكني أبحث عن إرشادات بشأن قابلية النقل وما إلى ذلك. - Deleted


في المرة الأخرى التي يجب عليك فيها استخدام / dev / shm (لنظام Linux 2.6 وما بعده) عندما تحتاج إلى نظام ملفات tmpfs مضمون لأنك لا تعرف ما إذا كنت يستطيع الكتابة إلى القرص.

يحتاج نظام المراقبة الذي أعرفه إلى كتابة الملفات المؤقتة أثناء بناء تقريره لتقديمه إلى خادم مركزي. من المحتمل أكثر من الناحية العملية أن يمنع شيء ما الكتابة إلى نظام الملفات (إما خارج مساحة القرص أو أن فشل RAID الأساسي قد دفع النظام إلى وضع القراءة فقط للأجهزة) ولكنك ستظل قادرًا على الوقوف بجانب التنبيه حول ذلك مما لو كان شيء spirals كل الذاكرة المتوفرة مثل أن tmpfs ستكون غير قابلة للاستخدام (ولن يكون الصندوق ميتًا). في حالات مثل هذا ، سيفضل نظام مراقبة الكتابة إلى ذاكرة الوصول العشوائي (RAM) حتى يتمكن من إرسال تنبيه حول قرص كامل أو جهاز ميت / يحتضر.


1
2017-09-05 22:08





يتم استخدام / dev / shm لبرامج وبرامج الأجهزة الخاصة بنظام الذاكرة الظاهرية المشتركة.

إذا كنت تقوم بإنشاء برنامج يتطلب كومة الذاكرة الظاهرية التي يجب تعيينها إلى الذاكرة الظاهرية. يتضاعف ذلك إذا كنت تحتاج إلى عمليات أو سلاسل عمليات متعددة لتتمكن من الوصول إلى تلك الذاكرة بأمان.

والحقيقة هي أن مجرد استخدام برنامج التشغيل لإصدار خاص من tmpfs له ، لا يعني أنه يجب عليك استخدامه كقسم tmpfs عام. بدلاً من ذلك ، يجب فقط إنشاء قسم tmpfs آخر إذا كنت تريد واحد للدليل المؤقت الخاص بك.


0
2017-10-11 23:22





في PERL ، مع وجود 8GB كحد أدنى على أي جهاز (جميع تشغيل Linux Mint) ، أنا من ما أعتقد أنه عادة جيدة للقيام بخوارزميات معقدة تستند إلى DB_File (بنية البيانات في ملف) مع الملايين من القراءات والكتابة باستخدام / dev / SHM

بلغات أخرى ، دون الحاجة إلى الالتقاط في كل مكان ، لتجنب البدء والتوقف في نقل الشبكة (يعمل محليًا على ملف موجود على خادم في جو عميل-خادم) ، باستخدام ملف دفعي من نوع ما ، سأقوم بنسخ كامل (300-900MB) ملف في آن واحد إلى / dev / shm ، قم بتشغيل البرنامج مع الإخراج إلى / dev / shm ، اكتب النتائج مرة أخرى إلى الخادم ، وحذف من / dev / shm

بطبيعة الحال ، إذا كان لدي عدد أقل من ذاكرة الوصول العشوائي ، فلن أقوم بذلك. عادةً ، يقرأ نظام الملفات في الذاكرة / dev / shm كحجم كونه نصف الذاكرة RAM المتوفرة. ومع ذلك ، الاستخدام العادي للذاكرة العشوائية ثابت. لذلك لا يمكنك فعل هذا على جهاز بسعة 2 غيغابايت أو أقل. لتحويل إعادة الصياغة إلى غلو ، هناك أشياء كثيرة في ذاكرة الوصول العشوائي حتى أن النظام لا يقدم تقارير جيدة.


0
2017-09-27 21:02



(أعتقد أن هذا هو في روح ما سئل في الأصل). ما أعنيه أساسا هو أنني أشعر براحة باستخدام / dev / shm كقرص ذاكرة الوصول العشوائي طالما لدي ذاكرة كافية. إذا كان عدم الكفاءة للقيام بذلك بطريقة أو بأخرى ، لا ينبغي أن يثنيك عن القيام بذلك ، ولكن ينبغي أن يثير سؤال مثل "كيف يمكنني الحصول على قرص ذاكرة الوصول العشوائي على لينكس؟". الجواب هو / dev / shm - David Grove