우리 애플리케이션은 거대한 링 버퍼(30~150TB)로 디스크에 데이터를 씁니다. 새 파일은 이전 파일이 삭제되는 동안 기록됩니다. 따라서 정의에 따르면 디스크는 항상 "거의 꽉 찼습니다".
이것작가이 프로세스는 약 100-150Mbits/s의 순 입력 속도로 다양한 파일을 생성합니다. 데이터 파일은 1GB "데이터" 파일과 여러 개의 작은 메타데이터 파일이 혼합되어 있습니다. (입력 속도는 일정하지만 새 파일 세트는 2분마다 생성됩니다.)
별도의삭제자30초마다 "가장 오래된" 파일을 삭제하는 프로세스입니다. 디스크의 여유 공간이 15GB에 도달할 때까지 계속 삭제됩니다.
따라서 안정적으로 실행될 때 모든 데이터 파티션의 사용 가능한 공간은 15GB뿐입니다.
존재하다이 문제파일 시스템 속도 저하와 관련하여우울한 다니엘댓글을 달았습니다:
동기화 중단은 단순히 파일 시스템이 최신 작업을 일관되게 저장하는 데 어려움을 겪고 있음을 의미합니다. 그 시점에서 디스크의 데이터를 이동하려고 시도할 것입니다. 자세한 내용은 모르지만 파일 시스템이 심각하게 조각화되어 있으면 ext4가 이에 대해 조치를 취할 것이라고 확신합니다. 파일 시스템이 거의 100% 가득 차면 좋지 않습니다. 100%에 가까운 용량으로 파일 시스템을 활용하는 유일한 합리적인 방법은 일부 파일로 정적으로 초기화한 다음 동일한 파일을 제자리에 덮어쓰는 것입니다(조각화를 방지하기 위해). 아마도 ext2/3에 가장 적합할 것입니다.
ext4는 이 애플리케이션에 적합하지 않은 선택인가요? 이제 실시간으로 실행되고 있으므로 조각화, 속도 저하 또는 기타 성능 제한을 방지하기 위해 ext4를 어떻게 조정할 수 있습니까? ext4에서 변경하는 것은 매우 어려울 것입니다...
(정적으로 생성된 파일을 다시 작성한다는 것은 전체 애플리케이션을 다시 작성한다는 의미입니다)
감사해요!
나를 편집하다
서버에는 50~100TB의 디스크(24개 드라이브)가 연결되어 있습니다. Areca RAID 컨트롤러는 24개의 드라이브를 RAID-6 RAID 세트로 관리합니다.
거기에서 각각 5TB에서 10TB 범위의 여러 파티션/볼륨으로 분할되었습니다. 따라서 한 롤의 크기는 그리 크지 않습니다.
"작성기" 프로세스는 "충분한" 공간이 있는 첫 번째 볼륨을 찾아 거기에 파일을 씁니다. 파일이 작성된 후 프로세스를 반복하십시오.
새로운 시스템에서는 볼륨이 순차적으로 채워집니다. 모든 볼륨이 "가득" 차면 "충분한" 공간을 사용할 수 있을 때까지 "프로그램 제거" 프로세스가 가장 오래된 파일 삭제를 시작합니다.
시간이 지남에 따라 다른 프로세스의 작업으로 인해 파일의 시간순 순서가 모든 볼륨에 무작위로 분산됩니다.
편집 2
실행에서는 fsck1~2%의 매우 낮은 조각화를 보여줍니다. 그러나 동시에 느린 파일 시스템 액세스는 등의 다양한 시스템 호출로 인해 실행 시간이 오래 걸리는 것으로 추적되었습니다 fclose()( fwrite()5 ftello()~60초!).
지금까지 이 문제에 대한 해결책은 없습니다. 자세한 내용은 이 문제를 참조하세요.매우 느린(200초) fwrite()/ftello()/fclose()를 디버깅하는 방법은 무엇입니까?
비활성화 sysstat하고 raid-check개선 사항이 있는지 확인했습니다.
답변1
원칙적으로 링 버퍼 쓰기를 엄격하게 하면 조각화에 문제가 발생하는 이유를 알 수 없습니다. 간단한 것 같습니다. 제 생각에는 이 설명은 보다 일반적인 쓰기 작업량을 기반으로 한 권장 사항입니다. 하지만 연결된 질문을 보면 진짜 문제가 있는 것 같습니다...
조각화에 관심이 있으므로 이를 측정하는 방법을 고려해야 합니다! e4defrag존재하다. 두 가지 옵션만 있습니다. -c현재 상태만 표시되며 조각 모음은 수행되지 않습니다. -v각 파일에 대한 통계를 표시합니다. 모든 옵션 조합이 유효합니다(옵션 없음 포함). 실행 중인 시스템에 대한 성능 영향을 제한하는 명시적인 방법을 제공하지는 않지만 e4defrag개별 파일에 대한 실행을 지원하므로 직접 속도를 제한할 수 있습니다.
(XFS에도 조각 모음 도구가 있지만 저는 사용해본 적이 없습니다.)
e2freefrag여유 공간 조각화를 표시할 수 있습니다. 만약에CFQ IO 스케줄러를 사용하는 경우 감소된 IO 우선순위로 실행할 수 있습니다 ionice.
인용된 추측은 틀렸고 Stephen Jeter의 대답은 정확했습니다. ext4는 자동 조각 모음을 수행하지 않습니다. 기록된 데이터를 "셔플"하려고 시도하지 않습니다.
이 이상한 오해를 포기하면 "ext2/ext3"을 제안할 이유가 없습니다. 그렇지 않으면 현재 커널에 ext3 코드가 없습니다. ext4 코드는 ext3을 마운트하는 데 사용됩니다. ext3은 ext4의 하위 집합입니다. 특히 상대적으로 큰 파일을 생성하는 경우 범위를 사용하지 않는 것이 어리석은 것처럼 보이며 이는 ext4에만 해당되는 기능입니다.
나는 "교수형"이 저널링과 더 자주 연관되어 있다고 생각합니다. (파일 시스템 진행 중)에 대한 설명을 참조하세요.bcachefs-
테일 대기 시간은 수년 동안 ext4 사용자의 골칫거리였습니다. 로깅 코드 및 다른 곳의 종속성으로 인해 멀티 스레드 워크로드에서 간단한 작업(예: 연결 해제)에 대해 30초 이상의 지연이 발생할 수 있습니다. 아무도 문제를 해결하는 방법을 모르는 것 같습니다.
bcachefs에서 IO 시 스레드가 차단되는 유일한 이유는 스레드가 이를 명시적으로 요청하는 경우(캐시되지 않은 읽기 또는 fsync 작업) 또는 리소스가 소진되는 경우(완전한 중지)입니다. IO를 수행하는 동안 포그라운드 작업을 차단하는 잠금은 유지되지 않습니다. bcachefs는 아직 실시간 파일 시스템은 아니지만(예: IO의 실시간 예약 기능이 부족함) 언젠가는 실시간 파일 시스템이 될 가능성이 높습니다.
XFS를 사용하여 위의 문제를 어느 정도 피할 수 있는지 설명해달라고 요청하지 마십시오. 나는 모른다. 그러나 대체 파일 시스템 설정 테스트를 고려하고 있다면 XFS가 제가 시도할 첫 번째 설정입니다.
ext4에서 로깅을 비활성화하면 어떤 영향을 미치는지에 대한 많은 정보를 찾으려고 노력하고 있습니다. 적어도 성능을 튜닝할 때 고려되는 일반적인 옵션 중 하나는 아닌 것 같습니다.
왜 sys_sync()를 사용하는지 잘 모르겠습니다. 일반적으로 피하는 것이 가장 좋습니다(예:여기). 이것이 실제로 귀하의 문제를 설명하는지 확실하지 않지만 범위를 좁히려고 노력하는 동안 발생한 불행한 것 같습니다.
답변2
또 다른 방법이 있지만 조금 더 복잡합니다.
10개 또는 20개 등의 작은 파티션을 많이 만듭니다. LVM2이런 상황에서 유용할 수도 있습니다. 그런 다음 다음과 같이 링 버퍼 형태로 파티션을 사용합니다.
파티션 중 하나는 항상 "활성" 파티션이며, 완전히 또는 거의 가득 찰 때까지 새 데이터가 해당 파티션에 기록됩니다. 헤드룸을 남겨둘 필요가 없습니다. 활성 파티션이 가득 차거나 다음 데이터 블록을 수용할 여유 공간이 충분하지 않은 경우 다음 파티션으로 전환하면 해당 파티션이 활성 파티션이 됩니다.
삭제자 프로세스는 항상 최소한 하나의 완전히 비어 있는 파티션을 사용할 수 있는지 확인합니다. 그렇지 않다면 – 이것이 핵심 부분입니다 – 그것은 단순히재포맷가장 오래된 파티션에서 완전히 새로운 파일 시스템을 만듭니다. 이 새 파티션은 나중에 조각화를 최소화하거나 전혀 사용하지 않고 새 데이터를 수신할 수 있습니다.
답변3
이 문제는 거의 확실하게 ext4 delalloc(지연 할당) 기본 ext4 마운트 옵션으로 인해 발생합니다. 동기화(명시적 동기화 또는 주기적으로 실행되는 암시적 동기화)까지 새 파일을 쓸 위치를 결정하는 데 지연이 발생합니다. 파일 시스템이 가득 찬 경우 이 작업에는 디스크의 기존 파일을 이동하여 새 파일에 대한 연속 파일을 생성하는 작업이 포함될 수 있습니다. . 공간.
마운트 옵션에 nodellalloc을 추가하면 문제가 해결될 수 있습니다. 이렇게 하면 원본 쓰기가 발생할 때 ext4가 강제로 공간을 생성하게 됩니다(공간을 만들기 위해 기존 파일을 이동해야 하는 경우). 파일 시스템이 꽉 차면 원시 쓰기 속도가 느려지고 버퍼 캐시를 쓰기에 사용할 수 없는 것처럼 보이게 됩니다. 그러나 데이터가 파일에 계속 남아 있기 때문에 동기화가 완료되어야 할 때까지 문제를 지연시키는 것보다 낫습니다. 시스템에 오랜 시간이 걸렸습니다. 전원이 꺼지면 버퍼 캐시가 손실될 수 있습니다.
일반적으로 delalloc은 작성될 새 파일의 전체 크기를 알고 나서 파일을 배치할 위치만 결정하여 조각화를 최소화하므로 선호됩니다. 그러나 nodellalloc을 사용하더라도 ext4는 가능할 때마다 미리 큰 공간을 선택하려고 하기 때문에 조각화를 줄이는 데 효과적입니다.