เมื่อใดที่ฉันควรใช้ / dev / shm / และเมื่อใดที่ฉันควรใช้ / tmp /

ฉันควรใช้/dev/shm/เมื่อใดและควรใช้เมื่อ/tmp/ใด ฉันสามารถพึ่งพาพวกเขาได้ตลอดเวลาหรือไม่?

/dev/shmเป็นระบบไฟล์ที่จัดเก็บไฟล์ชั่วคราวเช่นtmpfsที่ใช้ RAM สำหรับที่เก็บข้อมูลสำรอง มันสามารถทำงานเป็นการใช้งานหน่วยความจำร่วมที่อำนวยความสะดวกIPC

จาก Wikipedia :

เคอร์เนล Linux ล่าสุด 2.6 บิวด์ได้เริ่มเสนอ / dev / shm เป็นหน่วยความจำแบบแบ่งใช้ในรูปแบบของ ramdisk โดยเฉพาะอย่างยิ่งเป็นไดเรกทอรีที่เขียนได้ทั่วโลกซึ่งเก็บไว้ในหน่วยความจำโดยมีขีด จำกัด ที่กำหนดไว้ใน / etc / default / tmpfs  การสนับสนุน / dev / shm เป็นทางเลือกที่สมบูรณ์ภายในไฟล์เคอร์เนล config   มันรวมอยู่ในค่าเริ่มต้นทั้งใน Fedora และ Ubuntu ดิสทริบิวชั่นที่ซึ่งมันถูกใช้อย่างกว้างขวางที่สุดโดยแอพพลิเคชั่น Pulseaudio             ^{(เพิ่มการเน้น)}

/tmpเป็นตำแหน่งสำหรับไฟล์ชั่วคราวตามที่กำหนดไว้ในFilesystem Hierarchy Standardซึ่งตามด้วยการแจกแจง Unix และ Linux เกือบทั้งหมด

เนื่องจาก RAM เร็วกว่าที่เก็บข้อมูลดิสก์คุณจึงสามารถใช้/dev/shmแทน/tmpการเพิ่มประสิทธิภาพได้หากกระบวนการของคุณคือ I / O อย่างเข้มข้นและใช้ไฟล์ชั่วคราวอย่างกว้างขวาง

เพื่อตอบคำถามของคุณ: ไม่คุณไม่สามารถพึ่งพาได้เสมอ/dev/shmไม่ได้อยู่บนเครื่องที่มัดไว้กับหน่วยความจำ คุณควรใช้จนกว่าคุณจะมีเหตุผลที่ดีมากสำหรับการใช้/tmp/dev/shm

โปรดจำไว้ว่า/tmpสามารถเป็นส่วนหนึ่งของ/ระบบไฟล์แทนการติดตั้งแยกต่างหากและสามารถเติบโตได้ตามต้องการ ขนาดของ/dev/shmถูก จำกัด โดย RAM ส่วนเกินในระบบและด้วยเหตุนี้คุณมีแนวโน้มที่จะมีพื้นที่ว่างในระบบไฟล์นี้

ในลำดับถัดลงมาของtmpfsโอกาส:

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

เนื่องจากคุณถามเกี่ยวกับจุดเมานต์tmpfsเฉพาะ Linux กับไดเรกทอรีที่กำหนดพอร์ตได้ซึ่งอาจเป็น tmpfs (ขึ้นอยู่กับระบบดูแลระบบของคุณและสิ่งที่เป็นค่าเริ่มต้นสำหรับ distro ของคุณ) คำถามของคุณมีสองด้านซึ่งคำตอบอื่น ๆ

1. เมื่อใดควรใช้ไดเรกทอรีเหล่านี้ตามแนวปฏิบัติที่ดี
2. เมื่อมีความเหมาะสมที่จะใช้ tmpfs

แนวปฏิบัติที่ดี

รุ่นอนุรักษ์นิยม (ส่วนผสมของอนุสัญญาจากFHSและการใช้งานทั่วไป):

• /tmpเมื่อสงสัยใช้
• ใช้/var/tmpสำหรับข้อมูลขนาดใหญ่ที่อาจไม่เหมาะกับแรม
• ใช้/var/tmpสำหรับข้อมูลที่มีประโยชน์ในการป้องกันการรีบูต (เช่นแคช)
• ใช้เป็นผลข้างเคียงของการโทร/dev/shm shm_open()ผู้ชมเป้าหมายคือบัฟเฟอร์ที่ล้อมรอบซึ่งจะถูกเขียนทับไม่รู้จบ ดังนั้นนี่เป็นไฟล์ที่มีอายุการใช้งานยาวนานซึ่งเนื้อหามีความผันผวนและไม่ใหญ่มาก
• หากยังมีข้อสงสัยให้เตรียมวิธีสำหรับผู้ใช้ในการแทนที่ ตัวอย่างเช่นmktempโปรแกรมให้เกียรติTMPDIRตัวแปรสภาพแวดล้อม

ในทางปฏิบัติรุ่น:

ใช้/dev/shmเมื่อมันเป็นสิ่งสำคัญที่จะใช้ tmpfs, เมื่อมันเป็นสิ่งสำคัญที่จะไม่อื่น/var/tmp/tmp

ที่ tmpfs เก่ง

fsyncเป็น no-op บน tmpfs syscall นี้เป็นศัตรูอันดับหนึ่งของประสิทธิภาพ (IO) (และอายุการใช้งานแฟลชยาวนานหากคุณใส่ใจ) แม้ว่าคุณจะพบว่าตัวเองใช้ tmpfs (หรือeatmydata)) เพียงเพื่อกำจัด fsync จากนั้นคุณ (หรือผู้พัฒนารายอื่นในเครือ) กำลังทำสิ่งผิดปกติ หมายความว่าธุรกรรมที่มีต่ออุปกรณ์จัดเก็บข้อมูลนั้นไม่จำเป็นสำหรับคุณ - คุณยินดีที่จะข้ามจุดเก็บข้อมูลเพื่อประสิทธิภาพขณะที่คุณไปสู่การก่อวินาศกรรมมากที่สุด นอกจากนี้ยังมีการทำธุรกรรมที่นี่ซึ่งประโยชน์ที่ยิ่งใหญ่ที่สุดของการมี SSD คือ SSD ที่ดีจะทำงานได้นอกโลกนี้เมื่อเทียบกับดิสก์หมุนได้ (7200 rpm = 120 Hz หากไม่ได้รับการเข้าถึงอย่างอื่น) ไม่ต้องพูดถึงการ์ดหน่วยความจำแฟลชซึ่งแตกต่างกันอย่างกว้างขวางในตัวชี้วัดนี้ (ไม่น้อยเพราะมันเป็นการแลกเปลี่ยนที่มีประสิทธิภาพตามลำดับซึ่งเป็นสิ่งที่พวกเขาได้รับการจัดอันดับโดย ดังนั้นจงระวัง

อยากได้ยินเรื่องราวไร้สาระไหม? fsyncบทเรียนแรกของฉัน: ฉันมีงานที่เกี่ยวข้องกับการ "อัปเกรด" ฐานข้อมูล Sqlite จำนวนมาก (เก็บไว้เป็นแบบทดสอบ) เป็นรูปแบบปัจจุบันที่เปลี่ยนแปลงตลอดเวลา เฟรมเวิร์ก "อัปเกรด" จะเรียกใช้สคริปต์หลาย ๆ รายการโดยทำธุรกรรมอย่างน้อยหนึ่งรายการเพื่ออัปเกรดฐานข้อมูลเดียว แน่นอนฉันอัพเกรดฐานข้อมูลของฉันแบบขนาน (8 ในแบบคู่ขนานตั้งแต่ฉันได้รับความสุขกับ 8 core CPU อันยิ่งใหญ่) แต่ตามที่ฉันค้นพบไม่มีการเร่งความเร็วแบบขนานใด ๆ (ค่อนข้างตีเล็กน้อย) เพราะกระบวนการนี้ถูกผูกไว้กับ IO ทั้งหมด อย่างสนุกสนานการห่อเฟรมเวิร์กการอัปเกรดในสคริปต์ที่คัดลอกแต่ละฐานข้อมูลไปยัง/dev/shmอัปเกรดที่นั่นและคัดลอกกลับไปยังดิสก์นั้นเร็วกว่า 100 เท่า (ยังคงมี 8 แบบขนาน) เป็นโบนัสพีซีใช้งานได้ ในขณะเดียวกันก็ทำการอัพเกรดฐานข้อมูล

ที่ tmpfs เหมาะสม

การใช้ tmpfs ที่เหมาะสมคือหลีกเลี่ยงการเขียนข้อมูลที่ไม่จำเป็น ได้อย่างมีประสิทธิภาพการปิดใช้งานwritebackเช่นการตั้งค่า/proc/sys/vm/dirty_writeback_centisecsอินฟินิตี้ในระบบแฟ้มปกติ

สิ่งนี้มีน้อยมากเกี่ยวกับประสิทธิภาพการทำงานและความล้มเหลวนี้เป็นสิ่งที่กังวลน้อยกว่าการใช้ fsync ในทางที่ผิด: การหมดเวลาการเขียนกลับกำหนดว่าเนื้อหาของดิสก์จะอัปเดตอย่างขี้เกียจหลังจากเนื้อหา pagecache และค่าเริ่มต้น 5 วินาทีเป็นเวลานานสำหรับคอมพิวเตอร์ - แอปพลิเคชันสามารถเขียนทับไฟล์ได้บ่อยเท่าที่ต้องการใน pagecache แต่เนื้อหาบนดิสก์จะได้รับการอัปเดตทุกๆ 5 วินาทีเท่านั้น ยกเว้นว่าแอปพลิเคชันบังคับให้ผ่านด้วย fsync นั่นคือ ลองคิดดูว่าแอปพลิเคชั่นสามารถส่งออกไฟล์ขนาดเล็กได้กี่ครั้งในเวลานี้และคุณจะเห็นว่าทำไมการซิงโครไนซ์ทุกครั้งจึงเป็นปัญหาที่ใหญ่กว่ามาก

tmpfs ใดที่ไม่สามารถช่วยคุณได้

• อ่านประสิทธิภาพ หากข้อมูลของคุณร้อน (ซึ่งควรจะเป็นถ้าคุณพิจารณาเก็บไว้ใน tmpfs) คุณจะตี pagecache ต่อไป ความแตกต่างคือเมื่อไม่ได้ตี pagecache; หากเป็นกรณีนี้ให้ไปที่ "Where tmpfs sux" ด้านล่าง
• ไฟล์มีอายุสั้น สิ่งเหล่านี้สามารถใช้ชีวิตทั้งชีวิตได้ในหน้ากระดาษ (เป็นหน้าสกปรก ) ก่อนที่จะถูกเขียนออกมา นอกเสียจากคุณจะบังคับด้วยfsyncแน่นอน

ที่ tmpfs sux

การเก็บข้อมูลเย็น คุณอาจถูกล่อลวงให้คิดว่าการแสดงไฟล์จากการแลกเปลี่ยนนั้นมีประสิทธิภาพเทียบเท่ากับระบบไฟล์ปกติ แต่มีเหตุผลสองประการที่ทำให้มันไม่:

• เหตุผลที่ง่ายที่สุด: ไม่มีสิ่งใดที่อุปกรณ์จัดเก็บข้อมูลร่วมสมัย (ไม่ว่าจะเป็นฮาร์ดดิสก์หรือแฟลช) รักมากกว่าการอ่านไฟล์ที่ต่อเนื่องกันอย่างเป็นระเบียบโดยระบบไฟล์ที่เหมาะสม การสลับในบล็อก 4KiB นั้นไม่น่าจะดีขึ้น
• ค่าใช้จ่ายที่ซ่อนอยู่: สลับออก หน้า tmpfs มีความสกปรก - พวกเขาจะต้องเขียนที่ไหนสักแห่ง (เพื่อแลกเปลี่ยน) ที่จะขับไล่ออกจาก pagecache เมื่อเทียบกับไฟล์ได้รับการสนับสนุนการทำความสะอาดหน้าเว็บที่สามารถลดลงได้ทันที นี่เป็นบทลงโทษพิเศษในทุกสิ่งที่แข่งขันเพื่อความจำ - ส่งผลกระทบต่อสิ่งอื่นในเวลาที่แตกต่างจากการใช้หน้า tmpfs เหล่านั้น

โอเคนี่คือความจริง

ทั้ง tmpfs และระบบไฟล์ปกติเป็นแคชหน่วยความจำบนดิสก์

tmpfs ใช้หน่วยความจำและ swapspace เนื่องจากเป็นระบบสำรองเก็บระบบไฟล์ใช้พื้นที่เฉพาะของดิสก์ไม่ จำกัด ขนาดที่ระบบไฟล์สามารถทำได้มีความเป็นไปได้ที่จะมี 200GB tmpfs บนเครื่องที่มีหน่วยความจำน้อยกว่า GB คุณมี swapspace เพียงพอ

ความแตกต่างเกิดขึ้นเมื่อข้อมูลถูกเขียนลงดิสก์ สำหรับ tmpfs ข้อมูลจะถูกเขียนขึ้นเฉพาะเมื่อหน่วยความจำเต็มเกินไปหรือข้อมูลที่ไม่น่าจะใช้ในไม่ช้า OTOH ระบบไฟล์ Linux ทั่วไปส่วนใหญ่ได้รับการออกแบบให้มีชุดข้อมูลบนดิสก์ที่สอดคล้องกันมากขึ้นหรือน้อยลงดังนั้นหากผู้ใช้ดึงปลั๊กพวกเขาจะไม่สูญเสียทุกสิ่ง

โดยส่วนตัวฉันเคยมีระบบปฏิบัติการที่ไม่ผิดพลาดและระบบ UPS (เช่นแบตเตอรี่แล็ปท็อป) ดังนั้นฉันคิดว่าระบบไฟล์ ext2 / 3 นั้นหวาดระแวงเกินไปกับช่วงเวลาเช็คอิน 5-10 วินาที ระบบไฟล์ ext4 นั้นดีกว่าด้วยจุดตรวจสอบ 10 นาทียกเว้นว่าจะถือว่าข้อมูลของผู้ใช้เป็นคลาสที่สองและไม่ได้ป้องกันไว้ (ext3 เหมือนกัน แต่คุณไม่สังเกตเห็นเพราะด่าน 5 วินาที)

จุดตรวจที่บ่อยครั้งนี้หมายความว่าข้อมูลที่ไม่จำเป็นจะถูกเขียนลงดิสก์อย่างต่อเนื่องแม้แต่ / tmp

ดังนั้นผลลัพธ์คือคุณต้องสร้างพื้นที่สว็อปให้ใหญ่ที่สุดเท่าที่คุณต้องการ / tmp ของคุณ (แม้ว่าคุณจะต้องสร้าง swapfile) และใช้พื้นที่นั้นเพื่อเมานต์ tmpfs ที่มีขนาดที่ต้องการลงบน / tmp

ไม่เคยใช้ / dev / shm

ยกเว้นว่าคุณกำลังใช้ไฟล์เหล่านี้สำหรับไฟล์ IPC ขนาดเล็กมาก (อาจเป็น mmap'd) และคุณแน่ใจว่ามีอยู่ (ไม่ใช่มาตรฐาน) และเครื่องมีหน่วยความจำ + สว็อปเพียงพอ

ใช้ / tmp / สำหรับไฟล์ชั่วคราว ใช้ / dev / shm / เมื่อคุณต้องการหน่วยความจำที่ใช้ร่วมกัน (เช่นการสื่อสารระหว่างกระบวนการผ่านไฟล์)

คุณสามารถพึ่งพา / tmp / การอยู่ที่นั่นได้ แต่ / dev / shm / เป็น Linux ล่าสุด

อีกครั้งเมื่อคุณควรใช้ / dev / shm (สำหรับ Linux 2.6 ขึ้นไป) คือเมื่อคุณต้องการระบบไฟล์ tmpfs ที่รับประกันเพราะคุณไม่ทราบว่าคุณสามารถเขียนลงดิสก์ได้หรือไม่

ระบบการตรวจสอบที่ฉันคุ้นเคยกับความต้องการในการเขียนไฟล์ชั่วคราวในขณะที่สร้างรายงานเพื่อส่งไปยังเซิร์ฟเวอร์กลาง ในทางปฏิบัติมีความเป็นไปได้มากกว่าที่บางสิ่งจะป้องกันการเขียนลงในระบบไฟล์ (ไม่ว่าที่ว่างบนดิสก์หรือความล้มเหลวของ RAID พื้นฐานทำให้ระบบเข้าสู่โหมดฮาร์ดแวร์แบบอ่านอย่างเดียว) แต่คุณจะยังคงกระวนกระวาย เกี่ยวกับมันมากกว่าถ้าบางสิ่งบางอย่างวนรอบหน่วยความจำที่มีอยู่ทั้งหมดเช่นนั้น tmpfs จะใช้ไม่ได้ (และกล่องจะไม่ตาย) ในกรณีเช่นนี้ระบบการตรวจสอบจะต้องการเขียนออกไปยัง RAM เพื่อที่จะสามารถส่งการแจ้งเตือนเกี่ยวกับดิสก์เต็มหรือฮาร์ดแวร์ตาย / ตาย

/ dev / shm ใช้สำหรับไดรเวอร์อุปกรณ์และโปรแกรมเฉพาะระบบหน่วยความจำเสมือนที่ใช้ร่วมกัน

หากคุณกำลังสร้างโปรแกรมที่ต้องการฮีปหน่วยความจำเสมือนที่ควรแมปกับหน่วยความจำเสมือน สิ่งนี้จะเพิ่มเป็นสองเท่าดังนั้นหากคุณต้องการกระบวนการหรือเธรดจำนวนมากเพื่อให้สามารถเข้าถึงหน่วยความจำนั้นได้อย่างปลอดภัย

ความจริงก็คือเพียงเพราะไดรเวอร์ใช้เวอร์ชันพิเศษของ tmpfs ไม่ได้หมายความว่าคุณควรใช้มันเป็นพาร์ติชัน tmpfs ทั่วไป แต่คุณควรสร้างพาร์ติชัน tmpfs ใหม่หากคุณต้องการพาร์ติชันหนึ่งสำหรับไดเรกทอรีชั่วคราว

ใน PERL มีขั้นต่ำ 8GB บนเครื่องใด ๆ (ใช้ Linux Mint ทั้งหมด) ฉันเป็นสิ่งที่ฉันคิดว่าเป็นนิสัยที่ดีในการทำ DB_File-based (โครงสร้างข้อมูลในไฟล์) อัลกอริทึมที่ซับซ้อนด้วยการอ่านและเขียนนับล้านโดยใช้ / dev / SHM

ในภาษาอื่น ๆ ที่ไม่มี gigether ทุกที่เพื่อหลีกเลี่ยงการเริ่มต้นและหยุดในการถ่ายโอนเครือข่าย (ทำงานภายในไฟล์ที่ตั้งอยู่บนเซิร์ฟเวอร์ในบรรยากาศของไคลเอนต์ - เซิร์ฟเวอร์) โดยใช้แบทช์ไฟล์บางประเภทฉันจะคัดลอก ไฟล์ทั้งหมด (300-900MB) ในครั้งเดียวเพื่อ / dev / shm เรียกใช้โปรแกรมด้วยเอาต์พุตไปยัง / dev / shm เขียนผลลัพธ์กลับไปที่เซิร์ฟเวอร์และลบจาก / dev / shm

โดยธรรมชาติถ้าฉันมี RAM น้อยกว่าฉันจะไม่ทำเช่นนี้ ตามปกติแล้วระบบไฟล์ในหน่วยความจำของ / dev / shm จะอ่านว่ามีขนาดเท่ากับครึ่งหนึ่งของ RAM ที่มีอยู่ของคุณ อย่างไรก็ตามการใช้ RAM ปกติจะคงที่ ดังนั้นคุณจึงไม่สามารถทำได้บนอุปกรณ์ที่มี 2GB หรือน้อยกว่า ในการเปลี่ยน paraphrase ไปเป็นอติพจน์มันมักจะมีสิ่งต่าง ๆ ใน RAM ที่แม้แต่ระบบก็ยังไม่รายงานที่ดี