What limit Mysql's performance?
CPU 포화도
메모리의 많은량의 데이터를 계산할때
I/O 포화도
네트워크나 하드에서읽어오는게 많을때
component의 시스템 사용 한계를 알아볼때
"컴포넌트 문제야? 아니면 시스템이 컴포넌트한태 잘못된거 요구하는거 아냐?"
라고 물어보자
How to Select CPUs for MySQL
Which is better: fast cpu or many cpu?
일반적으로 fast cpu가 낮다
1.왜? mysql은 하나의 쿼리를 병렬로 돌릴수 없걸랑
2.hyperthead로 인해 물질 1개의 코어를 가상의 2개의 코어로 OS
스케쥴링 할수 있기 때문에
3.레플리케이션에서도 fast 가좋음
레플에서는 cpu 가 문제가 아니라 네트워크 보틀넥이 문제가됨
목표
low latency(fast response time)
fast cpu
high throughput
많은 쿼리를 한번에 돌리면 성능이 높아 짐으로
many cpu
cpu 확장
oltp 환경에서 어느정도의 규모가 커지면
엔진 자체의 락을 최적화 할수없다
즉 일을 빠르게 처리 하는방법 밖에 존재하지 않는대
그말은 즉 더 빠른 fast cpu를 서야 한다는 뜻
동시성 이슈
logical concurrency issues
자원에 대한 경쟁(table or row lock)
1.다른 storage enegine 을 쓰거나
2.change server configuration
3.different locking hint
4.change transaction isolation levels
interal concurrency issues
자원에 대한 경쟁(semaphores, access to pages bufferful)
1.change server setting
2.change os system
3.chage hardware
하드웨어 교체전에 mysql 버전 먼져 올라라
*power 전략이 cpu의 클락속도를 많은 차이 나게 한다.
*4개의 cpu가 x4의 성능을 내는건 아니다.
1개의 cpu가 풀로 돌면 다른자원에 락을 건다
Random I/O에서 문제가 생기면 ram 을 늘려라
Write
buffer 가 write 를 딜레이 시킬수는 있지만 결국 디스크에 써야 한다.
buffer의 장점
Many writes, one flush
100개를 한번에 쓰는게 빠르다
I/O merging
비슷한 애들끼리 변경 사항을 메모리에 저장하다가 한번에 쓰는게 빠르다
write-ahead logging strategy.
랜덤으로 여러곳에 쓰면 오래 걸리니까 걍 로깅으로 쓰고 나중에 처리
working set
실제 작업에 자주 사용되는 데이터의 량
워킹셋 보다는 메모리가 커야된다!
만약 작다면 swap 이 자주 일어나고 I/O문제로 보일수 있다
Finding an Effective Memory-to-Disk Ratio
벤치 마크를 통해 cache miss rate로 결정한다.
그럼 cache miss는 어느 정도가 적당하냐?
그건 그때 그떄 다르다.
*20G의 데이터중 16G메모리를 사용하는대
데이터를 2배로 늘린다고 할때 메모리도 2배하면 똑같은
성능일까? 당근아니다....
Choosing Hard Disks
메모리만 늘리면 성능이 좋아질까 아니다!
write의 경우 I/O에 영향을 받는다.
대부분의 리스판스 타임의 속도는 하드 디스크의 속도에 비례한다
고려사항
1.storage capacity
문제가 없다
있다면 작은애들을 모아 RAID로 구성해라
2.transper speed
3.access time
4.spindle rotation speed
Solid-State Storage
1.하드보단빠르다
2.write보다 읽기가 빠르다
P401
