Zabbix DB 성능 최적화 (MySQL 환경 기준 실무 튜닝 가이드)

Zabbix를 일정 규모 이상으로 운영하다 보면 가장 먼저 한계가 오는 부분이 DB다.
CPU, 메모리보다도 InnoDB I/O와 Zabbix의 내부 캐시 구조가 병목을 일으킨다.
특히 수백~수천 개 아이템이 초 단위로 들어오는 환경에서는 DB 튜닝이 시스템 전체 안정성을 좌우한다.

이 글은 단일 Zabbix Server + MySQL 조합에서 실무적으로 가장 효과가 컸던 zabbix DB 성능 최적화 기법을 정리한 것이다.

이것과 관련한 글 특히 파티션 테이블에 대한 글은 전체 설치와 함께 상세히 설명된 아래 url 참고 바란다.

1. Zabbix DB 구조 개요

Zabbix의 데이터는 두 개의 주요 테이블 그룹으로 나뉜다.

대부분의 DB 부하는 history 계열에서 발생한다.
그래서 “어떻게 이 테이블을 효율적으로 쓰고 주기적으로 정리하느냐”가 핵심이다.

2. History / Trends 저장소 분리

서버 하나라도, 디스크를 논리적으로 분리해두면 효과가 크다.
Zabbix는 random write가 많으므로 SSD 기반의 history 디스크를 권장한다.

3. Partition Table 권고

housekeeper가 수백만 건을 삭제할 때는 DB가 사실상 멈춘다는 표현이 맞을 정도로
많은 부하를 겪게 된다
partition table 구조로 가는걸 고민할 필요성이 있다

4. Housekeeper 튜닝

Housekeeper는 오래된 데이터를 주기적으로 지우는 프로세스다.
하지만 대규모 환경에서는 오히려 성능을 떨어뜨린다.

파티션 테이블 운영을 권고하는 바이며 zabbix 7.4 기준으로 웹 UI에서 수정하여야 한다.

Administration -> Housekeeping 이동

Events and alerts → ☐ (끄기)
Services → ☐ (끄기)
User sessions → ☑ (유지)
History → ☐ (끄기)
Trends → ☐ (끄기)

5. Cache 및 프로세스 튜닝

Zabbix server는 DB를 직접 hit하지 않고 캐시를 먼저 사용한다.
캐시가 부족하면 바로 DB에 write를 시도하므로 DB I/O가 폭발한다.

/etc/zabbix/zabbix_server.conf에서 아래 항목을 확인해야 한다.

이 설정들은 직접적인 DB 부하 완화에 도움이 된다.

6. MySQL InnoDB 핵심 튜닝 항목

Zabbix는 InnoDB 기반으로 동작한다.
디폴트 설정만으로 버티기엔 버거울 수 있다.
아래는 실무 기준으로 수정하면 좋은 주요 파라미터들이다.

[mysqld]
innodb_buffer_pool_size = 4G
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_doublewrite = 1
innodb_flush_method = O_DIRECT
innodb_io_capacity = 2000
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_buffer_pool_instances = 4

🔹 innodb_buffer_pool_size

InnoDB의 데이터와 인덱스를 캐싱하는 영역.
DB 전체 성능에 가장 큰 영향을 준다.
서버 메모리의 **60~70%**까지 할당해도 무방하다.
이 값이 작으면 디스크 I/O가 폭증한다.

🔹 innodb_flush_log_at_trx_commit

트랜잭션 로그를 디스크에 얼마나 자주 flush할지 결정하는 핵심 옵션이다.

Zabbix처럼 초당 수백 트랜잭션이 발생하는 환경에서는 2번이 최적이다.
전원 장애 시 1초 이내 데이터 일부 손실 가능성이 있지만,
운영상 무시 가능한 수준이다.

🔹 innodb_doublewrite

• 전원장애/커널 패닉 시 페이지 찢김 위험↑
• NVMe + O_DIRECT 환경이라도 운영 DB면 보수적으로 1 권장.
  • 성능 이슈 없으면 1, 성능 한계가 보여서 리스크 감수할 때만 0.

🔹 innodb_flush_method

파일 시스템 캐시를 건너뛰고 OS I/O를 직접 수행하는 방식.
O_DIRECT 설정으로 중복 캐시를 줄이고 I/O 지연을 최소화한다.

🔹 innodb_io_capacity

InnoDB의 내부 I/O 스케줄러가 처리할 수 있는 최대 IOPS.
디스크가 SSD라면 2000~4000 이상으로 설정 가능.
기본값(200)은 너무 낮아서 dirty page flush가 지연된다.

7. RAID Chunk Size / I/O 구조 최적화

Zabbix DB는 작은 블록 random write가 대부분이다.
RAID 환경에서는 **작은 chunk size (16KB~32KB)**가 유리하다.
이 크기가 InnoDB의 기본 페이지 크기(16KB)와 맞기 때문이다.

RAID10 환경에서는 chunk size × (n-1) 로 stripe width가 결정되므로
전체 블록 정렬을 고려해 세팅해야 한다.

8. 모니터링으로 병목 지점 확인하기

튜닝은 “무엇이 병목인지 확인”한 뒤에 해야 한다.
아래 항목들 또는 비슷한 지표값들을 확인하면 병목 지점을 확인하는데 도움이 될 것이다.

이 값들이 모두 정상 범위면 DB 튜닝은 완료된 것이다.

9. 예시: 단일 서버 기준 최적 구조

Zabbix Server
 ├─ MySQL (history: SSD, trends: HDD)
 ├─ InnoDB buffer pool: 4G
 ├─ Housekeepers 비활성화
 ├─ innodb_flush_log_at_trx_commit=2
 ├─ CacheSize=512M
 ├─ HistoryCacheSize=1G
 └─ TrendCacheSize=256M

• history는 SSD에 보관
• trends는 HDD에 장기 보존
• housekeeper 비활성화
• 매일 cron으로 partition drop 수행
• InnoDB flush 모드는 OS cache 기반(2번)

이 구성으로 초당 10~20K metrics 환경에서도 queue delay가 거의 발생하지 않는다.

10. 결론

Zabbix DB 성능의 핵심은 단순하다.
InnoDB I/O를 줄이고 캐시로 버티는 구조로 전환하는 것.

1. history/trends 분리 저장
2. partition 기반 데이터 삭제
3. Housekeepers 비활성화
4. innodb_flush_log_at_trx_commit=2
5. innodb_buffer_pool_size 최대화
6. CacheSize / ValueCacheSize 확장

이 6가지만 제대로 세팅하면 Zabbix 서버는 수배의 부하에도 안정적으로 동작한다.
대규모로 가기 전에 “DB가 먼저 무너지는 이유”를 이해하면,
모니터링 플랫폼을 오래 버틸 수 있다.

🛠 마지막 수정일: 2025.10.28