8con이 올려놓은거 좀 보고 있음.
2004년 7월
- 300kbps, 5600 피드
- App 서버 3대, 웹 서버 3대, DB 서버 2대
(5600 피드 밖에 없는데 그때부터 이미 트래픽 많아서 서버가 많이 있었나??)
2005년 4월
- 5Mbps, 47700 피드
- App 서버 6대, 웹 서버 6대
2005년 9월
- 20Mbps, 109200 피드
2006년
- 115Mbps, 270000 피드, 하루 1억 hit
음... 저 정도 되어도 100메가 선이면 완전 남는건가 (...)
신뢰도 문제
- 사용자의 1/3 이 오류 목격
- Cacti나 Nagios를 사용해서 모니터링
로깅 문제
- 와와 90GB 테이블 -_- (별 수 있냐 ㅋㅋ)
- Executor Pool 사용해서 해결
- 당일 통계는 실시간으로 하고 나머지는 요청할 때 처리
Primary DB 부하
- 느린 INSERT 때문에 읽기도 Block 됨
- read와 read/write를 쪼개기
- master slave 로드 밸런싱
- 느린 쿼리가 복제도 느려지게 하니 찾아내야 함
전체적인 DB 부하
- App 서버에서 DB를 공유 장소로 사용
- DB를 캐시로 썼음 -_-;
- 테이블 크기 제한 4G에 걸리게 되어서 Merge Table 써야 했음
- 다단계 캐싱하기로 해결 (EHCache, Memcached, 마지막으로 DB에)
통계 문제
- 밤에 배치 처리 하는걸로 바꿔도 역시 버벅버벅
- 게다가 마스터 DB에 통계 쓰는게 너무 많음 (Ad, Item, Circulation)
- 2일 전 것은 서브 테이블로 쪼개버림 (Merge Table)
- 복제 걸어놨으면 slave에서 안 쪼개지는 사태 벌어지지 않게 잘 해야함
- 빡시게 사용되는 테이블과 쿼리는 별도 클러스터로 쪼갬
Master DB 뻑나는 문제
- 여기 한 군데 뻑나면 전부 죽는다 (SPOF)
- 살아남은 slave 중 하나가 master가 되도록 할 방법이 쉽지는 않은데..
- DRBD + Heartbeat 써서 블럭 단위로 디스크 복제를 해봤으나 정작 myisamchk가 너무 오래 걸려서 -_-;
- 멀티 마스터로 해결함 (작은 단위로 쪼개면 그리 오래 걸리지 않으니까)
- 피드 데이터 클러스터와 연결 (그러니까 마스터 하나에 데이터 클러스터 집단 하나)
일반적 가이드라인
- DB 부하를 모니터링해라 (Cacti 쓰니 좋더라)
- 하나도 빼지 말고 쿼리 실행 계획을 다 살펴봐라
- 열심히 캐싱할 것
- 성능 프로파일링 해볼 것
환경
- Hibernate 2.1
- Spring
- DBCP
- MySQL 4.1
- Tomcat 5.0.x
JDBC를 써야 되냐고?
- 상황이 괜찮으면 ORM 써라.
- 대신 ORM에서 생성하는 쿼리를 잘 살펴볼 것
- 쫄아서 JDBC 쓰는 우를 범하지 않도록.
- Biggest performance bits라고 써놓은 부분이..
cacheServerConfiguration=true
useLocalSessionState=true
2004년 7월
- 300kbps, 5600 피드
- App 서버 3대, 웹 서버 3대, DB 서버 2대
(5600 피드 밖에 없는데 그때부터 이미 트래픽 많아서 서버가 많이 있었나??)
2005년 4월
- 5Mbps, 47700 피드
- App 서버 6대, 웹 서버 6대
2005년 9월
- 20Mbps, 109200 피드
2006년
- 115Mbps, 270000 피드, 하루 1억 hit
음... 저 정도 되어도 100메가 선이면 완전 남는건가 (...)
신뢰도 문제
- 사용자의 1/3 이 오류 목격
- Cacti나 Nagios를 사용해서 모니터링
로깅 문제
- 와와 90GB 테이블 -_- (별 수 있냐 ㅋㅋ)
- Executor Pool 사용해서 해결
- 당일 통계는 실시간으로 하고 나머지는 요청할 때 처리
Primary DB 부하
- 느린 INSERT 때문에 읽기도 Block 됨
- read와 read/write를 쪼개기
- master slave 로드 밸런싱
- 느린 쿼리가 복제도 느려지게 하니 찾아내야 함
전체적인 DB 부하
- App 서버에서 DB를 공유 장소로 사용
- DB를 캐시로 썼음 -_-;
- 테이블 크기 제한 4G에 걸리게 되어서 Merge Table 써야 했음
- 다단계 캐싱하기로 해결 (EHCache, Memcached, 마지막으로 DB에)
통계 문제
- 밤에 배치 처리 하는걸로 바꿔도 역시 버벅버벅
- 게다가 마스터 DB에 통계 쓰는게 너무 많음 (Ad, Item, Circulation)
- 2일 전 것은 서브 테이블로 쪼개버림 (Merge Table)
- 복제 걸어놨으면 slave에서 안 쪼개지는 사태 벌어지지 않게 잘 해야함
- 빡시게 사용되는 테이블과 쿼리는 별도 클러스터로 쪼갬
Master DB 뻑나는 문제
- 여기 한 군데 뻑나면 전부 죽는다 (SPOF)
- 살아남은 slave 중 하나가 master가 되도록 할 방법이 쉽지는 않은데..
- DRBD + Heartbeat 써서 블럭 단위로 디스크 복제를 해봤으나 정작 myisamchk가 너무 오래 걸려서 -_-;
- 멀티 마스터로 해결함 (작은 단위로 쪼개면 그리 오래 걸리지 않으니까)
- 피드 데이터 클러스터와 연결 (그러니까 마스터 하나에 데이터 클러스터 집단 하나)
일반적 가이드라인
- DB 부하를 모니터링해라 (Cacti 쓰니 좋더라)
- 하나도 빼지 말고 쿼리 실행 계획을 다 살펴봐라
- 열심히 캐싱할 것
- 성능 프로파일링 해볼 것
환경
- Hibernate 2.1
- Spring
- DBCP
- MySQL 4.1
- Tomcat 5.0.x
JDBC를 써야 되냐고?
- 상황이 괜찮으면 ORM 써라.
- 대신 ORM에서 생성하는 쿼리를 잘 살펴볼 것
- 쫄아서 JDBC 쓰는 우를 범하지 않도록.
- Biggest performance bits라고 써놓은 부분이..
cacheServerConfiguration=true
useLocalSessionState=true
