Incident Library

IL-0439 Cybozu · 2018-06-28 (게시일)database

블록 디바이스와 파일 시스템을 확장할 때마다 데이터베이스 접근이 한동안 느려졌다

Cybozu 는 자사 시스템의 데이터 일부를 SQLite 에 저장한다. 이 데이터가 놓인 블록 디바이스는 원격 서버의 LVM 볼륨에 대응하는 iSCSI 디바이스 두 개를 RAID1 로 묶은 것이다. 데이터베이스가 커져 파일 시스템의 빈 공간이 모자라면, 이 블록 디바이스의 크기를 늘리고 그 위의 파일 시스템 크기를 늘렸다. 그때마다 데이터베이스 접근이 한동안 느려져 고객이 쓰는 애플리케이션의 응답이 나빠졌다. free 와 sar 로 보니 블록 디바이스를 늘린 뒤 페이지 캐시가 크게 줄었고, 성능 저하와 함께 스토리지 접근이 생겼다. 페이지 캐시는 스토리지 디바이스의 데이터를 메모리에 복사해 두고 읽기와 쓰기를 메모리 속도로 처리하게 하는 커널 기능이다.

운영 본부의 한 엔지니어가 커널 소스를 조사했다. 블록 디바이스 크기 변경 처리에서 불리는 check_disk_size_change() 함수는 크기가 바뀌면 축소든 확장이든 flush_disk() 를 불러, 그 디바이스 위 파일 시스템의 페이지 캐시를 무효화했다. flush_disk() 호출을 넣은 커밋을 git blame 으로 찾아 설명을 읽었다. 축소 때 대상 영역을 읽고 쓰는 중이면 I/O 오류가 나고, 확장은 축소 직후 확장하는 특수한 경우에만 문제가 될 수 있다는 내용이었다. 관련 소스를 모두 조사해 보니 커널 안의 상호 배제 때문에 축소 직후 확장해도 그 문제는 일어날 수 없었고, 확장 때의 무효화는 필요 없었다.

운영 본부의 두 엔지니어는 크기가 줄어들 때만 flush_disk() 를 부르는 fs/block_dev.c 패치를 만들었고, 개발 환경에서 시험한 뒤 운영 환경에 적용해 사내 문제를 풀었다. 두 엔지니어 가운데 커널 소스를 조사하지 않은 다른 한 사람이 이 패치를 upstream Linux 커널에 넣는 작업을 했다. 처음 보낸 [RFC PATCH] fs: don't flush pagecahce when expanding block device 에는 아무도 답하지 않았지만, 패치와 글을 단순하게 다듬어 여러 번 다시 보낸 끝에 몇 달 뒤 next tree 를 거쳐 v4.17 에 들어갔다.

심각도
–
영향 범위
Database access slowed down temporarily after each filesystem expansion, showing as slower application responses for customers
영향 사용자
–
지역
–
감지까지
–
복구까지
–

증상

SQLite 데이터베이스가 놓인 파일 시스템의 크기를 늘린 뒤 데이터베이스 접근이 한동안 느려졌다. 이 현상은 고객이 쓰는 애플리케이션의 응답 속도 저하로 나타났고, Cybozu 는 오랫동안 이 문제를 겪었다.

확장은 두 단계였다. 먼저 파일 시스템이 놓인 블록 디바이스의 크기를 늘리고, 그다음 그 위의 파일 시스템 크기를 늘렸다. 느려지는 것은 두 번째 단계 뒤였다.

free 명령과 sar 명령으로 통계를 보니 첫 번째 단계 뒤 시스템의 페이지 캐시 양이 크게 줄어 있었다. 두 번째 단계 뒤에는 데이터베이스 접근 성능이 떨어지는 것과 함께 스토리지 디바이스 접근이 생겼고, 성능이 회복되면서 스토리지 접근도 줄었다.

커널에서 이 동작을 피하는 설정 항목을 찾았지만 없었다.

증상 지연 시간 증가

원인

원인 소프트웨어 결함

구성 요소 리눅스 커널데이터베이스
기여 요인 –
촉발
데이터베이스가 커져 빈 공간이 모자라자 파일 시스템이 놓인 블록 디바이스의 크기를 늘리고 그 위의 파일 시스템 크기를 늘렸다.

감지

파일 시스템 확장 뒤 데이터베이스 접근이 느려진 것이 고객이 쓰는 애플리케이션의 응답 속도 저하로 드러났다.

조치

후속 조치

교훈

Cybozu 는 소스 수정의 수고가 바뀐 줄 수에 비례하지 않는다고 했다. 이번 수정은 2천만 줄에 이르는 Linux 커널 소스에서 4줄을 더하고 2줄을 지운 것에 지나지 않았지만, 거기까지 여러 시행착오가 있었다. 코드를 쓴 의도를 모를 때는 주석이나 변경 때의 커밋 설명을 보는 것이 정석이라고도 했다.

출처

관련 사례

내 클러스터에도 있는지 확인하기

kubegap 은 Claude Code 나 Codex 에서 쿠버네티스 클러스터를 읽기만 하며 이 사례와 같은 상태를 점검합니다. 이 사례의 구성 요소: 리눅스 커널, 데이터베이스. 점검 항목의 근거는 이 사례 같은 공개 보고서입니다.

kubegap 열기

AI 도구와 스크립트용

API 는 키가 필요 없습니다. MCP 서버는 search_incidents, get_incident, list_incidents, get_topic, vocab 도구를 내놓습니다. 사용법은 API 와 MCP.