วิธีทำให้ rm` เร็วขึ้นบน ext3 / linux


32

ฉันติดตั้งระบบไฟล์ ext3 ด้วยตัวเลือกเริ่มต้น ในนั้นฉันมีไฟล์ ~ 100GB

การลบไฟล์ใด ๆ ดังกล่าวใช้เวลานาน (8 นาที) และทำให้เกิดการรับส่งข้อมูล io จำนวนมากซึ่งจะเป็นการเพิ่มภาระให้กับเซิร์ฟเวอร์

มีวิธีใดที่จะทำให้ rm ไม่ได้ก่อกวนหรือไม่?


4
โดยทั่วไปไม่มีวิธีการทำงานจากที่นี่ดังนั้นเราจึงพัฒนาของเราเอง อธิบายไว้ในที่นี่: depesz.com/index.php/2010/04/04/how-to-remove-backups

คำตอบ:


14

คำตอบที่น่าสนใจที่สุดนั้นถูกฝังอยู่ในความคิดเห็นของคำถาม นี่เป็นคำตอบที่ดีที่สุดเพื่อให้มองเห็นได้ชัดเจนยิ่งขึ้น:

โดยทั่วไปไม่มีวิธีการทำงานจากที่นี่ดังนั้นเราจึงพัฒนาของเราเอง อธิบายไว้ในที่นี่: http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ - depesz 6 เม.ย. 53 เวลา 15:15 น.

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

หมายเหตุด้วย:

บทความพูดว่า:

อย่างที่คุณเห็นฉันใช้-c2 -n7ตัวเลือกกับอิออนซึ่งดูเหมือนมีเหตุผล

ซึ่งเป็นความจริง แต่ผู้ใช้ TafT บอกว่าถ้าคุณไม่ต้องการการหยุดชะงัก-c3'ว่าง' จะเป็นตัวเลือกที่ดีกว่า-c2'ดีที่สุด - ความพยายาม' เขาเคย-c3สร้างในพื้นหลังและพบว่ามันทำงานได้ดีโดยไม่ทำให้การสร้างต้องรอตลอดไป หากคุณมีการใช้งาน io จริง 100% -c3จะไม่ทำให้การลบเสร็จสมบูรณ์ แต่เขาไม่คาดหวังว่าเป็นสิ่งที่คุณได้จากการทดสอบที่ทำงาน


18

อัพเกรดเป็น ext4 หรือระบบไฟล์ที่ทันสมัยอื่น ๆ ที่ใช้ extents เนื่องจาก ext3 ใช้รูปแบบบล็อกทางอ้อมแทนที่จะเป็นส่วนขยายการลบไฟล์ขนาดใหญ่ย่อมส่งผลให้เกิดงานจำนวนมากอย่างหลีกเลี่ยงไม่ได้



4

ในแง่ของประสิทธิภาพการใช้หนึ่ง rm ต่อไฟล์ไม่เหมาะสมเนื่องจากต้องใช้ fork และ exec สำหรับแต่ละ rm

สมมติว่าคุณมี list.txt ที่มีไฟล์ที่คุณต้องการลบสิ่งนี้จะมีประสิทธิภาพมากกว่า แต่ก็ยังช้าอยู่:

xargs -i rm {} < list.txt

อีกวิธีคือ: nice -20 xargs -i rm {} < list.txt
(ใช้เวลาน้อยลง แต่จะส่งผลต่อระบบของคุณอย่างมาก :)

หรือ

ฉันไม่รู้ว่ามันจะเร็วแค่ไหน แต่:

mv <file-name> /dev/null 

หรือ

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

หรือ

cat /dev/null > /file/to/be/deleted(ตอนนี้มันจะมีขนาดเป็นศูนย์) และถ้าคุณต้องการให้มันหายไปrm -rf <file>ตอนนี้

หรือดีกว่า

วางแมวและทำ # > /file/to/be/emptied


ฉันกำลังลบ1ไฟล์ดังนั้นจึงไม่มีค่าใช้จ่าย

stackoverflow.com/questions/1795370/… - ตรวจสอบด้วย

1

ฉันมีปัญหาในการทำให้ไดเรคทอรีทำการลบอย่างเหมาะสมกลับกลายเป็นว่ากระบวนการล็อกดิสก์และสร้างกระบวนการจำนวนหนึ่งที่พยายามเข้าถึงดิสก์ ionice ไม่ทำงานมันแค่ใช้ 99% ของดิสก์ IO และล็อคกระบวนการอื่นทั้งหมดออก

นี่คือรหัส Python ที่เหมาะกับฉัน มันลบไฟล์ 500 ครั้งต่อครั้งจากนั้นใช้เวลาพัก 2 วินาทีเพื่อให้กระบวนการอื่นทำงานได้ ใช้งานได้ดี

import os, os.path
import time

for root, dirs, files in os.walk('/dir/to/delete/files'):
    file_num = 0
    for f in files:
        fullpath = os.path.join(root, f)
        os.remove(fullpath)
        if file_num%500 == 1:
            time.sleep(2)
            print "Deleted %i files" % file_num
        file_num = file_num + 1

1
ลองใช้กับไฟล์ 100G + บนระบบไฟล์ ext3 ปัญหาคือขนาดไฟล์เดียวไม่ใช่จำนวนไฟล์

ในกรณีของคุณดูเหมือนว่าจะไม่ทำงาน แต่ฉันมีไฟล์ขนาดเล็กมากมาย ขอบคุณสำหรับความคิดเห็น.
Nick Woodhams

1

สองเซ็นต์ของฉัน

ฉันได้รับปัญหานี้แล้ว "ในสคริปต์ต่อเนื่องที่ต้องทำงานอย่างรวดเร็วกระบวนการจะลบไฟล์จำนวนมาก" .. ดังนั้น "rm" จะทำให้ความเร็วสคริปต์นั้นใกล้เคียงกับเวลารอของ IO / exec

ดังนั้นเพื่อให้สิ่งที่รวดเร็วฉันได้เพิ่มกระบวนการอื่น (สคริปต์ทุบตี) เปิดตัวต่อ cron .. เช่นตัวรวบรวมขยะจะลบไฟล์ทั้งหมดในไดเรกทอรีเฉพาะ

จากนั้นฉันได้อัปเดตสคริปต์ต้นฉบับโดยแทนที่ "rm" โดย mv เป็น "โฟลเดอร์ขยะ" (เปลี่ยนชื่อไฟล์โดยเพิ่มตัวนับที่ท้ายชื่อเพื่อหลีกเลี่ยงการชนกัน)

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

หวังว่าจะช่วย ..


0

นอกจากนี้ยังทราบว่าคำตอบโดยเดนนิสวิลเลียมสันที่แสดงให้เห็นioniceเป็นวิธีแก้ปัญหาสำหรับโหลดจะทำงานเฉพาะในกรณีที่อุปกรณ์ป้องกันของคุณใช้ CFQ io กำหนดการ


0

คุณสามารถลองสร้างระบบไฟล์วนซ้ำเพื่อจัดเก็บข้อมูลสำรองของคุณไว้

# dd if=/dev/zero of=/path/to/virtualfs bs=100M count=1024 # 100 MB * 1024 = 100 GB
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

จากนั้นเมื่อคุณต้องการลบข้อมูลสำรองออก:

# umount /mnt/backups
# mke2fs /path/to/virtualfs
# mount -t ext2 /path/to/virtualfs /mnt/backups -o loop

โอมเพี้ยง! ระบบไฟล์เสมือนทั้งหมดจะถูกล้างออกในเวลาไม่นาน


ไม่ได้แก้ปัญหาเพราะมันจะทำงานเฉพาะในกรณีที่ฉันต้องการลบการสำรองข้อมูลทั้งหมดในระบบไฟล์ที่กำหนด

0

คุณสามารถใช้มัลติเธรดที่มี xargs

find . -type f | xargs -P 30 rm -rf 

โดยที่ 30 คือจำนวนเธรดที่คุณต้องการสร้าง หากคุณใช้ศูนย์ระบบจะสร้างเธรดสูงสุดที่ผู้ใช้ดำเนินงาน


1
findมี-deleteตัวเลือกซึ่งเป็นทางเลือกที่ดีกว่ามาก
Ariel

0

mv <file-name> / dev / null

/ dev / null เป็นไฟล์ที่ไม่ใช่ไดเรกทอรี ไม่สามารถย้ายไฟล์ไปยังไฟล์หรือคุณเสี่ยงต่อการเขียนทับ

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

ฉันไม่คิดว่ามันใช้งานได้จริง มันจะใช้ I / O มากกว่า OP ที่ไม่จำเป็นโดยไม่จำเป็น


-1

/ dev / null เป็นไฟล์ที่ไม่ใช่ไดเรกทอรี ไม่สามารถย้ายไฟล์ไปยังไฟล์หรือคุณเสี่ยงต่อการเขียนทับ

จริงๆแล้วมันเป็นอุปกรณ์และข้อมูลทั้งหมดที่เขียนขึ้นเพื่อจะได้รับการทิ้งเพื่อให้mv <file> /dev/nullความรู้สึกที่ทำให้

จากวิกิพีเดียสารานุกรมเสรี
ในระบบปฏิบัติการยูนิกซ์ที่เหมือนกัน / dev / null หรืออุปกรณ์ null เป็นไฟล์พิเศษที่ทิ้งข้อมูลทั้งหมดที่เขียนไป (แต่รายงานว่าการดำเนินการเขียนสำเร็จ) และไม่ให้ข้อมูลใด ๆ แก่กระบวนการที่ อ่านจากมัน (ยอม EOF ทันที) [1]


1
นั่นเป็นสิ่งที่ผิดและเป็นอันตรายอย่างยิ่ง / dev / null เป็นอุปกรณ์ที่มีวัตถุเหมือนไฟล์พิเศษ หากคุณรูท "mv / some / file / dev / null" จะลบอุปกรณ์พิเศษ / dev / null และย้ายไฟล์ของคุณไปที่นั่น! ดังนั้นในครั้งต่อไปที่มีคนพยายามใช้ / dev / null พวกเขาจะใช้ไฟล์จริงแทนอุปกรณ์และภัยพิบัติจะเกิดขึ้น (เมื่อวิกิพีเดียบอกว่า "ทิ้งข้อมูลทั้งหมดที่เขียนไปแล้ว" นั่นหมายความว่า "cat / some / file> / dev / null" จะอ่าน / some / file และทิ้งข้อมูลที่คุณอ่าน แต่จะไม่ส่งผลกระทบต่อ ไฟล์ต้นฉบับ)
user9876
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.