PostgreSQL에서 삽입 성능에 가장 적합한 파일 시스템은 무엇입니까?

파일 시스템과 데이터베이스 성능간에 실험이나 비교를 수행 한 사람이 있는지 궁금합니다. Linux에서는 postgres 데이터베이스에 가장 적합한 파일 시스템이 무엇인지 궁금합니다. 또한 어떤 설정 (inode 등)이 이상적입니까? 이것이 데이터베이스의 데이터에 따라 크게 다를 수 있습니까?

일반적인 파일 시스템 / 데이터베이스 성능과 관련된 질문을 찾고 있다면 이 게시물 에 좋은 정보가 있습니다.

그러나 가능한 한 읽기 성능이 아닌 삽입 성능 에 대해 많은 조언을 얻고 싶습니다 . 모든 위대한 답변에 감사드립니다!

Greg Smith의 "postgresql high performance"사본을 구입하십시오. 훌륭한 책이며 두 개 이상의 장이 디스크 하드웨어 및 파일 시스템에 관한 것입니다. 당신은 많이 배울 것입니다.

한마디로 : 짧은 대답이 없습니다.

그러나 나는 여름을 보려고 노력할 것이다.

• 뭘하고 있는지 알 때까지 ext2를 사용하지 마십시오.
• fsync 호출로 인해 검사 점 급증에주의하여 ext3 사용시, 113 및 82 및 79 페이지 참조
• ext4 또는 xfs 사용
• 다른 옵션이 있습니다

그러나 실제로 어떤 FS를 사용할 것인지 스스로에게 묻는다면이 책을 읽어야합니다!

우선, 당신은 안정적인 파일 시스템을 원하고 빠른 1 초를 원합니다. 어떤 옵션을 배제합니까?

성능 테스트에 따르면 XFS가 종종 최상의 성능을 제공합니다. 디스크에 매우 근접한 전체 시나리오에 도달하면 안정성 문제가 발생하지만, 발생하지 않는 상황을 모니터링하면 성능이 약간 향상됩니다.

이론적으로 pg_xlog 디렉토리에 저널링 파일 시스템이 필요하지 않지만 속도 차이는 일반적으로 너무 작아서 가치가 없습니다. 데이터 디렉토리의 경우 항상 메타 데이터 저널링 파일 시스템이 있어야합니다.

데이터베이스 관리 시스템은 데이터베이스 로그를 통해 자체 저널링을 구현하므로 저널링 된 파일 시스템에 이러한 DBMS를 설치하면 두 가지 메커니즘을 통해 성능이 저하됩니다.

1. 중복 저널링으로 디스크 활동량 증가

2. 실제 디스크 레이아웃은 조각화 될 수 있습니다 (일부 저널링 파일 시스템에는이를 정리하는 메커니즘이 있지만).

3. 디스크 활동이 많으면 저널이 가득 차서 가짜 '디스크 가득 참'조건이 발생할 수 있습니다.

몇 년 전 HP / UX 박스의 Baan 설치에서 LFS 파일 시스템에서 수행 된 인스턴스를 보았습니다. 파일 시스템이 LFS로 포맷되었다는 문제를 해결할 때까지 시스템에는 지속적인 성능 및 데이터 손상 문제가 진단되지 않았습니다.

데이터베이스 파일을 보유한 볼륨에는 일반적으로 적은 수의 큰 파일이 있습니다. DBMS 서버에는 일반적으로 단일 I / O에서 읽은 블록 수를 구성하는 설정이 있습니다. 중복 트랜잭션의 캐싱을 최소화하므로 대량 트랜잭션 처리 시스템에는 더 적은 수가 적합합니다. 다수의 시퀀셜 읽기를 수행 한 데이터웨어 하우스와 같은 시스템에는 많은 수가 적합합니다. 가능하면 파일 시스템 할당 블록 크기를 DBMS가 설정된 다중 블록 읽기와 동일한 크기로 조정하십시오.

일부 데이터베이스 관리 시스템은 원시 디스크 파티션에서 작동 할 수 있습니다. 이것은 다양한 메모리 성능을 가진 최신 시스템에서 다양한 수준의 성능 향상을 제공합니다. 파일 시스템 메타 데이터를 캐시 할 공간이 적은 구형 시스템에서는 디스크 I / O의 절감 효과가 상당히 컸습니다. 원시 파티션은 시스템을 관리하기 어렵지만 최상의 성능을 제공합니다.

RAID-5 볼륨은 RAID-10 볼륨보다 쓰기 오버 헤드가 더 많으므로 쓰기 트래픽이 많은 사용량이 많은 데이터베이스는 RAID-10에서 더 나은 성능을 발휘합니다 (종종 훨씬 더 우수). 로그는 물리적으로 별도의 디스크 볼륨을 데이터에 배치해야합니다. 데이터베이스가 크고 대부분 읽기 전용 (예 : 데이터웨어 하우스) 인 경우로드 프로세스 속도가 지나치게 느려지지 않으면 RAID-5 볼륨에 배치해야 할 수 있습니다.

컨트롤러의 후기 입 캐싱은 데이터가 손상 될 수있는 (합리적으로는 아니지만 가능할 수있는) 몇 가지 오류 모드를 만들면서 성능을 향상시킬 수 있습니다. 이것의 가장 큰 성능 승리는 매우 임의적 인 액세스로드입니다. 이렇게하려면 로그를 별도의 컨트롤러에 놓고 로그 볼륨에서 후기 입 캐싱을 비활성화하십시오. 그러면 로그의 데이터 무결성이 향상되고 단일 장애로 인해 로그 및 데이터 볼륨을 모두 제거 할 수 없습니다. 이를 통해 백업에서 복원하고 로그에서 롤 포워드 할 수 있습니다.

나는 그런 상세한보고를했지만 프랑스어로만되어있다 . 프랑스어를 읽거나 자동 번역 도구에 만족하는 경우 방법론을 재사용하여 직접 실행할 수 있습니다.

행정상 개요 : 나는 pgbench를 사용했다. Linux I / O 스케줄러는 성능 및 파일 시스템에 대한 중요성이 거의 없습니다. 따라서 급한 경우에는 기본값을 선택하십시오. JFS를 선택했습니다.

파일 시스템은 문제의 일부일뿐입니다. IO 스케줄러를 변경하여 성능을 크게 향상시킬 수 있습니다. 다행히도 IO 스케줄러를 즉시 변경할 수 있으므로 테스트하기가 매우 쉽습니다. 나는 전형적인 부하 하에서 며칠 동안 각각을 시도해보고 어느 것이 최고의 성능을 제공하는지 확인하는 것이 좋습니다.

몇 달 전에 몇 가지 테스트를 수행했습니다.

50 개의 스레드를 생성하는 작은 테스트 프로그램이 있었으며 모든 스레드가 동일한 테이블에 1000 (또는 10000 행) 행을 삽입했습니다.

• EXT3의 데이터베이스와 4 개의 디스크 RAID5의 경우 50 초가 걸렸습니다.
• 램 디스크의 테이블 (테이블 스페이스 사용)은 여전히 ​​50 초가 걸렸습니다. 더 빠르지 않은 이유는 모든 것이 pg_xlog 디렉토리에 여전히 같은 RAID 5에 기록되어 있기 때문입니다.
• pg_xlog를 4 디스크 RAID0 (스트라이프)으로 옮기고 같은 프로그램이 40 초 안에 실행됩니다.
• 테스트 목적으로 pg_xlog를 램 디스크로 옮기고 EXT3 4 디스크 RAID에 다른 모든 것을 가졌습니다. 프로그램은 5 초 이내에 완료되었습니다.

그러나 소프트웨어 램 디스크에 pg___xlog를 갖는 것은 옵션이 아닙니다. pg_xlog 디렉토리의 내용을 잃어버린 경우 postgres가 시작되지 않습니다. (하지만 배터리 백업이 필요한 하드웨어 램 디스크가 있습니다.)

IMHO : 데이터베이스 파일에 가장 익숙한 파일 시스템을 사용하십시오. pg_xlog (symlink와 함께, 설명서 참조)를 가능한 가장 빠른 장치로 옮기십시오.

조정 된 FreeBSD는 다른 OS와 비교하여 약간 더 많은 성능을 제공한다는 것을 기억했습니다. 나는이 정보가 구식이며 아마도 처음에는 신화라고 확신하지만. 그럼에도 불구하고 시도해 볼 수 있습니다. 커널 설정에 대한 다음 지침을 참조하십시오. http://developer.postgresql.org/pgdocs/postgres/kernel-resources.html