[MySQL/MariaDB] Maria DB IO 및 swap 점유 튜닝 포인트

[MariaDB] Maria DB IO 및 swap 점유 튜닝 포인트

 

리눅스는 기본적으로 app에서 사용하는 heap, stack/shared data, file은 재사용 확률 높다하여 메모리에 캐쉬하려는 경향이 있으며,

커널 파라미터에 지정된 전체 메모리의 dirty 비율(통상 20%)에 도달 시 clean 작업을 진행…

만약 프로그램에서 요구하는 메모리의 양이 위 clean 작업 통해 반환되는 메모리보다 많으면, 커널은 가용 메모리 확보 위해 inactive memory cache를 flush(file)하거나 swap out(data) 처리.

 

기본적으로 app.(db) 메모리 요구(사용량) 줄이는 방향으로 튜닝하고,

그래도 문제 지속되면 OS 측면 flush 강도, dirty ratio 조정 필요하다 판단함 (보라매 사례 참조)

 

우선적으로 isolation level 변경과 slave의 bin log 생성을 중지하여 i/o 양(app memory 요구)을 줄이겠다는 게 요점입니다.

 

ㅇTransaction Isolation level 변경 (read committed → repeatable read)

Read-committed 설정시 record 단위 복제가 이루어짐(제약사항). Repeatable read 설정시 statement 단위 복제 가능.

일예로, update 문장 하나로 100개의 Row가 변경되었다면, Row 단위 복제에서는 100개의 row가 slave에 전달되고, statement 방식에서는 update 문장 한 개만 전달됨

row(record) 단위 대비 Statement 복제 방식은 동시성은 낮아지지만(lock issue ↑),  i/o가 상대적으로 적어짐.

Workload 특성 고려시 동시성 문제는 없을 것으로 판단되나 TB 통해서 App 단 lock wait 발생여부 확인 예정

현재 보라매사옥의 경우 tran isol level은  repeatable read임

(IT 시스템 운용 가이드에서 명기된 내용 그대로 적용, 가이드 업데이트 추진 예정)

 

ㅇlog-slave-update 변경 (1 → 0)

“master -> slave & master -> slave” 구조에서 필요한 설정으로, 당사 master -> slave 구조의 slave server에서 bin log를 생성할 필요 없음

(IT 시스템 운용 가이드에서 명기된 내용 그대로 적용, 가이드 업데이트 추진 예정)

 

ㅇTemporary table Replication 제외

temporary table은 system이 아닌 session level에서만 유효, 세션 종료시 사라지는 객체임. 기본적으로 replication 대상 아니며, 설정 변경 불필요함.