stone92김경민허접한 지식이지만 제 의견을 말씀드리겠습니다.
시스템 부하에 대한 접근 방법에 약간은 오류가 있지 않나 싶습니다.
iostat상에서 보이는 것은 실제로 커널에서 처리하고 있는 실시간의 전송데이터에 대한 내용이므로 이것을 누적을 시키시면 안됩니다.
말그대로 IO를 처리했다(혹은 처리중)는 것이니깐요.
실제로 디스크의 IO는 iostat 내용중에서 상단에 보이는 %iowait을 보셔야 합니다.
서비스를 하는 서버는 상태들이 지속적으로 변하므로 실시간으로 변경되는 데이터는 모아서 보셔야 정확한 데이터를 찾을 수 있습니다.
즉 커널에서 IO입출력에 대한 대기를 얼마나 하느냐 그리고 그 IO대기를 시키는 프로세서가 뭔지
그 프로세서가 어떤 작업을 하는지를 살피는것이 우선이라고 생각합니다.
cpu,disk io,memory,mysql status,apache status 등을 계속 누적해 둬야 실제로 부하가 걸리는 부분을 찾을수 있을것 같습니다.
그리고 리눅스 시스템에서 가장 중요한 변수로 작용이 되는 메모리에 대한 부분이 빠져있어서 아쉽습니다.
리눅스 커널은 프로그램 동작시 처음에 디스크로 부터 읽어서 메모리에 올려두고 사용하기 때문에 메모리가 부족한 경우
디스크에 페이지 캐시를 저장해두고 메모리가 다시 사용이 가능한 시점에 다시 메모리에 올려서 작업을 하는것으로 알고 있습니다.
이 부분이 왜 중요하냐면 2cpu같은 접속자가 많은 사이트의 경우 동시에 많은 요청이 들어오면 그만큼 메모리 사용이 많아 질것이고
당연히 메모리가 부족해지면 커널은 디스크에 swap 하게 됩니다.
정확하게 2cpu 서버를 확인해보지 못해서 모르겠지만 예전에 올려주신 2cpu 상태를 보면 swap영역을 꽤 사용하고 있습니다.
따라서 2cpu나 기타 다른 서버들도 메모리 사용 부분을 먼저 체크해 보시는게 좋을 것 같습니다.
그리고 저번에 말씀드린대로 DB 테스트 끝나면 결과 내용 한번 올려드리겠습니다.
그리고 제가 알기로는 컨트롤러에 달려있는 캐시메모리도 컨트롤러의 프로세서가 리눅스커널과 비슷하게 동작하는것으로 알고있습니다.
따라서 캐시라는것은 말그대로 입출력 성능을 늘리기 위한 저장소의 개념으로 보시는게 맞지 않을까 싶습니다.
반복되는 데이터에 대한 처리는 캐시에 저장된 내용으로 cpu가 아닌 컨트롤러에서 함으로 빠른 성능과
cpu의 처리비용을 내리는 을 내는 역할로 알고 있습니다.
결국 BBU가 없는 캐시 메모리는 결국은 시스템fail날 경우에 날아가는것은 매한가지일 겁니다.
또한 가득차게 되면 데이터를 다시 덮어쓰게 될 것이구요.
저는 주로 Raid를 안정성 위주로 사용을 해서 실제로 성능이 어떻게 잘 나오는지에 대해서는 관심이 없어서
저도 정답인지 아닌지 모르겠습니다.^^
PS. 시스템 좀 사랑해 주십시요 너무 빡세게 굴리시는거 같아서 서버들이 불쌍합니다.ㅎㅎ
다른 누적값들은 언급하신 것처럼 크게 의미 없다고 생각하기에 전혀 참고하지 않습니다.
swap의 경우 apache가 같이 돌고 있기 때문에 일부 사용을 하고 있지만, 1G 미만입니다.
메모리를 더 적극적으로 쓰게 setting을 바꾸면 swap은 줄어들겠지만,
그런 경우에는 안정성의 문제가 있어서 1G 정도는 메모리가 비어 있도록 설정을 해둔 것 입니다.
apache가 다른 서버로 분리되면 메모리 사용량은 5-6G 정도로 줄어들게 될 것이구요.
설정을 통해 swap을 줄일 수는 있지만,
줄이는 경우 예상치 못한 kernel panic이나 reboot의 문제가 있을 수 있어서 (실제로 그랬습니다)
메모리를 어느정도는 남겨두게 하기 때문에, swap을 더 줄이지 못하고 있으며
HP 서버의 메모리 증설은 돈~~~ 때문에 못하고 있습니다.
4장에 32G 꼽으면 메모리 type이 달라져서 금액대가 천문학적으로 올라가서 서버 1대값이 나옵니다.
가성비가 없는 일이라, 16G 메모리에서 다 해결해야 합니다.
프로스세를 모니터링 하는 방법도 있지만,
웹서버의 경우 돌아가는 프로그램이 몇개 안되기 때문에
몇년동안 꾸준히 프로그램의 설정을 변경하면서 테스트를 해봤고 그 결과값들을 반영해 둔 것 있고
apache를 2.4.4 event mpm으로 바꾸면서 전체적으로 메모리 사용이 줄어든 측면도 있습니다.
반복되는 데이터가 웹서버의 경우에는 php 프로그램과 빈번하게 호출되는 이미지 버튼 같은 것들과
db의 정보들 입니다. db 정보는 가능하면 cache가 되게 코드를 수정해 두었구요. 물론 삽질 튜닝 입니다.
그결과로 파일서버에서 이미지를 가져오고 프로그램의 대부분을 cache에 담아두기에 충분한 경우에는
disk i/o가 현저하게 떨어지는 것 같습니다. 웹서버로만 쓰이는 서버들이 그런 상황이죠.
생각날 때마다, 서버들을 하나씩 갈아 엎으면서 테스트 하면서 수정중입니다.
지난주말 DB 서버 하나에서, Read_wrtn/s가 5만을 넘었습니다.
그래서 사랑하는 마음으로 1G 캐쉬가 있는 고성능 컨트롤러와 CPU를 수배중입니다.
http://2cpu.co.kr/bbs/board.php?bo_table=buy&wr_id=3929
http://2cpu.co.kr/bbs/board.php?bo_table=buy&wr_id=3928
PS. 서버들은 돈 값을 해야 합니다. 하드에 불이나지 않도록 raid 카드라는 선물도 하사 했습니다.
이정도면 충분히 넘치도록 사랑하고 있는 것 입니다.
달라지는 것은
CPU가 E3-1220에서 x5570으로 변경되면서 QPI가 5에서 6.4로 변경되고
Memory Bandwidth도 21Gb/s에서 32Gb/s로 높아지게 되고,
메모리도 16G에서 24G로 늘어나게 되어, 더이상 swap을 안써도 될 것 입니다.
Raid도 P212/256mb에서 LSI MegaRaid 9265-8i로 변경 됩니다.
캐쉬램이 256mb에서 1G로 크게 늘어나게 되고, 프로세서도 듀얼코어로 개선 됩니다.
HDD도 SATA 2개를 10으로 묶는 것에서
SATA 2개와 킹맥스 240GB SSD 2개를 raid 1으로 묶어서 사용할 것이구요.
돌려봐야 하겠지만, Wrtn/s는 크게 줄어들고, Read/s는 더 높아질 것 같으며
전반적인 성능도 크게 개선될 것이라고 봅니다.
==
장기적으로는
슈마 6016T를 DB서버 HP DL120 G7을 웹서버로 하는 2대로 운용할 예정이고
2대로 운용하면 동시접속 1,600명까지는 전혀 문제 없을 것이라고 봅니다.
너무 서버를 사랑하기 때문에, 식스팩이 생길 수 있게 강훈련을 하는 것 입니다^^