한국어 English 日本語简体中文繁體中文 Deutsch ไทย Tiếng Việt Русский Português (Brasil)Español Bahasa Indonesia

fsync 폭주 fsync storms

원인 ID dk-fsync · 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·DB 인프라

그림과 실험이 있는 원본 카드로 열기 →

데이터를 “확실히” 디스크에 쓰도록 요청하면 디스크에 따라 한 번에 0.1ms~수십 ms가 걸리고, 몰리면 대기열이 길어집니다.

왜 정기 저장·로그아웃 러시로 확실한 쓰기 요청이 몰림 → 그러면 디스크 대기열이 길어짐 → 화면에서는 저장 시각마다 렉, 로그아웃·채널 이동 지연

증상: 뚝뚝 끊김, 입력 지연
요인: 정체, 지연
누가 겪나: 서버 전체
언제: 일정한 주기로, 사람이 몰릴 때
담당: 주 담당 게임개발팀·서버 개발 · 함께 인프라팀·서버 인프라, 인프라팀·DB 인프라
게임개발팀 할 일: 저장 묶어서 한 번에(여러 저장을 fsync 한 번으로), 저장 시각 분산.
인프라팀 할 일: 서버 장비·OS: 전원 보호 기능이 있는 서버용 SSD, 디스크 대기열 길이·fsync 지연 모니터링. DB 장비: 저장이 DB로 가면 DB 로그 디스크도 같은 SSD로, 커밋 지연 모니터링.
수치 감각: 한 번에 걸리는 시간은 장비마다 다르지만 대략 서버용 SSD(전원 보호 기능) 0.1ms, 보통 SSD 1~수 ms, 클라우드 디스크 1~2ms, HDD 10ms 이상. 한 스레드가 하나씩 기다리면 HDD는 1초에 100번도 못 합니다.
그래프에서는: 일정 주기로 튐 · 디스크 대기열 길이, 플러시·쓰기 지연
확인할 곳: iostat -x 1의 f/s·f_await(디스크가 처리한 플러시 수와 걸린 시간), w/s·aqu-sz·w_await를 정기 저장·로그아웃 시각과 겹쳐 봄. 예전 sysstat은 aqu-sz를 avgqu-sz로 표시함. 클라우드 디스크는 EBS의 VolumeQueueLength·VolumeAvgWriteLatency를 봄
이러면 맞음: 저장 시각·로그아웃 러시마다 플러시 수와 대기열 길이가 함께 솟고 w_await·f_await가 평소의 몇 배가 됨. 그때 저장·채널 이동이 늦어짐
이러면 아님: 저장·로그아웃과 상관없는 시각에 대기열이 솟으면 백업·압축(dk-backup)이나 IOPS 한도(dk-iops). 플러시 수는 그대로인데 느려지면 버스트 크레딧 소진(dk-burst) 쪽
확인 수단: 인프라 도구로 확인(게임 코드 불필요)

출처

fsync(2) — Linux manual page Linux man-pages
fsync는 디스크 캐시까지 비우고 장치가 완료를 알릴 때까지 블록
Reliability (PostgreSQL Documentation) PostgreSQL
일반 SATA 디스크와 많은 SSD는 정전에 날아가는 쓰기 캐시를 가져, 확실한 저장에는 배터리·전원 보호가 있는 캐시가 필요
Amazon EBS General Purpose SSD volumes AWS
클라우드 기본 디스크(gp3) 지연은 한 자릿수 ms, io2 Block Express는 16KiB I/O 평균 500µs 미만
Designs, Lessons and Advice from Building Large Distributed Systems (LADIS 2009 keynote) Google
HDD 탐색 한 번 10ms
iostat(1) — Linux manual page sysstat
-x: f/s·f_await(디스크가 처리한 플러시 요청 수와 평균 시간), w/s, w_await, aqu-sz(예전 이름 avgqu-sz)
Amazon CloudWatch metrics for Amazon EBS AWS
VolumeQueueLength(완료를 기다리는 요청 수), VolumeAvgWriteLatency(1분 평균 쓰기 지연, Nitro 인스턴스)

fsync 폭주 fsync storms

출처

함께 보면 좋은 원인

같은 층: L11 디스크

같은 증상(뚝뚝 끊김)의 다른 층 원인