จำกัด ดิสก์ i / o อย่างไรในระหว่างการสำรองข้อมูล

14

ฉันมี cron ที่ทำง่ายๆ "tar zcf" ในตอนกลางคืน

เซิร์ฟเวอร์มี:

8 Cores - Intel (R) Xeon (R) CPU E5606 @ 2.13GHz
RAM 25GB
Ubuntu 12.04.2 LTS
ฮาร์ดแวร์ RAID 1 (LSI Logic / Symbios Logic MegaRAID SAS SMC2108) พร้อมฮาร์ดไดรฟ์ 2.728TB สองตัว

อย่างที่คุณเห็นบนหน้าจอมอนิเตอร์โฮสต์:

http://clip2net.com/s/57YRKP

ในช่วงเวลาเกือบตลอดระยะเวลาที่ทาร์ดิสก์ I / O ไปที่> 90% และทำให้แอพอื่น ๆ (mysql, apache) ช้าลงมาก

2 คำถาม:

เป็นเรื่องปกติหรือไม่ที่จะมีดิสก์ I / O สูงในระหว่างการสำรองข้อมูล
มีวิธี จำกัด ดิสก์ I / O หรือไม่เพื่อให้แอปอื่นทำงานต่อไปได้อย่างถูกต้อง?

ขอขอบคุณ!

— acemtp
แหล่งที่มา

11

นอกจากแนวทางที่ค่อนข้างทั่วไปioniceแล้วยังมีเป้าหมาย mapper อุปกรณ์ (ioband) ที่ดีซึ่งช่วยให้สามารถควบคุมแบนด์วิดท์ไปยังอุปกรณ์บล็อก (DM) ได้อย่างแม่นยำ น่าเสียดายที่มันไม่ได้เป็นส่วนหนึ่งของเคอร์เนลมาตรฐาน

นอกจากนี้คุณอาจเร่งความเร็วน้ำมันดินโดย

การอ่านชื่อไฟล์ลงในแคชดิสก์: find /source/path -printf ""
การอ่าน inodes ลงในแคชดิสก์: find /source/path -perm 777 -printf ""
การทำให้ tar อ่านและเขียนบล็อกขนาดใหญ่จากและไปยังดิสก์โดยใช้ไพพ์ที่มี mbuffer หรือ buffer (อย่างน้อย 100 MiB of RAM): tar ... | mbuffer -m 256M -P 100 -p 1 ...

— Hauke Laging
แหล่งที่มา

เหตุใดการอ่านชื่อไฟล์ / inodes ลงในแคชจึงทำให้ดิสก์ IO ลดลงในขณะที่รออยู่ ฉันคาดว่าจะเพิ่ม IO โดยเฉลี่ยในขณะที่ลดเวลาทั้งหมดเพียงเล็กน้อย

— scai

3

@scai สิ่งนี้ไม่ช่วย SSD คำแนะนำของฉันหมายถึงการปั่นฮาร์ดดิสเท่านั้น สิ่งที่ทำให้ประสิทธิภาพการทำงานลดลงคือการเคลื่อนไหวของหัว ชื่อไฟล์จะถูกเก็บไว้ในบล็อกต่อเนื่อง inodes จะถูกเก็บไว้ในบล็อกต่อเนื่องและเนื้อหาไฟล์จะถูกเก็บไว้ในบล็อกต่อเนื่อง หากคุณทำตามวิธี tar คุณจะอ่านชื่อไฟล์ (และไดเรกทอรีย่อย) ของไดเรกทอรีเดียวเข้าถึง inode สำหรับหนึ่งไฟล์จากนั้นจึงสร้างไฟล์เองจากนั้นจึงทำการ inode สำหรับไฟล์ถัดไปจากนั้นจะเป็นไฟล์ถัดไป ... นั่น ทำให้เกิดการเคลื่อนไหวที่ศีรษะมากกว่าการอ่านชื่อและ inodes ทั้งหมดหลังจากกัน

— Hauke Laging

@scai ผลกระทบด้านประสิทธิภาพขึ้นอยู่กับสิ่งที่คุณทำ มันค่อนข้างเล็กสำหรับการสำรองข้อมูลเต็มรูปแบบ (อาจขึ้นอยู่กับขนาดไฟล์) แต่ฉันสังเกตเห็นความแตกต่างใหญ่สำหรับการสำรองข้อมูลที่แตกต่างกัน (ไม่ใช่สำหรับ tar แม้ว่าฉันไม่ได้ใช้มัน แต่ควรเป็นลักษณะทั่วไป)

— Hauke Laging

เพียงเพื่อให้แน่ใจว่าฉันเข้าใจถูกต้อง สำหรับ 1. และ 2. เราเพียงแค่เรียกคำสั่ง find และ Linux จะทำการแคชโดยอัตโนมัติ?

— acemtp

@acemtp นั่นถูกต้อง แม้ว่าfindไม่มี (เช่น) -permจะไม่สามารถเข้าถึงไฟล์ inode ได้ แต่นั่นช่วยให้การเพิ่มประสิทธิภาพในการใช้สองfindสาย หากคุณใช้findสายเดียวกันสองครั้ง (โดยมีเวลาน้อยในระหว่างนั้น) สายที่สองมักจะเสร็จสิ้นภายในไม่กี่วินาที (หรือน้อยกว่า) ขึ้นอยู่กับจำนวนหน่วยความจำว่างและปริมาณข้อมูลที่แคช ณ จุดหนึ่งข้อมูลจะถูกโยนออกจากแคช การอ่านมากเกินไปอาจทำให้การทำงานช้าลง หากคุณสามารถป้อนโปรแกรมสำรองข้อมูลด้วยชื่อไฟล์ผ่าน stdin คุณสามารถป้องกันสิ่งนี้ได้โดยการอ่านบล็อกเช่นไฟล์ 100 ไฟล์

— Hauke Laging

13

คาดว่าจะเห็น I / O สูงในระหว่างการสำรองข้อมูลเพราะโดยทั่วไปมักจะทำกับไฟล์ขนาดใหญ่ที่มีไฟล์ขนาดใหญ่ คุณสามารถใช้ioniceเพื่อจัดลำดับความสำคัญของงาน I / O ใน Linux ด้วยคลาสและระดับ IIRC ระดับ 2 ระดับ 7 เป็นระดับต่ำสุดและไม่หิวโหยซึ่งจะทำให้มองไม่เห็นโหลด I / O และผู้ใช้อื่น ๆ ในทางปฏิบัติ ดูman ioniceการใช้งานและรายละเอียด

— bayindirh
แหล่งที่มา

1

ฉันจะแนะนำให้ทิ้ง tar และไปด้วย rsync (ตามที่ได้รับการกล่าวถึงโดย Dogsbody) ฉันใช้ BackupPC เพื่อสำรองไฟล์ในระบบ Windows และ Linux ของฉันและรองรับการใช้ tar เช่นเดียวกับ rsync และดูแลการเชื่อมโยงที่ยากสำหรับคุณโดยอัตโนมัติรวมถึงให้เว็บอินเตอร์เฟสที่ดี

http://backuppc.sourceforge.net/

— Atari911
แหล่งที่มา

0

อย่างที่คนอื่น ๆ ตอบใช่นี่เป็นเรื่องปกติและioniceเป็นวิธีที่ดีโดยทั่วไปที่จะไม่ปล่อยให้มันส่งผลกระทบต่อระบบของคุณ

หลายครั้งที่ฉันเห็นผู้คนรู้สึกtarสับสนเมื่อไม่ต้องการ หากเปอร์เซ็นต์ของข้อมูลที่คุณกำลังคัดลอกไม่ได้เปลี่ยนไปจากการคัดลอกครั้งล่าสุดฉันขอแนะนำให้rsyncลอง

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

หากคุณต้องการคัดลอก / สำรองข้อมูลแยกต่างหากในแต่ละครั้งจะมีการเรียกใช้ตัวเลือกที่มีประสิทธิภาพมากที่สุดคือ –link-dest ซึ่งช่วยให้คุณสามารถลิงก์ไฟล์ที่ไม่มีการเปลี่ยนแปลงไปยังการสำรองข้อมูลก่อนหน้าอย่างหนัก สิ่งนี้ช่วยประหยัดพื้นที่จำนวนมากบนเซิร์ฟเวอร์สำรอง เช่นฉันสำรองข้อมูลเครื่อง (Fred) Fred มี 20GB HD และฉันสำรอง / คัดลอกไดรฟ์ทั้งหมดยกเว้น / proc และ / dev ตอนนี้ฉันมีไดเรกทอรี 20GB บนเซิร์ฟเวอร์สำรองของฉัน ในวันถัดไปฉันทำการสำรองข้อมูล Fred อีกครั้งและ - เชื่อมโยง-dest ไปยังการสำรองข้อมูลเมื่อวาน Rsync เปรียบเทียบไฟล์รีโมตกับสำเนาโลคัลและหากเหมือนกันจะไม่รบกวนการถ่ายโอน แต่จะฮาร์ดลิงก์ไฟล์ใหม่ไปยังไฟล์ yesterdays ไฟล์ใด ๆ ที่มีการเปลี่ยนแปลงจะถูกคัดลอกใหม่ (หรือคัดลอกบางส่วนโดยใช้การสำรองข้อมูลเมื่อวานถ้าเป็นไปได้) หากไฟล์มีการเปลี่ยนแปลงเพียง 100MB ตั้งแต่เมื่อวานตอนนี้ฉันมีสองไดเรกทอรีทั้งที่มี 20GB ไฟล์ แต่รับได้เพียง 20 เท่านั้น

ฉันหวังว่าจะช่วยและยังตอบคำถามของคุณ

— Dogsbody
แหล่งที่มา