synology / self-hosting / security / performance

성능

시놀로지 MariaDB 버퍼 풀이 16MB였던 이유: my.cnf보다 synology.cnf가 우선

my.cnf에 3GB로 적은 innodb_buffer_pool_size가 16MB로 돌던 원인이 시놀로지가 관리하는 synology.cnf였던 과정과, 확인·변경 방법, 적중률 85%에서 98.5%로 바뀐 결과입니다.

시놀로지 NAS의 MariaDB 10 패키지에서 innodb_buffer_pool_size를 설정 파일에 3GB로 적어 뒀는데, 실제로 돌고 있는 값을 확인해 보니 16MB였습니다. 기본값보다도 작은 값입니다. 적어 둔 다른 설정은 다 잘 먹는데 이것만 무시되고 있었습니다.

원인은 시놀로지가 따로 관리하는 설정 파일이었습니다.

실제 값은 DB에 물어봐야 압니다

설정 파일에 뭐라고 적혀 있든, 지금 적용된 값은 DB에 직접 물어보는 게 정확합니다.

SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS pool_mb;

여기서 16이 나왔습니다. 버퍼 풀이 이렇게 작으면 자주 읽는 데이터도 메모리에 못 올리고 매번 디스크에서 읽습니다. 실제로 이 상태에서 2시간 동안 디스크에서 13.7GB를 읽고 있었고, 적중률은 85%였습니다.

적중률은 이렇게 계산합니다. 디스크까지 간 읽기(reads)를 전체 읽기 요청(read_requests)으로 나눈 값을 1에서 빼면 됩니다.

SELECT 1 - (
  (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS
    WHERE VARIABLE_NAME = 'Innodb_buffer_pool_reads') /
  (SELECT VARIABLE_VALUE FROM information_schema.GLOBAL_STATUS
    WHERE VARIABLE_NAME = 'Innodb_buffer_pool_read_requests')
) AS hit_ratio;

설정 파일이 두 개 있습니다

MariaDB 10 패키지의 설정 폴더(/var/packages/MariaDB10/etc/)를 보면 파일이 여러 개 있습니다.

MariaDB 10 패키지 설정 폴더 (DSM 7.3)
파일권한용도
my.cnfroot만 읽기사용자가 직접 설정을 넣는 곳
synology.cnf누구나 읽기패키지 화면에서 바꾼 값을 시놀로지가 써 넣는 곳
my_port.cnf누구나 읽기포트 설정

synology.cnf를 열면 맨 위에 이렇게 적혀 있습니다.

# DO NOT EDIT THIS FILE !!!
# DO NOT EDIT THIS FILE !!!
# DO NOT EDIT THIS FILE !!!
# DO NOT EDIT THIS FILE !!!
# DO NOT EDIT THIS FILE !!!
# You can change some configs on user interface of MariaDB10.
# Please add your custom configuration to /var/packages/MariaDB10/etc/my.cnf
[mysqld]
skip_networking=0
innodb_buffer_pool_size=16M

안내문은 "사용자 설정은 my.cnf에 넣으라"고 하는데, 같은 키가 양쪽에 있으면 실제로 적용되는 건 synology.cnf 쪽이었습니다. my.cnf의 다른 값(bind-address, max_allowed_packet, wait_timeout)은 정상 반영됐고, 겹치는 키 하나만 덮어쓰인 겁니다.

파일 시각을 보니 9월 22일 새벽 1시 41분에 새로 만들어져 있었습니다. 그 시각에 무엇이 이 파일을 다시 썼는지는 확인하지 못했습니다.

바꾸는 방법

정석은 패키지 화면입니다. DSM에서 MariaDB 10 패키지를 열어 버퍼 풀 크기를 바꾸면 시놀로지가 synology.cnf를 다시 쓰고 DB를 재시작합니다.

재시작 없이 당장 바꾸려면 SET GLOBAL로도 됩니다. MariaDB 10.11은 버퍼 풀 크기를 돌면서 바꿀 수 있습니다. 대신 재시작하면 원래 값으로 돌아갑니다.

SET GLOBAL innodb_buffer_pool_size = 1073741824;  -- 1GB
SELECT @@innodb_buffer_pool_size / 1024 / 1024 AS pool_mb;

저는 새벽에 사이트가 느린 상태라 SET GLOBAL로 먼저 1GB를 적용했고, 영구화는 synology.cnf를 root로 직접 1024M으로 고쳤습니다. 경고문을 무시한 거라 원본은 백업해 뒀고, 패키지 화면에서 저장하면 다시 써질 수 있다는 것도 알고 있습니다. 그때는 화면에서 1024로 맞추면 됩니다.

얼마로 잡을까

이 NAS는 사용 가능한 메모리가 약 10.8GB이고, DB에는 워드프레스 7개 정도가 들어 있습니다. 1GB로 잡았더니 적중률이 85%에서 98.5%로 올라갔고, 20초 동안 디스크까지 간 읽기가 146건으로 줄었습니다. 이 규모에서는 1GB로 충분했습니다.

메모리가 넉넉하다고 크게 잡을 필요는 없습니다. 시놀로지는 Photos, Docker 같은 다른 패키지도 같은 메모리를 씁니다. 적중률을 보면서 99% 근처에서 멈추면 됩니다.

9월 27일 지금 상태

synology.cnf에는 innodb_buffer_pool_size=1024M이 그대로 남아 있습니다. DSM이나 패키지를 업데이트한 뒤에는 이 파일부터 열어 보는 게 습관이 됐습니다. my.cnf에 적었는데 반영이 안 되는 값이 있다면, 같은 키가 synology.cnf에 있는지 먼저 확인해 보세요.

확인한 공식 자료

구현 과정에서 판단 기준을 교차 확인한 공식 문서입니다. 글의 사례와 결론은 운영자가 직접 겪은 작업을 바탕으로 작성했습니다.