기본 옵션으로 ext3 파일 시스템을 마운트했습니다. 그것에 ~ 100GB 파일이 있습니다.
이러한 파일을 제거하면 시간이 오래 걸리고 (8 분) 많은 io 트래픽이 발생하여 서버의로드가 증가합니다.
rm을 파괴적이지 않게 만드는 방법이 있습니까?
답변:
가장 흥미로운 답변은 원래 질문에 대한 의견에 묻혔습니다. 여기에 더 눈에 잘 띄는 첫 번째 답변이 있습니다.
기본적으로 여기에서 방법이 작동하지 않아서 자체 개발했습니다. 여기에 설명되어 있습니다 : http://www.depesz.com/index.php/2010/04/04/how-to-remove-backups/ – depesz 4 월 6 일 10시 15 분 15 초
이 링크는 실행 가능한 솔루션의 탐색과 발견에 대한 엄청나게 철저한 분석입니다.
참고 사항 :
기사는 말합니다 :
보시다시피, 나는
-c2 -n7이온화 하는 옵션을 사용했습니다 .
사실이지만 TafT 사용자는 중단을 원하지 않으면 -c3'유휴'가 -c2'최선의 노력' 보다 더 나은 선택 이라고 말합니다 . 그는 -c3백그라운드에서 빌드 하는 데 사용 했으며 빌드가 기다릴 필요없이 잘 작동한다는 것을 알았습니다. 실제로 100 % io 사용률을 가진 경우 -c3삭제가 완료되지는 않지만 실제로 테스트 한 결과를 기대하지는 않습니다.
ionice 를 시도해 볼 수 있습니다 . 더 빠르지는 않지만 덜 방해 할 수 있습니다.
효율성 측면에서 파일 당 하나의 rm을 사용하는 것은 각 rm에 대해 포크와 exec가 필요하므로 최적이 아닙니다.
제거하려는 파일이 들어있는 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(지금은 크기가 0입니다.) rm -rf <file>지금 사라지고 싶다면
또는 더 나은
고양이를 버리고 그냥 # > /file/to/be/emptied
합리적인 속도로 디렉토리를 삭제하는 데 문제가 있었고 프로세스가 디스크를 잠그고 디스크에 액세스하려고하는 프로세스 더미를 생성하는 것으로 나타났습니다. ionice가 작동하지 않았기 때문에 디스크 IO의 99 %를 계속 사용하고 다른 모든 프로세스를 잠갔습니다.
나를 위해 일한 파이썬 코드는 다음과 같습니다. 한 번에 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
내 두 센트
나는 이미이 문제를 겪었다. "빠르게 실행되어야하는 순차 스크립트에서 프로세스는 많은 파일을 제거합니다." "rm"은 해당 스크립트 속도를 IO 대기 / 실행 시간에 가깝게 만듭니다.
그래서 일을 더 빨리하기 위해 가비지 콜렉터와 같이 cron ..마다 실행되는 다른 프로세스 (bash 스크립트)를 추가하여 특정 디렉토리의 모든 파일을 제거합니다.
그런 다음 "rm"을 mv로 "garbage folder"로 바꾸어 원본 스크립트를 업데이트했습니다 (충돌을 피하기 위해 이름 끝에 카운터를 추가하여 파일 이름을 바꿉니다).
이것은 나를 위해 작동합니다. 스크립트는 최소 3 배 빠르게 실행됩니다. 그러나 파일 폴더를 피하기 위해 가비지 폴더와 원본 파일이 동일한 마운트 지점 (동일한 장치)에있는 경우에만 잘 작동합니다. (동일한 장치에서 mv는 rm보다 적은 IO를 소비합니다)
도움이 되길 바랍니다 ..
백업을 저장할 루프 파일 시스템을 만들 수 있습니다.
# 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
프레스토 악장! 전체 가상 파일 시스템이 순식간에 지워집니다.
/ dev / null은 디렉토리가 아닌 파일입니다. 파일을 파일로 옮길 수 없거나 덮어 쓸 위험이 있습니다.
실제로는 장치이며 장치에 기록 된 모든 데이터는 폐기되므로 mv <file> /dev/null의미가 있습니다.
Wikipedia에서 무료 백과 사전
Unix와 같은 운영 체제에서 / dev / null 또는 null 장치는 쓰여진 모든 데이터를 버리고 (쓰기 작업이 성공했다고보고) 특별한 프로세스에 데이터를 제공하지 않는 특수 파일입니다. 그것으로부터 읽습니다 (즉시 EOF를 나타냄). [1]