btrfs의 쓰기 중 복사 기능은 데이터베이스 애플리케이션(예: postgresSQL)에 어떤 영향을 미치나요?

btrfs의 쓰기 중 복사 기능은 데이터베이스 애플리케이션(예: postgresSQL)에 어떤 영향을 미치나요?

저는 manjaro KDE를 개발 중이며 전체 /파티션(물론 /boot/efi 파티션 제외)은 btrfs 파일 시스템으로 포맷되어 있으며 쓰기 시 복사 기능은 여전히 ​​기본값입니다. 방금 Postgres를 설치하기 위해 Arch wiki를 팔로우하고 있었는데, 제가 잘 이해하지 못하는 것을 발견했습니다.

#https://wiki.archlinux.org/title/PostgreSQL

Warning:
If the database resides on a Btrfs file system, you should consider disabling Copy-on-Write for the directory before creating any database.

구글에서 검색해 봤는데, 제가 본 바로는 COW가 데이터베이스 성능을 저하시킬 것이라고 말하는 것 같습니다. 그런데 어떻게 이런 일이 일어났나요? COW는 I/O 대기 시간을 줄여준다고 되어 있지 않나요?

PS 영어는 제 모국어가 아닙니다. 일부 구문 오류가 있을 수 있습니다. 용서해주세요.

최선을 다하길 바랍니다.

답변1

링크를 클릭하시면여기>여기>드디어 왔어요다음 단어가 표시될 수 있습니다.

어떤 사람들은 Btrfs가 Ohad Rodeh가 제안한 리디렉션 기반 B-트리 업데이트 방식을 기반으로 하고 코드를 이해하기 더 쉽기 때문에 Btrfs가 "쓰기 시 복사" 대신 "쓰기 시 리디렉션"을 수행한다고 주장합니다. 그 사고방식을 이용해서요.

그 결과 기록 중 복사는 다른 곳에 새 데이터를 쓰고 리디렉션을 남겨둡니다. 이로 인해 디스크에 파일 조각화가 발생할 수 있습니다. 이 답변에는 이에 대한 토론이 있습니다.https://unix.stackexchange.com/a/395013/20140

이것을 postgresql(대부분의 최신 DBMS와 마찬가지로)의 동작과 결합하면 결과는 매우 바람직하지 않습니다. postgresql은 매우 큰 파일에 "무작위" 쓰기를 많이 수행하기 때문입니다. btrfs는 이러한 파일을 심각하게 조각화할 수 있습니다.

더 나쁜 것은 postgresql이 이미 매우 최적화되어 있다는 것입니다. 최소한의 디스크 검색을 발생시키기 위해 읽기 계획을 시도합니다. 또한 행이 기록될 때 수집된 테이블 데이터를 디스크의 동일한 위치에 유지하려고 시도합니다. 파일이 디스크 전체에 분산되어 있으면 읽기 데이터를 함께 수집하는 기능을 방해하고 결과적으로 속도가 느려집니다.

postgresql에는 다음과 같은 프로세스가 있습니다.진공. Vacuum의 업무 중 하나는 동일한 테이블에서 데이터를 대략적으로 수집하는 것입니다. 기록 중 복사를 켜면 이 프로세스는 실제로 정반대의 효과를 가져서 데이터가 디스크 전체에 널리 분산될 수 있습니다.


또한 매우 빠른 SSD 드라이브를 사용하면 조각화 비용이 다소 줄어들지만 여전히 존재한다는 점을 지적하고 싶습니다.

자기 저장 비용은 엄청납니다. 디스크는 작은 움직임으로 한 번에 많은 MB를 읽을 수 있습니다. 그러나 데이터가 단편화되면 디스크 헤드는 새로운 위치를 "찾아야" 하는데, 이는 (계산적으로 말하면) 오랜 시간이 걸립니다.

관련 정보