MGDC 발표 요약 - 리눅스 게임 서버 성능 분석하기 (아이펀팩토리, 김진욱님)
처리량
- 얼마나 많은 일을 하고 있는가?
- 이 서버 동시 접속 몇 명 까지 받을 수 있나?
응답 시간
게임서버는 구성 요소가 많음
접근 방법
- 원하는 것 : 성능 저하가 적을 것
- Valgrind 처럼 수 배 - 수십배의 성능 저하는 쓸 수 없다.
- 프로덕션 환경에서 크래시 할 수 있다면 사용하기 힘들다.
- 원하는 것 : 상시 모니터링
- 원하는 것 : 충분한 데이터
- 실행 속도가 평균이 얼마인지는 별로 안 중요하고 실행 속도의 분포가 중요
- 실행 시간의 분포가 있어야 파악하기 쉽다.
어떻게 측정할까?
- 서버 코드에 측정하는 기능 추가
- 게임 서버 실행 방법을 모니터링
- 필요한 코드를 서버에 추가
- 측정 결과를 얻고 분석 및 코드 개선
- 네트워크 메시지 -> 새이벤트 이벤트#4 이벤트 #3 -- 이벤트 #1 실행 중인 이벤트
- 이벤트 하나하나를 측정
- 모든 분리된 이벤트 단위에서 측정한다.
- 클라이언트 메시지 받고 처리 시작까지 걸린 시간 (큐대기시간)
- 디비 혹은 레디스 요청 전송 / 요청 완료 콜백에 걸린 시간
- 외부 API 요청 / 완료 콜백까지 걸린시간
- 장점
- 개발자가 원하는 수치를 측정한다.
- 외부 API 성능이 궁금하다면 호출 시간 분포나 호출 실패 분포를 측정
- 측정범위를 제어하기 쉽다.
- 원하는 추상화 수준을 고를 수 있다.
- 단점
- 측정 코드를 직접 추가해야한다: 작업량
- 빠진 부분이 있다면 측정 자체가 무의미
- 성능 모델을 직접 만들어야 함
- 측정 방법/내용을 바꾸려면 다시 실행하거나 로드해야함
- 외부에서 관찰
- 리눅스 성능 측정 도구들
- Linux perf kernel 이벤트 카운터 (2.6 이상)
- Linux eBPF 프레임웍의 트레이싱 기능 (v3.18 이상; 가능하면 v4.9 이상)
- 그리고 이를 이용한 스크립트 /성능 모니터링 툴
- BCC : eBPF 프로그램 컴파일러 (python, lua)
- PLY : eBPF 스크립트 툴
- eBPF trace : D-Trace 유사 기능
- eBPF 리눅스 커널 안에서 동작하는 제한된 VM
- BCC: eBPF 프로그램을 생성하고, 해당 프로그램과 통신하는 파이선/루아 스크립트
- 성능 측정이 커널 안에서 이뤄져서 빠르다
- eBPF 할 수 있는 일
- 커널 안의 함수, 시스템 콜, 프로그램 내의 함수를 후킹
- 해당 함수 호출할 때 마다 특정 동작을 하거나 동작을 변경할 수 있다. (패킷 필터링도 가능)
- eBPF 프로그램을 생성하고, 해당 프로그램을 커널에 넣어 실행한 후에 통신한다.
- CPU 프로파일링
- 1초에 수십-수백번 정도 특정 프로세스나 스레드를 살펴 본다.
- 이때 각 CPU가 실행 중인 콜스택을 Key로 map 에 저장
- Map 에 있는 데이터를 FlameGraph로 시각화
- 어떤 질문에 답할 수 있는가
- 어떤 lock을 제일 오래 기다리는가
- Disk 읽기 요청을 어떤 크기로 주로 보내는가
- CPU 수가 작업 수에 비해서 적은가
- 어느 시스템 콜을 제일 많이 하는가
- 어떤 Disk IO가 제일 느린가?
- Kernel - 유저 스페이스 역할 분리
- 데이터를 측정 대상의 커널 영역 안에 안전하게 갈무리
- 장점
- 안전성 - OS나 측정 대상을 크래시 하지 않는다. (eBPF 컴파일러가 보장)
- 시스템/프로그램 재시작 없이 측정 방식 변경
- 3rd 파티 라이브러리 / 프레임웍이 존재
- 단점
- 최신 커널 필요 - 일정 이상의 커널 버전이 필요하다 (센트os7은 커널 추가 설치 필요)
- 측정 대상이 사용 하는 라이브러리 / OS 지식이 필요
- 컴파일러 최적화로 인해서 변경된 콜스택 분석이 어려운 경우가 있다.
- 3~6프로 정도면 측정에 드는 리소스로 인정하고 10프로도 사견으로는 괜찮다.
- 넷플릭스도 10프로 정도 상시로 활용해서 측정한다.