เหตุใดระบบไฟล์ XFS ของฉันจึงใช้พื้นที่มากขึ้นและเต็มไปด้วยไฟล์ที่กระจัดกระจาย

ฉันใช้ระบบไฟล์ XFSเป็นพาร์ติชั่นข้อมูล / การเติบโตเกือบ 10 ปีในเซิร์ฟเวอร์ Linux ต่างๆ

ฉันสังเกตเห็นปรากฏการณ์แปลก ๆ กับเซิร์ฟเวอร์ CentOS / RHEL ล่าสุดที่ใช้งานเวอร์ชัน 6.2+

การใช้ระบบไฟล์ที่เสถียรกลายเป็นตัวแปรสูงหลังจากย้ายไปยังการแก้ไขระบบปฏิบัติการรุ่นใหม่จาก EL6.0 และ EL6.1 ระบบที่ติดตั้งในตอนแรกพร้อมกับ EL6.2 + มีพฤติกรรมเหมือนกัน แสดงการแกว่งแบบไวด์ในการใช้งานดิสก์บนพาร์ติชัน XFS (ดูบรรทัดสีน้ำเงินในกราฟด้านล่าง)

ก่อนและหลัง. การอัปเกรดจาก 6.1 เป็น 6.2 เกิดขึ้นในวันเสาร์

กราฟการใช้ดิสก์ของไตรมาสที่ผ่านมาของระบบเดียวกันซึ่งแสดงความผันผวนในสัปดาห์ที่ผ่านมา

ฉันเริ่มตรวจสอบระบบไฟล์สำหรับไฟล์ขนาดใหญ่และกระบวนการที่ควบคุมไม่ได้ (ล็อกไฟล์อาจ?) ผมค้นพบว่าไฟล์ที่ใหญ่ที่สุดของฉันถูกรายงานค่าที่แตกต่างจากและdu lsการรันduด้วยและไม่มี--apparent-sizeสวิตช์แสดงให้เห็นถึงความแตกต่าง

# du -skh SOD0005.TXT
29G     SOD0005.TXT

# du -skh --apparent-size SOD0005.TXT
21G     SOD0005.TXT

การตรวจสอบอย่างรวดเร็วโดยใช้ยูทิลิตี ncduในระบบไฟล์ทั้งหมดให้ผล:

Total disk usage: 436.8GiB  Apparent size: 365.2GiB  Items: 863258

ระบบไฟล์เต็มไปด้วยไฟล์กระจัดกระจายที่มีพื้นที่สูญหายเกือบ 70GB เมื่อเทียบกับ OS / kernel รุ่นก่อนหน้า!

ฉันอ่านผ่านRed Hat Bugzillaและเปลี่ยนบันทึกเพื่อดูว่ามีการรายงานพฤติกรรมที่เหมือนกันหรือประกาศใหม่เกี่ยวกับ XFS หรือไม่

Nada

ฉันไปจากเคอร์เนลรุ่น2.6.32-131.17.1.el6ถึง2.6.32-220.23.1.el6ในระหว่างการอัพเกรด; ไม่มีการเปลี่ยนแปลงในหมายเลขรุ่นรอง

ฉันตรวจสอบการแตกไฟล์ด้วยfilefragเครื่องมือ ไฟล์ที่ใหญ่ที่สุดบางส่วนในพาร์ติชัน XFS มีหลายพันรายการ การใช้งาน Defrag ออนไลน์xfs_fsr -vในช่วงที่มีกิจกรรมช้าจะช่วยลดการใช้ดิสก์ได้ชั่วคราว (ดูวันพุธในกราฟแรกด้านบน) อย่างไรก็ตามการใช้งานถูกเพิ่มบอลลูนทันทีที่กิจกรรมของระบบกลับสู่การทำงานหนัก

เกิดอะไรขึ้นที่นี่

ฉันตรวจสอบปัญหานี้กลับไปที่การสนทนาเกี่ยวกับการยอมรับต้นไม้ต้นกำเนิด XFSตั้งแต่เดือนธันวาคม 2010 แพทช์ถูกนำมาใช้ในเคอร์เนล 2.6.38 (และเห็นได้ชัดหลังจากนั้นย้อนกลับเข้าไปในเมล็ดกระจาย Linux ยอดนิยมบางส่วน)

ความผันผวนที่สังเกตได้จากการใช้งานดิสก์เป็นผลมาจากคุณสมบัติใหม่ XFS แบบไดนามิกเก็งกำไร EOF preallocation

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

เป็นไปตามกำหนดการนี้:

freespace       max prealloc size
  >5%             full extent (8GB)
  4-5%             2GB (8GB >> 2)
  3-4%             1GB (8GB >> 3)
  2-3%           512MB (8GB >> 4)
  1-2%           256MB (8GB >> 5)
  <1%            128MB (8GB >> 6)

นี่เป็นส่วนเสริมที่น่าสนใจของระบบไฟล์เนื่องจากมันอาจช่วยไฟล์ที่มีการแตกไฟล์ขนาดใหญ่ที่ฉันจัดการได้

พื้นที่เพิ่มเติมสามารถเรียกคืนได้ชั่วคราวโดยการปลดปล่อย pagecache, dentries และ inodes ด้วย:

sync; echo 3 > /proc/sys/vm/drop_caches

คุณลักษณะนี้สามารถปิดใช้งานได้อย่างสมบูรณ์โดยการกำหนดallocsizeค่าระหว่างการเมานต์ระบบไฟล์ ค่าเริ่มต้นสำหรับ XFS allocsize=64kคือ

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

ทั้งหมดในทุกมันจับฉันออกยามเพราะไม่มีประกาศที่ชัดเจนของการเปลี่ยนแปลงระบบแฟ้มในระดับการจัดจำหน่ายหรือแม้กระทั่งในการตรวจสอบXFS รายชื่อผู้รับจดหมาย

แก้ไข :
ประสิทธิภาพของโวลุ่ม XFS ด้วยคุณสมบัตินี้ได้รับการปรับปรุงอย่างมาก ฉันเห็นการกระจายตัวของ <1% ที่สอดคล้องกันของไดรฟ์ข้อมูลที่ก่อนหน้านี้แสดงได้ถึง 50% ประสิทธิภาพการเขียนขึ้นทั่วโลก!

สถิติจากชุดข้อมูลเดียวกันการเปรียบเทียบ XFS รุ่นเก่ากับรุ่นใน EL6.3

เก่า:

# xfs_db -r -c frag /dev/cciss/c0d0p9
actual 1874760, ideal 1256876, fragmentation factor 32.96%

ใหม่:

# xfs_db -r -c frag /dev/sdb1
actual 1201423, ideal 1190967, fragmentation factor 0.87%