| [ CnUnix ] in KIDS 글 쓴 이(By): belami (__커피__) 날 짜 (Date): 2002년 3월 20일 수요일 오후 03시 49분 50초 제 목(Title): Re: RAW Socket TCP/IP 예제프로그램좀요~ 1에 대한 생각. 수 만개 connection이 아니라 수 만개 entry입니다. 리눅스건 뭐건 수 만개 connection은 실제로 발생하지도 않을 뿐더러 리눅스의 경우에는 10k 프로젝트도 아직 진행중이죠? (1만개 연결이 불가능합니다. 1만개는 커녕 3~4천개에서 OS 뻗습니다. 2~3년 전 상황이니 지금은 나아졌을지도..) 수만 entry라면 그냥 커널 tcp 테이블에 수 만개의 엔트리가 있을 뿐 연관된 process도 없고 메모리도 table에 필요한 메모리만 약간 있으면 되는 정도이므로 수 만개 entry 있을 수 있습니다. 2에 대한 생각. 대량의 i/o가 수반된 트랜잭션이 아니라면 2초 걸리는 것 자체가 잘못된 것입니다. 오라클은 그렇게 후지지(-_-) 않습니다. db 세션 풀링을 하지 않고 있다면 세션 풀링을 도입하는 것만으로도 2초가 아니라 0.002초로 줄일 수 있을 것입니다. 하나를 돌리면 1초인데 둘을 돌리면 2초가 걸린다면 어플의 문제네요. mutex, semaphonre, java의 synchronized 키워드, 명시적 lock, disk를 통한 ipc 등이 어플에 있으면 그 부분을 들여다보세요. 하나를 돌리는데도 1초 가량이나 걸린다면 sql 과 index의 문제입니다. 제대로 된 index를 사용하면 1초가 아니라 0.001 이하가 나와야 정상입니다. 수십 개로 버벅.. 말씀하시는 것으로 보아 대량 접속을 해보지는 않으신 것 같네요. 대량 접속을 할 때 느려지면 그때는 매우 높은 확률로 disk i/o의 병목입니다. 대량 접속시, 사용하는 메모리를 계산해봤을 때는 부족하지 않는데 이상하게 swapping이 계속 일어날 수 있습니다. OS 파일캐시의 과다입니다. 여유 메모리를 확보하기 위한 OS의 파일캐시 축소, 스피드 업을 위한 DB의 버퍼캐시 증가(95% 이상 히트 목표), Disk 튜닝(활용률 30% 이하 목표)을 해야 합니다. 그런데 가장 좋은 튜닝은... 돈 생각하지 않고 CPU, Memory, Array를 마구 가져다 일단 꽂아보는 것이더군요. -_- 아차 동시 트랜잭션이 궁금하다고 하셨죠. 어플도 모르고 답을 줄 수는 없지만, 유저수 규모가 얼마이든 100을 넘으면 정상적인 케이스는 아닙니다. 100을 넘지 않도록 설계를 해야 제대로 된 것이고요. 실제로는 100은 커녕 50 이하에서 동작하고, 웬만한 경우는 20~30 정도에서 동작해야 합니다. 그 정도에서 동시 세션의 개수가 부족하지 않아야 제대로 설계된 것입니다. 튜닝의 99%는 지표와 모니터링입니다. - 무엇을 측정할 것인가. - 어떻게 측정할 것인가. 두 가지를 하고 나면 튜닝은 99%가 끝난 것입니다. 나머지 1%는 변경하는 일이죠. |