NAVER D2, profile picture
Uploaded byNAVER D2
6,801 views

[231]운영체제 수준에서의 데이터베이스 성능 분석과 최적화

운영체제 수준에서의 데이터베이스 성능 분석과 최적화

Embed presentation

운영체제 수준에서의 데이터베이스 성능 분석 및 최적화 김상욱 Apposha
2 김상욱 • Co-founder and CEO @ Apposha • 성균관대 컴퓨터공학 박사과정 • 4편의 SCI 저널 저술, 6편의 국제학술대회 논문 발표 • 클라우드/가상화 분야 • 멀티코어 스케줄링 [ASPLOS’13, VEE’14] • 그룹 기반 메모리 관리 [JPDC’14] • 데이터베이스/저장장치 분야 • 비휘발성 캐시 관리 [USENIX ATC’15, ApSys’16] • 리퀘스트 중심 I/O 우선 처리 [FAST’17, HotStorage’17]
3 MySQL 대비 5배 성능 상용 제품 대비 1/10 비용 for Apposha?
Contents • DB 트렌드 소개 • OS 수준 분석 및 최적화의 중요성 • DB 성능 관점에서의 리눅스 커널 최적화 4
다양한 오픈소스 DB 활용 증가 5 30 35 40 45 50 55 60 65 70 Jan.2013 Jan.2014 Jan.2015 Jan.2016 Jan.2017 Percentage(%) 오픈 소스 상용 제품 0 50 100 150 200 250 300 350 Jan.2013 Jan.2014 Jan.2015 Jan.2016 Jan.2017 DB-EngineScore MongoDB PostgreSQL Cassandra Redis SQLite Elasticsearch Source : db-engines.com Source : db-engines.com
DB와 OS의 관계 변화 • 과거 • DB를 위한 OS 수준 지원 미비 [CACM’81] • OS 간섭을 최소화 하는 방향으로 전개 (e.g., Oracle) • 현재 • 다양한 OS 인터페이스 제공 • madvise(), fadvise(), ionice(), … • fallocate(), fdatasync(), sync_file_range(), … • OS 기능을 적극 활용한 구현이 주류 • “Nearly all modern databases run through the file system.” [OSDI’14] 6
OS 수준 최적화의 중요성 7 - 실제 리소스 관리/할당의 주체는 운영체제이므로 DB 수준 최적화 만으로는 성능 개선의 한계가 있음 높은 우선순위 낮은 우선순위 하드웨어 데이터베이스
사례 분석 • MySQL “swap insanity” • MongoDB readahead 튜닝 • PostgreSQL autovacuum 설정 • Elasticsearch 로깅 8
사례 1: MySQL “swap insanity” 9 NUMA 아키텍쳐 (Non-Uniform Memory Access) Solution: interleaving via OS interface # numactl --interleave all command Default NUMA allocation https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture https://blog.jcole.us/2012/04/16/a-brief-update-on-numa-and-mysql
사례 2: MongoDB Readahead 튜닝 10 “Set the readahead setting to 0 regardless of storage media type.” CPU Disk
사례 2: MongoDB Readahead 튜닝 11 0 10000 20000 30000 40000 50000 Default Readahead 0 처리량(ops/sec) • Dell Poweredge R730 • 32 cores • 8GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read-only • 10GB dataset • 10 min run 처리량 40%
사례 3: PostgreSQL Autovacuum 설정 12 Free Space Map http://bstar36.tistory.com/308
사례 3: PostgreSQL Autovacuum 설정 13 • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • PostgreSQL v9.5.6 • TPC-C workload • 50GB dataset • 1 hour run 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1 50 100 150 200 250 300 처리량(trx/sec) 클라이언트 수 Default Aggressive AV 처리량 40%
0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 3000 최대응답지연(ms) 경과시간 (초) Default Aggressive AV 사례 3: PostgreSQL Autovacuum 설정 14 최대 2.5초
0 500 1000 1500 2000 2500 0 500 1000 1500 2000 2500 3000 최대응답지연(ms) 경과시간 (초) Default Aggressive AV V12-P 사례 3: PostgreSQL Autovacuum 설정 15 최대 0.1초 최대 2.5초 V12-P: Aggressive AV + Apposha 최적화 엔진
사례 4: Elasticsearch 로깅 16 https://www.elastic.co/guide/en/elasticsearch/guide/current/translog.html
0 1000 2000 3000 4000 5000 Default Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 17 • AWS m4.2xlarge • 8 vCPUs, 16GB RAM • EBS 1000 IOPS • Elasticsearch v5.2 • YCSB workload • Insert-only • 50 concurrent clients 데이터 안전 데이터 손실가능 처리량 4.5X
사례 4: Elasticsearch 로깅 18 Translog Translog .ckp write() + fdatasync() FS Metadata Storage write() + fdatasync() Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata
사례 4: Elasticsearch 로깅 19 Translog Translog .ckp write() + fdatasync() Storage write() + fdatasync() Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata
0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000 Default V12-E v0.1 Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 20 처리량 2X
사례 4: Elasticsearch 로깅 21 Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata Translog Translog .ckp write() Storage write() + fdatasync()
0 1000 2000 3000 4000 5000 Default V12-E v0.2 Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 22 처리량 3X 데이터 안전 데이터 손실가능
Contents • DB 트렌드 소개 • OS 수준 분석 및 최적화의 중요성 • DB 성능 관점에서의 리눅스 커널 최적화 23
DB 성능 관점에서의 리눅스 커널 분석 • 저장장치 I/O 스택 • I/O 우선순위 적용의 어려움 • WAL 로그 쓰기 증폭 현상 • Lock으로 인한 scalability 저하 • CPU 스케줄링 • 멀티코어 로드 밸런싱 문제 24 데이터베이스 운영체제 하드웨어
I/O 우선순위 적용의 어려움 • DB 일반적인 구조 25 Storage Device Operating System T1 Client T2 I/O T3 T4 Request Response I/O I/O I/O Database Database performance * Example: MongoDB - Client (foreground) - Checkpointer - Log writer - Eviction worker - …
I/O 우선순위 적용의 어려움 • MongoDB 실험 결과 26 0 5000 10000 15000 20000 25000 30000 0 200 400 600 800 1000 1200 1400 1600 1800 Operationthroughput (ops/sec) Elapsed time (sec) CFQ Regular checkpoint task • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read:update=50:50 • 12GB dataset • 30 min run • 200 clients
0 5000 10000 15000 20000 25000 30000 0 200 400 600 800 1000 1200 1400 1600 1800 Operationthroughput (ops/sec) Elapsed time (sec) CFQ CFQ-IDLE I/O 우선순위 적용의 어려움 • MongoDB 실험 결과 27 I/O priority does not help • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read:update=50:50 • 12GB dataset • 30 min run • 200 clients
I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 28 Storage Device Caching Layer Application File System Layer Block Layer Abstraction
I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 29 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() admission control
I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 30 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() admission control Block-level Q admission control
Application I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 31 Storage Device Caching Layer File System Layer Block Layer Abstraction Buffer Cache reorder FG FG BGBG read() write()
I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 32 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() FG FGBG Device-internal Q admission control
I/O 우선순위 적용의 어려움 • 각 계층에서의 독립적인 I/O 처리 33 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() FG FGBG BG FG BGBG reorder
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 34 Storage Device Caching Layer Application File System Layer Block Layer Locks Condition variables
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 35 Storage Device Caching Layer Application File System Layer Block Layer Condition variables I/OFG lock BG wait
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 36 Storage Device Caching Layer Application File System Layer Block Layer I/OFG lock BG wait FG wait wait BGvar wake
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 37 Storage Device Caching Layer Application File System Layer Block Layer I/O FG wait wait BGuser var wake FG wait I/OFG lock BG wait FG wait wait BGvar wake
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 (I/O dependency) 38 Storage Device Caching Layer Application File System Layer Block Layer Outstanding I/Os
I/O 우선순위 적용의 어려움 • I/O 우선순위 역전 (I/O dependency) 39 Storage Device Caching Layer Application File System Layer Block Layer I/OFG wait For ensuring consistency and/or durability
리퀘스트 중심 I/O 우선처리 • 솔루션 v1 (reactive) • 전체 계층에서의 우선순위 적용 [FAST’17] • 동적 우선순위 상속 [USENIX ATC’15, FAST’17] • Locks • Condition variables 40 FG lock BG I/OFG BG submit complete FG BG FG wait BG register BG inherit FG BGI/O submit complete wake CV CV CV [USENIX ATC’15] Request-Oriented Durable Write Caching for Application Performance [FAST’17] Enlightening the I/O Path: A Holistic Approach for Application Performance
리퀘스트 중심 I/O 우선처리 41 Caching Layer Application File System Layer Block Layer • 솔루션 v1 (문제점) Synchronization linux/include/linux/mutex.h linux/include/linux/pagemap.h linux/include/linux/rtmutex.h linux/include/linux/rwsem.h linux/include/uapi/linux/sem.h linux/include/linux/wait.h linux/kernel/sched/wait.c linux/kernel/locking/rwsem.c linux/kernel/futex.c linux/kernel/locking/mutex.h linux/kernel/locking/mutex.c linux/kernel/locking/rtmutex.c linux/kernel/locking/rwsem-xadd.c linux/kernel/fork.c linux/kernel/sys.c linux/kernel/sysctl.c linux/include/linux/sched.h linux/include/linux/blk_types.h linux/include/linux/blkdev.h linux/include/linux/buffer_head.h linux/include/linux/caq.h linux/block/blk-core.c linux/block/blk-flush.c linux/block/blk-lib.c linux/block/blk-mq.c linux/block/caq-iosched.c linux/block/cfq-iosched.c linux/block/elevator.c linux/fs/buffer.c linux/fs/ext4/extents.c linux/fs/ext4/inode.c linux/include/linux/jbd2.h linux/fs/jbd2/commit.c linux/fs/jbd2/ journal.c linux/fs/jbd2/ transaction.c linux/include/linux/writeback.h linux/mm/page-writeback.c linux/include/linux/mm_types.h linux/fs/buffer.c Interface mongo/util/net/message_server_port.cpp third_party/wiredtiger/src/evict/evict_lru.c
리퀘스트 중심 I/O 우선처리 • 솔루션 v2 (proactive) 42 Device Driver Noop CFQ Deadline Apposha I/O Scheduler Block Layer Ext4 XFS F2FS VFS Apposha Front-End File System Etc Linux I/O 스택 PageCache - 우선순위 기반 I/O 스케줄링 - 디바이스 큐 혼잡 제어 - 우선순위 기반 쓰기 I/O 제어 - OS 캐싱 효율성 향상
리퀘스트 중심 I/O 우선처리 • V12 성능 최적화 엔진 43 Apposha 최적화 엔진 MongoDB Library PostgreSQL Library Elasticsearch Library V12-M V12-P V12-E - 태스크 중요도, 파일 접근 패턴 분류 Front-End File System I/O Scheduler
0 1000 2000 3000 4000 5000 6000 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 44 V12-M: MongoDB용 V12 엔진 최대 5.2초
0 500 1000 1500 2000 2500 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 45 최대 2.2초 최대 0.1초 V12-M: MongoDB용 V12 엔진
0 5000 10000 15000 20000 25000 30000 35000 1 50 100 150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 46 처리량 30% V12-M: MongoDB용 V12 엔진
리퀘스트 중심 I/O 우선처리 • MongoDB 성능 분석 (LatencyTOP) 47 $ cat /proc/latency_stats | sort –k2rn # blocked total wait max wait kernel call stack 14930242 2688576986 5000 sk_wait_data…SyS_recvfrom 1236442 250490867 40485 jbd2_log_wait_commit…SyS_fdatasync 503473 145763439 5000 futex_wait…SyS_futex 15330 72668185 37287 ext4_file_write_iter…SyS_pwrite64 1329954 57847733 4688 wait_on_page_writeback…SyS_fdatasync 93613 2392472 26378 blkdev_issue_flush…SyS_fdatasync …
리퀘스트 중심 I/O 우선처리 • MongoDB 성능 분석 (SystemTap) 48 $ vi full_backtrace.stp probe kernel.function("filemap_fdatawait_range") { print_backtrace() print_ubacktrace() }
리퀘스트 중심 I/O 우선처리 • MongoDB 성능 분석 (SystemTap) 49 $ stap full_backtrace.stp –d /usr/local/bin/mongod --ldd --all-modules handleIncomingMsgEPv receivedCommand runCommands … waitUntilDurable __session_log_flush __wt_log_flush __wt_log_force_sync __posix_sync sys_fdatasync do_fsync vfs_fsync_range ext4_sync_file filemap_write_and_wait_range filemap_fdatawait_range
WAL 로그 쓰기 증폭 • MongoDB 사례 50 WTLog write() + fdatasync() FS Metadata Storage Step 1. fallocate log file Step 2. write log record Step 3. sync log record Step 4. sync FS metadata fallocate()
WAL 로그 쓰기 최적화 • 솔루션 51 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 Apposha OS V12 엔진 v2 - 로그 선할당 & 재사용 - BG 로그 쓰기 예외 처리 - 로그 쓰기 시 RMW 처리
WAL 로그 쓰기 증폭 • MongoDB 사례 52 WTLog write() + fdatasync() Storage Step 1. fallocate log file Step 2. write log record Step 3. sync log record Step 4. sync FS metadata fallocate()
WAL 로그 쓰기 최적화 • 성능 평가 53 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 1 50 100 150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M V12-M v2 처리량 37%~72% V12-M: MongoDB용 V12 엔진
Lock으로 인한 Scalability 저하 • MongoDB 성능 결과 (60GB dataset) 54 0 1000 2000 3000 4000 5000 6000 7000 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 V12-M: MongoDB용 V12 엔진
Lock으로 인한 Scalability 저하 • MongoDB 성능 결과 (60GB dataset) 55 0 500 1000 1500 2000 2500 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 최대 0.9초 V12-M: MongoDB용 V12 엔진
Lock으로 인한 Scalability 저하 • MongoDB 성능 결과 (60GB dataset) 56 $ cat /proc/latency_stats | sort –k2rn # blocked total_wait max_wait kernel_call_stack 6948352 15336712185 5000 futex_wait…SyS_futex 17116192 2950396149 5000 sk_wait_data…SYSC_recvfrom 132555 422559398 48725 ext4_file_write_iter…SyS_pwrite64 1998336 94252487 5848 wait_on_page_writeback…SyS_fdatasync 1997980 85578077 39318 blkdev_issue_flush SyS_fdatasync 104922 29824666 35976 __lock_page_killable…SyS_pread64
Lock으로 인한 Scalability 저하 • 문제 상황 57 File A write() write() File B write() write() T2 T3 T5 T6 T1 T4
Lock으로 인한 Scalability 최적화 • 솔루션 58 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 V12 엔진 v3 - Range lock for file writing
Lock으로 인한 Scalability 최적화 • 솔루션 59 File A write() write() T2 T3 write() T1 File B write() write() T5 T6 write() T4
0 500 1000 1500 2000 2500 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 V12-M v3 Lock으로 인한 Scalability 최적화 • 성능 평가 60 최대 0.9초 최대 0.13초 V12-M: MongoDB용 V12 엔진
DB 성능 관점에서의 리눅스 커널 분석 • 저장장치 I/O 스택 • I/O 우선순위 적용의 어려움 • WAL 로그 쓰기 증폭 현상 • Lock으로 인한 scalability 저하 • CPU 스케줄링 • 멀티 코어 로드 밸런싱 문제 61 데이터베이스 운영체제 하드웨어
멀티 코어 로드 밸런싱 문제 62 Thread Load Balancing - Wakeup - Create - Exec Thread Thread Thread Thread Thread Thread가 Runnable 상태로 변하는 시점 Global 로드 밸런싱 주기마다 전체의 로드를 맞춤 Pre load balancing Periodic load balancing
멀티 코어 로드 밸런싱 문제 63 Thread Thread Thread 매 주기(HZ 단위)에 idle 한 코어를 찾아서 thread를 내쫒음 Thread Thread Thread Idle 코어가 되는 시점에 바쁜 코어로부터 thread를 끌어옴 Kick load balancing Drain load balancing
• 로드 밸런싱 오버헤드 • 로드 계산 • 매 타이머 HZ or 스케줄러 호출 시 • 타겟 코어 선정 • Drain, Pre, Periodic: Sched-Domain Tree 활용 • Kick: CPU mask 활용 • 마이그레이션 • 마이그레이션 워커를 통해 진행 (수 ms 소모) 멀티 코어 로드 밸런싱 문제 64 CPU cycle 소모 Lock 경쟁 발생
멀티 코어 로드 밸런싱 문제 • 마이그레이션에 의한 지연 65 Lock Lock Unparking Migration Worker Context Switching Current  Migration Worker unLock unlock Parking Migration Worker Schedule Schedule Waiters Waiters Migration Context Switching Migration Worker  Current
멀티 코어 로드 밸런싱 문제 • DB 워크로드 영향 66 DB 태스크 1: Network I/O Storage I/OC Network I/OC DB워크로드는 I/O Intensive 한 Task들의 집합 Network I/O C Storage I/O C Network I/ODB 태스크 2:
멀티 코어 로드 밸런싱 문제 • DB 워크로드 영향 67 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: Pre Load Balance 잦은 Task State 변화로 인한 Pre Load Balancing 발생
멀티 코어 로드 밸런싱 문제 • DB 워크로드 영향 68 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: IDLE IDLE IDLE Pre Load Balance Drain Load Balance IDLE 상태 변화시 로드 밸런싱 수행
멀티 코어 로드 밸런싱 문제 • DB 워크로드 영향 69 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: IDLE IDLE IDLE Pre Load Balance Drain Load Balance Kick Load Balance IDLE 상태 변화시 로드 밸런싱 수행
멀티 코어 로드 밸런싱 문제 • DB 워크로드 영향 70 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: Migration Migration Migration 응답지연 발생
멀티 코어 로드 밸런싱 최적화 • 솔루션 71 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 V12 엔진 v4 - Anticipatory 스케줄링 클래스 - 스마트 마이그레이션 CPU 스케줄러
0 10000 20000 30000 40000 50000 60000 1 50 100 150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M v3 V12-M v4 멀티 코어 로드 밸런싱 최적화 • 성능 평가 (12GB dataset) 72 처리량 1.4X~2.5X V12-M: MongoDB용 V12 엔진
Credits 73 김형준 • 성균관대 박사과정 • 파일시스템 개발 현병훈 • 성균관대 석박통합과정 • CPU 스케줄러 개발 Luis Cavazos • 성균관대 박사과정 • 파일시스템 개발 Mr. K. • 성균관대 석사 • 삼성전자 S/W 엔지니어 • 웹 개발 및 DB 분석 Pedram Khoshnevis • 성균관대 박사과정 • DBaaS 프론트엔드 개발 Mr. J. • 삼성전자 S/W 엔지니어 • DBaaS 백엔드 개발 김환주 • KAIST 박사 • Dell EMC Senior S/W Engineer • I/O 우선처리 설계 정진규 • KAIST 박사 • 성균관대 조교수 • I/O 우선처리 설계 이준원 • Georgia Tech 박사 • 성균관대 교수 • I/O 우선처리 설계 김상훈 • KAIST 박사 • Virginia Tech PostDoc • I/O 상속 설계
74 H http://apposha.io F www.facebook.com/apposha M sangwook@apposha.io

More Related Content

PPTX
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
byNAVER D2
 
PDF
今さら聞けない！ Windows Server 2016 Active Directoryドメインサービス入門
byTrainocate Japan, Ltd.
 
PPTX
S3 整合性モデルと Hadoop/Spark の話
byNoritaka Sekiyama
 
PDF
KafkaとPulsar
byYahoo!デベロッパーネットワーク
 
PDF
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
byAmazon Web Services Korea
 
PDF
マイクロサービス　４つの分割アプローチ
by増田 亨
 
PDF
DockerとPodmanの比較
byAkihiro Suda
 
PDF
AWS CLOUD 2018- Amazon DynamoDB기반 글로벌 서비스 개발 방법 (김준형 솔루션즈 아키텍트)
byAmazon Web Services Korea
 
[135] 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다.
byNAVER D2
 
今さら聞けない！ Windows Server 2016 Active Directoryドメインサービス入門
byTrainocate Japan, Ltd.
 
S3 整合性モデルと Hadoop/Spark の話
byNoritaka Sekiyama
 
KafkaとPulsar
byYahoo!デベロッパーネットワーク
 
쿠키런: 킹덤 대규모 인프라 및 서버 운영 사례 공유 [데브시스터즈 - 레벨 200] - 발표자: 용찬호, R&D 엔지니어, 데브시스터즈 ...
byAmazon Web Services Korea
 
マイクロサービス　４つの分割アプローチ
by増田 亨
 
DockerとPodmanの比較
byAkihiro Suda
 
AWS CLOUD 2018- Amazon DynamoDB기반 글로벌 서비스 개발 방법 (김준형 솔루션즈 아키텍트)
byAmazon Web Services Korea
 

What's hot

PDF
Zabbixのパフォーマンスチューニング & インストール時の注意点
byKodai Terashima
 
PDF
20190320 AWS Black Belt Online Seminar Amazon EBS
byAmazon Web Services Japan
 
PPTX
DeNA の AWS アカウント管理とセキュリティ監査自動化
byDeNA
 
PDF
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...
byAmazon Web Services Korea
 
PDF
AWSのログ管理ベストプラクティス
byAkihiro Kuwano
 
PPTX
MongoDBが遅いときの切り分け方法
byTetsutaro Watanabe
 
PDF
Dockerイメージ管理の内部構造
byEtsuji Nakai
 
PDF
MySQL GTID 시작하기
byI Goo Lee
 
PDF
AWS BlackBelt AWS上でのDDoS対策
byAmazon Web Services Japan
 
PDF
Fluentd vs. Logstash for OpenStack Log Management
byNTT Communications Technology Development
 
PDF
[네이버오픈소스세미나] Pinpoint를 이용해서 서버리스 플랫폼 Apache Openwhisk 트레이싱하기 - 오승현
byNAVER Engineering
 
PDF
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
byNAVER D2
 
PDF
20200930 AWS Black Belt Online Seminar Amazon Kinesis Video Streams
byAmazon Web Services Japan
 
PDF
Bringing Kafka Without Zookeeper Into Production with Colin McCabe | Kafka Su...
byHostedbyConfluent
 
PDF
YugabyteDBを使ってみよう（NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料）
byNTT DATA Technology & Innovation
 
PDF
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
byAmazon Web Services Korea
 
PDF
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
byAmazon Web Services Japan
 
PDF
MySQLアンチパターン
byyoku0825
 
PDF
ヤフー社内でやってるMySQLチューニングセミナー大公開
byYahoo!デベロッパーネットワーク
 
PDF
AWS で Presto を徹底的に使いこなすワザ
byNoritaka Sekiyama
 
Zabbixのパフォーマンスチューニング & インストール時の注意点
byKodai Terashima
 
20190320 AWS Black Belt Online Seminar Amazon EBS
byAmazon Web Services Japan
 
DeNA の AWS アカウント管理とセキュリティ監査自動化
byDeNA
 
PUBG: Battlegrounds 라이브 서비스 EKS 전환 사례 공유 [크래프톤 - 레벨 300] - 발표자: 김정헌, PUBG Dev...
byAmazon Web Services Korea
 
AWSのログ管理ベストプラクティス
byAkihiro Kuwano
 
MongoDBが遅いときの切り分け方法
byTetsutaro Watanabe
 
Dockerイメージ管理の内部構造
byEtsuji Nakai
 
MySQL GTID 시작하기
byI Goo Lee
 
AWS BlackBelt AWS上でのDDoS対策
byAmazon Web Services Japan
 
Fluentd vs. Logstash for OpenStack Log Management
byNTT Communications Technology Development
 
[네이버오픈소스세미나] Pinpoint를 이용해서 서버리스 플랫폼 Apache Openwhisk 트레이싱하기 - 오승현
byNAVER Engineering
 
백억개의 로그를 모아 검색하고 분석하고 학습도 시켜보자 : 로기스
byNAVER D2
 
20200930 AWS Black Belt Online Seminar Amazon Kinesis Video Streams
byAmazon Web Services Japan
 
Bringing Kafka Without Zookeeper Into Production with Colin McCabe | Kafka Su...
byHostedbyConfluent
 
YugabyteDBを使ってみよう（NewSQL/分散SQLデータベースよろず勉強会 #1 発表資料）
byNTT DATA Technology & Innovation
 
마이크로서비스 기반 클라우드 아키텍처 구성 모범 사례 - 윤석찬 (AWS 테크에반젤리스트)
byAmazon Web Services Korea
 
ElastiCacheを利用する上でキャッシュをどのように有効に使うべきか
byAmazon Web Services Japan
 
MySQLアンチパターン
byyoku0825
 
ヤフー社内でやってるMySQLチューニングセミナー大公開
byYahoo!デベロッパーネットワーク
 
AWS で Presto を徹底的に使いこなすワザ
byNoritaka Sekiyama
 

Viewers also liked

PDF
[232]mist 고성능 iot 스트림 처리 시스템
byNAVER D2
 
PDF
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색
byNAVER D2
 
PDF
[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼
byNAVER D2
 
PDF
[221]똑똑한 인공지능 dj 비서 clova music
byNAVER D2
 
PDF
[241]large scale search with polysemous codes
byNAVER D2
 
PDF
[213]building ai to recreate our visual world
byNAVER D2
 
PDF
[246]reasoning, attention and memory toward differentiable reasoning machines
byNAVER D2
 
PDF
[212]big models without big data using domain specific deep networks in data-...
byNAVER D2
 
PDF
[215]streetwise machine learning for painless parking
byNAVER D2
 
PDF
[234]멀티테넌트 하둡 클러스터 운영 경험기
byNAVER D2
 
PDF
[222]neural machine translation (nmt) 동작의 시각화 및 분석 방법
byNAVER D2
 
PDF
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
byNAVER D2
 
PDF
[242]open stack neutron dataplane 구현
byNAVER D2
 
PDF
[225]빅데이터를 위한 분산 딥러닝 플랫폼 만들기
byNAVER D2
 
PPTX
[213] 의료 ai를 위해 세상에 없는 양질의 data 만드는 도구 제작하기
byNAVER D2
 
PDF
인공지능추천시스템 airs개발기_모델링과시스템
byNAVER D2
 
PPTX
[211] HBase 기반 검색 데이터 저장소 (공개용)
byNAVER D2
 
PDF
유연하고 확장성 있는 빅데이터 처리
byNAVER D2
 
PPTX
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
byNAVER D2
 
PDF
[141]네이버랩스의 로보틱스 연구 소개
byNAVER D2
 
[232]mist 고성능 iot 스트림 처리 시스템
byNAVER D2
 
[216]네이버 검색 사용자를 만족시켜라! 의도파악과 의미검색
byNAVER D2
 
[224]nsml 상상하는 모든 것이 이루어지는 클라우드 머신러닝 플랫폼
byNAVER D2
 
[221]똑똑한 인공지능 dj 비서 clova music
byNAVER D2
 
[241]large scale search with polysemous codes
byNAVER D2
 
[213]building ai to recreate our visual world
byNAVER D2
 
[246]reasoning, attention and memory toward differentiable reasoning machines
byNAVER D2
 
[212]big models without big data using domain specific deep networks in data-...
byNAVER D2
 
[215]streetwise machine learning for painless parking
byNAVER D2
 
[234]멀티테넌트 하둡 클러스터 운영 경험기
byNAVER D2
 
[222]neural machine translation (nmt) 동작의 시각화 및 분석 방법
byNAVER D2
 
[223]rye, 샤딩을 지원하는 오픈소스 관계형 dbms
byNAVER D2
 
[242]open stack neutron dataplane 구현
byNAVER D2
 
[225]빅데이터를 위한 분산 딥러닝 플랫폼 만들기
byNAVER D2
 
[213] 의료 ai를 위해 세상에 없는 양질의 data 만드는 도구 제작하기
byNAVER D2
 
인공지능추천시스템 airs개발기_모델링과시스템
byNAVER D2
 
[211] HBase 기반 검색 데이터 저장소 (공개용)
byNAVER D2
 
유연하고 확장성 있는 빅데이터 처리
byNAVER D2
 
[244]네트워크 모니터링 시스템(nms)을 지탱하는 기술
byNAVER D2
 
[141]네이버랩스의 로보틱스 연구 소개
byNAVER D2
 

Similar to [231]운영체제 수준에서의 데이터베이스 성능 분석과 최적화

PDF
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
byPgDay.Seoul
 
PDF
Rankwave MOMENT™ (Korean)
byHyoungEun Kim
 
PPTX
NexGen overview_201705
byCDIT-HCI
 
PPTX
cdit hci zerto '소통하는 세미나' 소개자료(201705)
byCDIT-HCI
 
PDF
[Pgday.Seoul 2019] AppOS 고성능 I/O 확장 모듈로 성능 10배 향상시키기
byPgDay.Seoul
 
PDF
Linux Performan tuning Part I
bysprdd
 
PDF
Rankwave moment™ desc3
bySungwha Shim
 
PDF
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
byAmazon Web Services Korea
 
PDF
[PYCON Korea 2018] Python Application Server for Recommender System
byKwangseob Kim
 
PDF
[PYCON Korea 2018] Python Application Server for Recommender System
byKwangseob Kim
 
PDF
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
byksdc2019
 
PDF
고성능 빅데이터 수집 및 분석 솔루션 - 티맥스소프트 허승재 팀장
byeungjin cho
 
PDF
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
bydevCAT Studio, NEXON
 
PPT
091106kofpublic 091108170852-phpapp02 (번역본)
byTaegil Heo
 
PPTX
OPEN_POWER8_SESSION_20150316
by기한 김
 
PPTX
Linux one brief_edm_202002
byjiyoungkim158
 
PPTX
MySQL_MariaDB-성능개선-202201.pptx
byNeoClova
 
PDF
Tdc2013 선배들에게 배우는 server scalability
by흥배 최
 
PDF
MySQL Deep dive with FusionIO
byI Goo Lee
 
PDF
Fy19 fujitsu ep
by의진 이
 
[Pgday.Seoul 2017] 2. PostgreSQL을 위한 리눅스 커널 최적화 - 김상욱
byPgDay.Seoul
 
Rankwave MOMENT™ (Korean)
byHyoungEun Kim
 
NexGen overview_201705
byCDIT-HCI
 
cdit hci zerto '소통하는 세미나' 소개자료(201705)
byCDIT-HCI
 
[Pgday.Seoul 2019] AppOS 고성능 I/O 확장 모듈로 성능 10배 향상시키기
byPgDay.Seoul
 
Linux Performan tuning Part I
bysprdd
 
Rankwave moment™ desc3
bySungwha Shim
 
AWS CLOUD 2018- Amazon Aurora  신규 서비스 알아보기 (최유정 솔루션즈 아키텍트)
byAmazon Web Services Korea
 
[PYCON Korea 2018] Python Application Server for Recommender System
byKwangseob Kim
 
[PYCON Korea 2018] Python Application Server for Recommender System
byKwangseob Kim
 
초초초 (초고속 초저지연 초연결) 5G IoT 플랫폼 개발 이야기
byksdc2019
 
고성능 빅데이터 수집 및 분석 솔루션 - 티맥스소프트 허승재 팀장
byeungjin cho
 
이승재, 실버바인 서버엔진 2 설계 리뷰, NDC2018
bydevCAT Studio, NEXON
 
091106kofpublic 091108170852-phpapp02 (번역본)
byTaegil Heo
 
OPEN_POWER8_SESSION_20150316
by기한 김
 
Linux one brief_edm_202002
byjiyoungkim158
 
MySQL_MariaDB-성능개선-202201.pptx
byNeoClova
 
Tdc2013 선배들에게 배우는 server scalability
by흥배 최
 
MySQL Deep dive with FusionIO
byI Goo Lee
 
Fy19 fujitsu ep
by의진 이
 

More from NAVER D2

PDF
[211] 인공지능이 인공지능 챗봇을 만든다
byNAVER D2
 
PDF
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
byNAVER D2
 
PDF
[215] Druid로 쉽고 빠르게 데이터 분석하기
byNAVER D2
 
PDF
[245]Papago Internals: 모델분석과 응용기술 개발
byNAVER D2
 
PDF
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
byNAVER D2
 
PDF
[235]Wikipedia-scale Q&A
byNAVER D2
 
PDF
[244]로봇이 현실 세계에 대해 학습하도록 만들기
byNAVER D2
 
PDF
[243] Deep Learning to help student’s Deep Learning
byNAVER D2
 
PDF
[234]Fast & Accurate Data Annotation Pipeline for AI applications
byNAVER D2
 
PDF
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
byNAVER D2
 
PDF
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
byNAVER D2
 
PDF
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
byNAVER D2
 
PDF
[224]네이버 검색과 개인화
byNAVER D2
 
PDF
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
byNAVER D2
 
PDF
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
byNAVER D2
 
PDF
[213] Fashion Visual Search
byNAVER D2
 
PDF
[232] TensorRT를 활용한 딥러닝 Inference 최적화
byNAVER D2
 
PDF
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
byNAVER D2
 
PDF
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
byNAVER D2
 
PDF
[223]기계독해 QA: 검색인가, NLP인가?
byNAVER D2
 
[211] 인공지능이 인공지능 챗봇을 만든다
byNAVER D2
 
[233] 대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing: Maglev Hashing Scheduler i...
byNAVER D2
 
[215] Druid로 쉽고 빠르게 데이터 분석하기
byNAVER D2
 
[245]Papago Internals: 모델분석과 응용기술 개발
byNAVER D2
 
[236] 스트림 저장소 최적화 이야기: 아파치 드루이드로부터 얻은 교훈
byNAVER D2
 
[235]Wikipedia-scale Q&A
byNAVER D2
 
[244]로봇이 현실 세계에 대해 학습하도록 만들기
byNAVER D2
 
[243] Deep Learning to help student’s Deep Learning
byNAVER D2
 
[234]Fast & Accurate Data Annotation Pipeline for AI applications
byNAVER D2
 
Old version: [233]대형 컨테이너 클러스터에서의 고가용성 Network Load Balancing
byNAVER D2
 
[226]NAVER 광고 deep click prediction: 모델링부터 서빙까지
byNAVER D2
 
[225]NSML: 머신러닝 플랫폼 서비스하기 & 모델 튜닝 자동화하기
byNAVER D2
 
[224]네이버 검색과 개인화
byNAVER D2
 
[216]Search Reliability Engineering (부제: 지진에도 흔들리지 않는 네이버 검색시스템)
byNAVER D2
 
[214] Ai Serving Platform: 하루 수 억 건의 인퍼런스를 처리하기 위한 고군분투기
byNAVER D2
 
[213] Fashion Visual Search
byNAVER D2
 
[232] TensorRT를 활용한 딥러닝 Inference 최적화
byNAVER D2
 
[242]컴퓨터 비전을 이용한 실내 지도 자동 업데이트 방법: 딥러닝을 통한 POI 변화 탐지
byNAVER D2
 
[212]C3, 데이터 처리에서 서빙까지 가능한 하둡 클러스터
byNAVER D2
 
[223]기계독해 QA: 검색인가, NLP인가?
byNAVER D2
 

[231]운영체제 수준에서의 데이터베이스 성능 분석과 최적화

  • 1.
    운영체제 수준에서의 데이터베이스 성능분석 및 최적화 김상욱 Apposha
  • 2.
    2 김상욱 • Co-founder andCEO @ Apposha • 성균관대 컴퓨터공학 박사과정 • 4편의 SCI 저널 저술, 6편의 국제학술대회 논문 발표 • 클라우드/가상화 분야 • 멀티코어 스케줄링 [ASPLOS’13, VEE’14] • 그룹 기반 메모리 관리 [JPDC’14] • 데이터베이스/저장장치 분야 • 비휘발성 캐시 관리 [USENIX ATC’15, ApSys’16] • 리퀘스트 중심 I/O 우선 처리 [FAST’17, HotStorage’17]
  • 3.
    3 MySQL 대비 5배성능 상용 제품 대비 1/10 비용 for Apposha?
  • 4.
    Contents • DB 트렌드소개 • OS 수준 분석 및 최적화의 중요성 • DB 성능 관점에서의 리눅스 커널 최적화 4
  • 5.
    다양한 오픈소스 DB활용 증가 5 30 35 40 45 50 55 60 65 70 Jan.2013 Jan.2014 Jan.2015 Jan.2016 Jan.2017 Percentage(%) 오픈 소스 상용 제품 0 50 100 150 200 250 300 350 Jan.2013 Jan.2014 Jan.2015 Jan.2016 Jan.2017 DB-EngineScore MongoDB PostgreSQL Cassandra Redis SQLite Elasticsearch Source : db-engines.com Source : db-engines.com
  • 6.
    DB와 OS의 관계변화 • 과거 • DB를 위한 OS 수준 지원 미비 [CACM’81] • OS 간섭을 최소화 하는 방향으로 전개 (e.g., Oracle) • 현재 • 다양한 OS 인터페이스 제공 • madvise(), fadvise(), ionice(), … • fallocate(), fdatasync(), sync_file_range(), … • OS 기능을 적극 활용한 구현이 주류 • “Nearly all modern databases run through the file system.” [OSDI’14] 6
  • 7.
    OS 수준 최적화의중요성 7 - 실제 리소스 관리/할당의 주체는 운영체제이므로 DB 수준 최적화 만으로는 성능 개선의 한계가 있음 높은 우선순위 낮은 우선순위 하드웨어 데이터베이스
  • 8.
    사례 분석 • MySQL“swap insanity” • MongoDB readahead 튜닝 • PostgreSQL autovacuum 설정 • Elasticsearch 로깅 8
  • 9.
    사례 1: MySQL“swap insanity” 9 NUMA 아키텍쳐 (Non-Uniform Memory Access) Solution: interleaving via OS interface # numactl --interleave all command Default NUMA allocation https://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture https://blog.jcole.us/2012/04/16/a-brief-update-on-numa-and-mysql
  • 10.
    사례 2: MongoDBReadahead 튜닝 10 “Set the readahead setting to 0 regardless of storage media type.” CPU Disk
  • 11.
    사례 2: MongoDBReadahead 튜닝 11 0 10000 20000 30000 40000 50000 Default Readahead 0 처리량(ops/sec) • Dell Poweredge R730 • 32 cores • 8GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read-only • 10GB dataset • 10 min run 처리량 40%
  • 12.
    사례 3: PostgreSQLAutovacuum 설정 12 Free Space Map http://bstar36.tistory.com/308
  • 13.
    사례 3: PostgreSQLAutovacuum 설정 13 • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • PostgreSQL v9.5.6 • TPC-C workload • 50GB dataset • 1 hour run 0 1000 2000 3000 4000 5000 6000 7000 8000 9000 1 50 100 150 200 250 300 처리량(trx/sec) 클라이언트 수 Default Aggressive AV 처리량 40%
  • 14.
    0 500 1000 1500 2000 2500 0 500 10001500 2000 2500 3000 최대응답지연(ms) 경과시간 (초) Default Aggressive AV 사례 3: PostgreSQL Autovacuum 설정 14 최대 2.5초
  • 15.
    0 500 1000 1500 2000 2500 0 500 10001500 2000 2500 3000 최대응답지연(ms) 경과시간 (초) Default Aggressive AV V12-P 사례 3: PostgreSQL Autovacuum 설정 15 최대 0.1초 최대 2.5초 V12-P: Aggressive AV + Apposha 최적화 엔진
  • 16.
    사례 4: Elasticsearch로깅 16 https://www.elastic.co/guide/en/elasticsearch/guide/current/translog.html
  • 17.
    0 1000 20003000 4000 5000 Default Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 17 • AWS m4.2xlarge • 8 vCPUs, 16GB RAM • EBS 1000 IOPS • Elasticsearch v5.2 • YCSB workload • Insert-only • 50 concurrent clients 데이터 안전 데이터 손실가능 처리량 4.5X
  • 18.
    사례 4: Elasticsearch로깅 18 Translog Translog .ckp write() + fdatasync() FS Metadata Storage write() + fdatasync() Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata
  • 19.
    사례 4: Elasticsearch로깅 19 Translog Translog .ckp write() + fdatasync() Storage write() + fdatasync() Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata
  • 20.
    0 500 10001500 2000 2500 3000 3500 4000 4500 5000 Default V12-E v0.1 Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 20 처리량 2X
  • 21.
    사례 4: Elasticsearch로깅 21 Step 1. write log record Step 2. sync log record Step 3. sync FS metadata Step 4. write log metadata Step 5. sync log metadata Translog Translog .ckp write() Storage write() + fdatasync()
  • 22.
    0 1000 20003000 4000 5000 Default V12-E v0.2 Async 처리량 (index/sec) 사례 4: Elasticsearch 로깅 22 처리량 3X 데이터 안전 데이터 손실가능
  • 23.
    Contents • DB 트렌드소개 • OS 수준 분석 및 최적화의 중요성 • DB 성능 관점에서의 리눅스 커널 최적화 23
  • 24.
    DB 성능 관점에서의리눅스 커널 분석 • 저장장치 I/O 스택 • I/O 우선순위 적용의 어려움 • WAL 로그 쓰기 증폭 현상 • Lock으로 인한 scalability 저하 • CPU 스케줄링 • 멀티코어 로드 밸런싱 문제 24 데이터베이스 운영체제 하드웨어
  • 25.
    I/O 우선순위 적용의어려움 • DB 일반적인 구조 25 Storage Device Operating System T1 Client T2 I/O T3 T4 Request Response I/O I/O I/O Database Database performance * Example: MongoDB - Client (foreground) - Checkpointer - Log writer - Eviction worker - …
  • 26.
    I/O 우선순위 적용의어려움 • MongoDB 실험 결과 26 0 5000 10000 15000 20000 25000 30000 0 200 400 600 800 1000 1200 1400 1600 1800 Operationthroughput (ops/sec) Elapsed time (sec) CFQ Regular checkpoint task • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read:update=50:50 • 12GB dataset • 30 min run • 200 clients
  • 27.
    0 5000 10000 15000 20000 25000 30000 0 200 400600 800 1000 1200 1400 1600 1800 Operationthroughput (ops/sec) Elapsed time (sec) CFQ CFQ-IDLE I/O 우선순위 적용의 어려움 • MongoDB 실험 결과 27 I/O priority does not help • Dell Poweredge R730 • 32 cores • 132GB DRAM • 1 SAS SSD • MongoDB v3.2.10 • YCSB workload • Read:update=50:50 • 12GB dataset • 30 min run • 200 clients
  • 28.
    I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 28 Storage Device Caching Layer Application File System Layer Block Layer Abstraction
  • 29.
    I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 29 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() admission control
  • 30.
    I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 30 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() admission control Block-level Q admission control
  • 31.
    Application I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 31 Storage Device Caching Layer File System Layer Block Layer Abstraction Buffer Cache reorder FG FG BGBG read() write()
  • 32.
    I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 32 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() FG FGBG Device-internal Q admission control
  • 33.
    I/O 우선순위 적용의어려움 • 각 계층에서의 독립적인 I/O 처리 33 Storage Device Caching Layer Application File System Layer Block Layer Abstraction Buffer Cache read() write() FG FGBG BG FG BGBG reorder
  • 34.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 34 Storage Device Caching Layer Application File System Layer Block Layer Locks Condition variables
  • 35.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 35 Storage Device Caching Layer Application File System Layer Block Layer Condition variables I/OFG lock BG wait
  • 36.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 36 Storage Device Caching Layer Application File System Layer Block Layer I/OFG lock BG wait FG wait wait BGvar wake
  • 37.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 37 Storage Device Caching Layer Application File System Layer Block Layer I/O FG wait wait BGuser var wake FG wait I/OFG lock BG wait FG wait wait BGvar wake
  • 38.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 (I/O dependency) 38 Storage Device Caching Layer Application File System Layer Block Layer Outstanding I/Os
  • 39.
    I/O 우선순위 적용의어려움 • I/O 우선순위 역전 (I/O dependency) 39 Storage Device Caching Layer Application File System Layer Block Layer I/OFG wait For ensuring consistency and/or durability
  • 40.
    리퀘스트 중심 I/O우선처리 • 솔루션 v1 (reactive) • 전체 계층에서의 우선순위 적용 [FAST’17] • 동적 우선순위 상속 [USENIX ATC’15, FAST’17] • Locks • Condition variables 40 FG lock BG I/OFG BG submit complete FG BG FG wait BG register BG inherit FG BGI/O submit complete wake CV CV CV [USENIX ATC’15] Request-Oriented Durable Write Caching for Application Performance [FAST’17] Enlightening the I/O Path: A Holistic Approach for Application Performance
  • 41.
    리퀘스트 중심 I/O우선처리 41 Caching Layer Application File System Layer Block Layer • 솔루션 v1 (문제점) Synchronization linux/include/linux/mutex.h linux/include/linux/pagemap.h linux/include/linux/rtmutex.h linux/include/linux/rwsem.h linux/include/uapi/linux/sem.h linux/include/linux/wait.h linux/kernel/sched/wait.c linux/kernel/locking/rwsem.c linux/kernel/futex.c linux/kernel/locking/mutex.h linux/kernel/locking/mutex.c linux/kernel/locking/rtmutex.c linux/kernel/locking/rwsem-xadd.c linux/kernel/fork.c linux/kernel/sys.c linux/kernel/sysctl.c linux/include/linux/sched.h linux/include/linux/blk_types.h linux/include/linux/blkdev.h linux/include/linux/buffer_head.h linux/include/linux/caq.h linux/block/blk-core.c linux/block/blk-flush.c linux/block/blk-lib.c linux/block/blk-mq.c linux/block/caq-iosched.c linux/block/cfq-iosched.c linux/block/elevator.c linux/fs/buffer.c linux/fs/ext4/extents.c linux/fs/ext4/inode.c linux/include/linux/jbd2.h linux/fs/jbd2/commit.c linux/fs/jbd2/ journal.c linux/fs/jbd2/ transaction.c linux/include/linux/writeback.h linux/mm/page-writeback.c linux/include/linux/mm_types.h linux/fs/buffer.c Interface mongo/util/net/message_server_port.cpp third_party/wiredtiger/src/evict/evict_lru.c
  • 42.
    리퀘스트 중심 I/O우선처리 • 솔루션 v2 (proactive) 42 Device Driver Noop CFQ Deadline Apposha I/O Scheduler Block Layer Ext4 XFS F2FS VFS Apposha Front-End File System Etc Linux I/O 스택 PageCache - 우선순위 기반 I/O 스케줄링 - 디바이스 큐 혼잡 제어 - 우선순위 기반 쓰기 I/O 제어 - OS 캐싱 효율성 향상
  • 43.
    리퀘스트 중심 I/O우선처리 • V12 성능 최적화 엔진 43 Apposha 최적화 엔진 MongoDB Library PostgreSQL Library Elasticsearch Library V12-M V12-P V12-E - 태스크 중요도, 파일 접근 패턴 분류 Front-End File System I/O Scheduler
  • 44.
    0 1000 2000 3000 4000 5000 6000 0 60 120180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 44 V12-M: MongoDB용 V12 엔진 최대 5.2초
  • 45.
    0 500 1000 1500 2000 2500 0 60 120180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 45 최대 2.2초 최대 0.1초 V12-M: MongoDB용 V12 엔진
  • 46.
    0 5000 10000 15000 20000 25000 30000 35000 1 50 100150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M 리퀘스트 중심 I/O 우선처리 • MongoDB 성능 결과 46 처리량 30% V12-M: MongoDB용 V12 엔진
  • 47.
    리퀘스트 중심 I/O우선처리 • MongoDB 성능 분석 (LatencyTOP) 47 $ cat /proc/latency_stats | sort –k2rn # blocked total wait max wait kernel call stack 14930242 2688576986 5000 sk_wait_data…SyS_recvfrom 1236442 250490867 40485 jbd2_log_wait_commit…SyS_fdatasync 503473 145763439 5000 futex_wait…SyS_futex 15330 72668185 37287 ext4_file_write_iter…SyS_pwrite64 1329954 57847733 4688 wait_on_page_writeback…SyS_fdatasync 93613 2392472 26378 blkdev_issue_flush…SyS_fdatasync …
  • 48.
    리퀘스트 중심 I/O우선처리 • MongoDB 성능 분석 (SystemTap) 48 $ vi full_backtrace.stp probe kernel.function("filemap_fdatawait_range") { print_backtrace() print_ubacktrace() }
  • 49.
    리퀘스트 중심 I/O우선처리 • MongoDB 성능 분석 (SystemTap) 49 $ stap full_backtrace.stp –d /usr/local/bin/mongod --ldd --all-modules handleIncomingMsgEPv receivedCommand runCommands … waitUntilDurable __session_log_flush __wt_log_flush __wt_log_force_sync __posix_sync sys_fdatasync do_fsync vfs_fsync_range ext4_sync_file filemap_write_and_wait_range filemap_fdatawait_range
  • 50.
    WAL 로그 쓰기증폭 • MongoDB 사례 50 WTLog write() + fdatasync() FS Metadata Storage Step 1. fallocate log file Step 2. write log record Step 3. sync log record Step 4. sync FS metadata fallocate()
  • 51.
    WAL 로그 쓰기최적화 • 솔루션 51 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 Apposha OS V12 엔진 v2 - 로그 선할당 & 재사용 - BG 로그 쓰기 예외 처리 - 로그 쓰기 시 RMW 처리
  • 52.
    WAL 로그 쓰기증폭 • MongoDB 사례 52 WTLog write() + fdatasync() Storage Step 1. fallocate log file Step 2. write log record Step 3. sync log record Step 4. sync FS metadata fallocate()
  • 53.
    WAL 로그 쓰기최적화 • 성능 평가 53 0 5000 10000 15000 20000 25000 30000 35000 40000 45000 1 50 100 150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M V12-M v2 처리량 37%~72% V12-M: MongoDB용 V12 엔진
  • 54.
    Lock으로 인한 Scalability저하 • MongoDB 성능 결과 (60GB dataset) 54 0 1000 2000 3000 4000 5000 6000 7000 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 V12-M: MongoDB용 V12 엔진
  • 55.
    Lock으로 인한 Scalability저하 • MongoDB 성능 결과 (60GB dataset) 55 0 500 1000 1500 2000 2500 0 60 120 180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 최대 0.9초 V12-M: MongoDB용 V12 엔진
  • 56.
    Lock으로 인한 Scalability저하 • MongoDB 성능 결과 (60GB dataset) 56 $ cat /proc/latency_stats | sort –k2rn # blocked total_wait max_wait kernel_call_stack 6948352 15336712185 5000 futex_wait…SyS_futex 17116192 2950396149 5000 sk_wait_data…SYSC_recvfrom 132555 422559398 48725 ext4_file_write_iter…SyS_pwrite64 1998336 94252487 5848 wait_on_page_writeback…SyS_fdatasync 1997980 85578077 39318 blkdev_issue_flush SyS_fdatasync 104922 29824666 35976 __lock_page_killable…SyS_pread64
  • 57.
    Lock으로 인한 Scalability저하 • 문제 상황 57 File A write() write() File B write() write() T2 T3 T5 T6 T1 T4
  • 58.
    Lock으로 인한 Scalability최적화 • 솔루션 58 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 V12 엔진 v3 - Range lock for file writing
  • 59.
    Lock으로 인한 Scalability최적화 • 솔루션 59 File A write() write() T2 T3 write() T1 File B write() write() T5 T6 write() T4
  • 60.
    0 500 1000 1500 2000 2500 0 60 120180 240 300 360 420 480 540 600 최대응답지연(ms) 경과시간 (초) Linux Default Best Practice V12-M v2 V12-M v3 Lock으로 인한 Scalability 최적화 • 성능 평가 60 최대 0.9초 최대 0.13초 V12-M: MongoDB용 V12 엔진
  • 61.
    DB 성능 관점에서의리눅스 커널 분석 • 저장장치 I/O 스택 • I/O 우선순위 적용의 어려움 • WAL 로그 쓰기 증폭 현상 • Lock으로 인한 scalability 저하 • CPU 스케줄링 • 멀티 코어 로드 밸런싱 문제 61 데이터베이스 운영체제 하드웨어
  • 62.
    멀티 코어 로드밸런싱 문제 62 Thread Load Balancing - Wakeup - Create - Exec Thread Thread Thread Thread Thread Thread가 Runnable 상태로 변하는 시점 Global 로드 밸런싱 주기마다 전체의 로드를 맞춤 Pre load balancing Periodic load balancing
  • 63.
    멀티 코어 로드밸런싱 문제 63 Thread Thread Thread 매 주기(HZ 단위)에 idle 한 코어를 찾아서 thread를 내쫒음 Thread Thread Thread Idle 코어가 되는 시점에 바쁜 코어로부터 thread를 끌어옴 Kick load balancing Drain load balancing
  • 64.
    • 로드 밸런싱오버헤드 • 로드 계산 • 매 타이머 HZ or 스케줄러 호출 시 • 타겟 코어 선정 • Drain, Pre, Periodic: Sched-Domain Tree 활용 • Kick: CPU mask 활용 • 마이그레이션 • 마이그레이션 워커를 통해 진행 (수 ms 소모) 멀티 코어 로드 밸런싱 문제 64 CPU cycle 소모 Lock 경쟁 발생
  • 65.
    멀티 코어 로드밸런싱 문제 • 마이그레이션에 의한 지연 65 Lock Lock Unparking Migration Worker Context Switching Current  Migration Worker unLock unlock Parking Migration Worker Schedule Schedule Waiters Waiters Migration Context Switching Migration Worker  Current
  • 66.
    멀티 코어 로드밸런싱 문제 • DB 워크로드 영향 66 DB 태스크 1: Network I/O Storage I/OC Network I/OC DB워크로드는 I/O Intensive 한 Task들의 집합 Network I/O C Storage I/O C Network I/ODB 태스크 2:
  • 67.
    멀티 코어 로드밸런싱 문제 • DB 워크로드 영향 67 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: Pre Load Balance 잦은 Task State 변화로 인한 Pre Load Balancing 발생
  • 68.
    멀티 코어 로드밸런싱 문제 • DB 워크로드 영향 68 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: IDLE IDLE IDLE Pre Load Balance Drain Load Balance IDLE 상태 변화시 로드 밸런싱 수행
  • 69.
    멀티 코어 로드밸런싱 문제 • DB 워크로드 영향 69 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: IDLE IDLE IDLE Pre Load Balance Drain Load Balance Kick Load Balance IDLE 상태 변화시 로드 밸런싱 수행
  • 70.
    멀티 코어 로드밸런싱 문제 • DB 워크로드 영향 70 DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: DB 태스크 1: Network I/O Storage I/OC Network I/OC Network I/O C Storage I/O C Network I/ODB 태스크 2: Migration Migration Migration 응답지연 발생
  • 71.
    멀티 코어 로드밸런싱 최적화 • 솔루션 71 프론트엔드 파일시스템 라이브러리 I/O 스케줄러 V12 엔진 v4 - Anticipatory 스케줄링 클래스 - 스마트 마이그레이션 CPU 스케줄러
  • 72.
    0 10000 20000 30000 40000 50000 60000 1 50 100150 200 250 300 처리량(ops/sec) 클라이언트 수 Linux Default Best Practice V12-M v3 V12-M v4 멀티 코어 로드 밸런싱 최적화 • 성능 평가 (12GB dataset) 72 처리량 1.4X~2.5X V12-M: MongoDB용 V12 엔진
  • 73.
    Credits 73 김형준 • 성균관대 박사과정 •파일시스템 개발 현병훈 • 성균관대 석박통합과정 • CPU 스케줄러 개발 Luis Cavazos • 성균관대 박사과정 • 파일시스템 개발 Mr. K. • 성균관대 석사 • 삼성전자 S/W 엔지니어 • 웹 개발 및 DB 분석 Pedram Khoshnevis • 성균관대 박사과정 • DBaaS 프론트엔드 개발 Mr. J. • 삼성전자 S/W 엔지니어 • DBaaS 백엔드 개발 김환주 • KAIST 박사 • Dell EMC Senior S/W Engineer • I/O 우선처리 설계 정진규 • KAIST 박사 • 성균관대 조교수 • I/O 우선처리 설계 이준원 • Georgia Tech 박사 • 성균관대 교수 • I/O 우선처리 설계 김상훈 • KAIST 박사 • Virginia Tech PostDoc • I/O 상속 설계
  • 74.