in0de

${instance home}/sqllib/tmp는 다음의 유틸리티/어플리케이션/툴 들에 의해 I/O가 발생한다.


DB2 Engine에서의 temporary processing의 세부내용은 알 수 없겠지만
대부분의 경우는 index key sorting 이라던가
여러 utility나 application들에 의해 I/O가 발생된다고 보면 되겠다.

엔터프라이즈 시스템에서의 sqllib/tmp의 위치는 신경써서 정해야할 듯 한데
실제로 이 디렉토리를 모니터링해보면 상당히 자주, 많이 access하고있고

파일시스템에 문제가 있거나
(ie. 시만텍의 매우 오래된 VxFS 4.0.3.2 (4.0 MP3RP2)의
비효율적인 dirty page scan 알고리즘으로 인해 disk I/O의 30%를 일으켰던 경우)

좋지 못한 성능의 Internal disk에 instance home을 둔다거나 한다면
전체적으로 DB의 성능을 떨어뜨릴 수 있기 때문이다.

instance home 디렉토리는 디스크 장애에 의해서 inaccessible할 경우
DB에 대해서 어떠한 제어도 할 수 없게 되므로, 안정적인 디스크에 두어야 하며

안정적인 디스크에 instance home을 두었으나 속도가 좋지 못해,
sqllib/tmp로 인한 성능 저하가 우려되는 경우
DB 자체적으로 sqllib/tmp의 위치를 hidden parameter등으로 변경할 방법은 존재하지 않으며
다음과 같은 방법으로 성능 좋은 디스크 쪽의 디렉토리를 링크하여
안정성과 성능을 둘 다 만족시킬 수 있다.

Tablespace의 File System Caching 기능을 해제하여 DB2 응답 성능을 향상시킬 수 있다.

모든 I/O를 할 때, OS 레벨의 File system caching 기능을 사용하지 않고
DB2의 bufferpool만을 사용하는 개념인데,
모든 상황, 모든 버전에서 효과가 있는 지는 테스트를 해봐야 알 것 같다.

Filesystem caching On 상태

이 상태로 속도는 최초 수행 시 0.83초, 반복 수행 시 0.45초로 나타났다.
정확한 측정을 위해서는 db2batch command를 사용해야하나, 측정 결과는 크게 다르지 않다.

Alter tablespace문의 NO FILE SYSTEM CACHING command option으로 OS level의 cache를 사용하지 않도록 지정한다.
online으로 바로 적용 가능하며, Connection terminate 이후부터 반영된다.

FSC 컬럼을 보면 Filesystem caching이 해제된 것을 확인할 수 있다.

적용 후의 동일 쿼리 수행 결과

OS Caching을 bypass함으로써, 상당한 성능 향상을 볼 수 있다.

단, 다음 환경에서의 테스트에 따르면