MySQL 사용에 있어서 Linux Filesystem Cache 문제(메모리 먹는 하마2)

아래의 내용은 Free Memory가 많이 남아 있음에도 불구하고 대량의 swap을 사용하는 것에 대한 문제를 해결한 내용입니다.

Mysql(or MariaDB)에서 사용하는 Innodb_Buffer는 할당된 공간을 미리 확보하는 것이 아니기 때문에 만일 다른 곳에서 메모리를 선점해 버린다면 Innodb_Buffer 사용량이 증가함에 따라 swap 사용량이 늘어난다.
물론 Innodb_Buffer가 미리 할당된 공간을 선점하였다하여도 알 수 없는 이유로 swap 사용량이 늘어나는 경우도 있다.
문제는 위의 두가지 모두 free memory Size가 있음에도 불구하고 발생한다는 것이다.

보통 서버의 메모리 free size라 함은
free -m -t 기준으로
free+cached 라고 들 한다.
왜냐하면 OS는 전체 memory size를 모두 사용하게 되었을 때에는 filesystem cache있는 메모리를 가장 먼저 반환해 주기 때문에 이 부분도 free로 보기 때문이다.
따라서, free size가 90M, cached가 9G이면 해당 DB서버의 free memory size는 9.09G가 된다.
그러나, 함정이 여기에 있었다.

실제 CentOS 5.x는 Filesystem Cache를 가장 우선시 하고 있었으며, 이 때문에 실제 서버의 free memory가 없을 경우
Filsystem Cache의 일부를 반환하는 것이 아닌 memory를 가장 많이 사용하고 있는 application의 일정량을 swap으로 내려버린다.
이것은 일부 mysql 엔진 개발자들 사이에서는 5.x까지의 버그로 인식하고 있으나(현재까지 OS쪽으로는 bug로 reporting 되지는 않았음)
CentOS 6.x에서는 패치가 되었다고는 하나 아직 6.x의 안정성 문제로 현재시점까지 카카오는 테스트 해 보지 않았다.

MySQL community 서버에서 filesystem cache를 사용하는 대표적인 경우는
1. O_DIRECT 미사용시
DataFile, Redo Log, Bin Log, Backup File(해당서버에서 Backup시), 기타 로그(slow-query.log 등등)
2. O_DIRECT 사용시
Redo Log, Bin Log, Backup File(해당서버에서 Backup시), 기타 로그(slow-query.log 등등)
MariaDB 서버에서 filesystem cache를 사용하는 대표적인 경우는
1. ALL_O_DIRECT 미사용시
DataFile, Redo Log, Bin Log, Backup File(해당서버에서 Backup시), 기타 로그(slow-query.log 등등)
2. ALL_O_DIRECT 사용시
Bin Log, Backup File(해당서버에서 Backup시), 기타 로그(slow-query.log 등등)

따라서, 다음의 경우에는 FileSystem Cache가 많이 커지게 된다.
- (ALL_)O_DIRECT를 사용하지 않고 partition table이 많거나 실제 table이 많은 경우
- ALL_O_DIRECT를 사용하지 않고 log group의 size가 크고 많은 경우
- Bin Log의 expire_days가 길어 파일이 많거나 백업 파일이 많은 경우
- 기타 복제 구성을 위한 덤프파일이 존재하는 경우

위의 경우에는 swap이 생길 수 있음을 유의해야 한다.

이를 해결하기 위한 방법으로는 cache unmap 스크립트를 주기적으로 실행하는 방법이 있다.
FileSystem Cache에 지정한 파일은 FileSystem Caching 대상에서 제외하라는 명령으로
카카오에서는 Maria Community의 요시노리 개발자가 작성한 스크립트를 수정하여 적용하였다.
Source : https://github.com/yoshinorim/unmap_mysql_logs

수행 효과는 다음과 같다.