업로드된 파일이 차지하는 디스크 공간을 조회하는 데 사용되는 ‘du’ 명령어가 관리자 대시보드의 성능 문제를 일으키고 있었습니다. 네, 저희는 이미지 업로드가 정말 많습니다. 아예 비활성화하는 것(그래프나/프로메테우스 대시보드가 있으니까요) 대신, 'df’를 사용해 훨씬 더 빠른 대략적인 근사값을 계산하도록 대체하기로 했습니다. 이 변경 사항은 물론 관리자가 선택할 수 있으며, 기본값은 'du’로 설정되어 있습니다.
이 변경 사항에 대한 PR을 제출했습니다. 제 첫 PR이라 좀 너그러이 봐주세요 :))
PR은 여기에서 확인하실 수 있습니다:
main ← overgrow:disk_space
closed 10:06AM - 10 Aug 24 UTC
This commit introduces the 'enable_precise_disk_space_calculation' feature that … allows admins to choose between using the 'du' command, which provides precise disk usage but is slower, and the 'df' command, which is faster but often inaccurate. This option is particularly useful for instances with 100,000+ uploads where the 'du' command can be detrimental.
The 'used' method now dynamically calculates disk usage based on the chosen option, ensuring accurate reporting of disk space on directories.
tgxworld
(Alan Tan)
8월 8, 2024, 2:07오전
2
du 명령이 얼마나 걸렸는지 대략적인 감이 있으신가요? 이 방식으로 성능 문제를 해결하는 데는 큰 관심이 없고, 두 가지 대안이 있다고 생각합니다:
외부 스토어에서처럼 uploads_used_bytes를 결정하기 위해 Upload.sum(:filesize).to_i + OptimizedImage.sum(:filesize).to_i를 사용하세요.
업로드가 사용하는 바이트를 주기적으로 다시 계산하고 Redis에 캐시하는 백그라운드 작업을 도입하세요.
개인적으로는 훨씬 더 간단한 솔루션인 (1)을 더 선호합니다. 정확도가 다소 떨어지지만, 여기서는 100%의 정확도가 필요하지 않습니다. 여전히 df로 얻는 근사치보다 훨씬 낫습니다.
2개의 좋아요
피드백 감사합니다.
du는 HDD에서 1분 이상 걸렸고, SSD에서는 대략 20초 정도 걸렸습니다.
저희처럼 업로드에 의존하는 인스턴스를 사용하는 경우, 어쨌든 업로드를 위한 전용 파티션을 가지고 있을 것이라는 것이 제 추론입니다.
하지만 네, 여러분의 1번 솔루션이 더 우아해 보입니다. 검토해서 수정된 PR을 제출하겠습니다.