이번부터 Windows 서버 튜닝에 대한 간단한 소개를 하고자 한다. 내가 생각하는 Tuning 시점은 시스템 구축에서 부터 운영이후 폐기할때 까지 신경 써야 하는 부분이라고 생각한다. 아직 미약한 실력이지만 Tuning을 할 수 있는 기본적인 용어에서부터 관리 기법까지 알기 쉽고 편하게 접근하려고 한다.
[Processor]
현재 Quad Core CPU가 탑재된 서버 제품이 나와 있지만 아직까지 대부분의 Site에서 운영되고 있는 CPU 기술은 Dual Core나 Hyper-Threading 기술을 기반으로 운영되고 있는 서벅가 많을 것이다. 물론 간헐적으로 64Bit System을 사용하고 있는 Site가 있지만 여기서의 설명은 주로 Dual Core나 SMP방식의 서버를 대상으로 논할것이다.
CPU는 크게 Core, 레지스터, Cache 3가지로 분류할 수 있다. 또 L1 Cache가 어떤 방식으로 동작하느냐에 따라서 RISK or CISK장비로 구별이 된다. 여담으로 RISK와 CISK구별방법을 살펴보자. 이방 법을 알려면 L1 Cache구조는 간단하다. L1 Cache는 CPU명령 집합(Instruction) + 최근,자주사용하는 명령어 Set을 가지고 있는 두가지 구조의 합으로 이루어져있다. RISK와 CISK의 차이는 CPU 명령어 집합을 어더한 방식으로 가지고 있느냐에 따라서 결정이 된다.
흠... 여기까지 설명하고 나니 다시 지식의 한계에 도달했기 때문에 여담을 접고...^^
CPU에서 또 확인 할 것이 Scalability, 즉 확장성에 대한 구조도 확인해야 한다. 여기서 구조를 설명하는 이유는 간단하다. 기본적인 구조를 알아야 Tuning시에 Bottleneck 구간을 찾아내는데 도움이 되기 때문이다. 에궁... 다시 본론으로 들어가면 CPU Scalability는 H/W 측면과 S/W 측면이 있는데 일단 H/W 측면부터 알아보겠다. H/W측면은 현재 운영서버에 많이 구축되어 있는 SMP방식이냐 아니면 NUMA방식으로 되어 있느냐를 고려하는 관점이다. SMP방식은 뭐 많이 들으셨으리라 생각하지만 NUMA방식은 다소 모르시는 분이 있을 수도 있다는 생각에 잠깐 언급하고 넘어가겠다.
NUMA란 Non Uniform Memory Access란 말로 다른 Node 를 통합하여 사용하는 방법을 말한다. 만약 8Way 장비를 16 Way 처럼 사용하고 싶다면 두개의 8Way 장비를 물리적으로 연결하는 방법을 말한다. NUMA의 핵심 내용은 특정 CPU가 여러개의 Memory에 Access 할 수 있게 하는 기술이다.
여기까지 H/W 기본적인 구성에 대한 설명을 마치고 Bottleneck Check에 Point가 되는 FSB에 대해 말해보고자 한다. CPU연산은 통상 Memory 연산보다 빠르다. 만약 SMP구조에서 동시에 CPU가 여러 요청을 할 경우 모두 Memory에 연산을 위한 요청을 할텐데 이경우 FSB에 병목현상이 발생된다. 이럴경우 FSB 수치에 대한 개념이 필요한데 위에서 그랬듯이 간단한 설명으로 개념만 잡고 넘어 가려고 한다. 왜냐하면 아직 갈길이 멀기 때문에....쿡쿡
위에 명시된 그림을 보면 FSB라고 검은색 표시가 되어 있다. FSB는 Front-side Bus의 줄임말로 Memory입장에서 봤을때 앞단의 Core로 통신하는 통로이기 때문에 FSB라는 말을 붙였다. 이후 BSB라는 용어가 나오는데 위의 설명처럼 Core에서 L1 Cache로 통신하는 경로이다. Tuning을 하려면 OS상의 Counter수치에 의한 접근도 필요하지만 기본적인 용어 정리가 필수 이기 때문이다. 만약 DB서버일 경우에는 Random한 Data를 수집한다고 했을경우 L1 Cache사용율이 떨어진다. 이러한 현상은 Memory Access 하는 효율 증대가 필요하다는 말로 DB서버 성능저하시 FSB 부분에 Bottleneck현상이 있는지도 확인해야 하는 항목이기 때문에 개념정리 및 용어 정리는 필수이다. 이부분에서 Double Edge Clocking, Netburst, FSB 기본 Stepping Level등의 개념또한 추가적으로 필요하지만 이 부분에 대해서는 뒷쪽에 다루도록 하겠다.
Processor 부분에서 튜닝 포인트로 중요하다는 부분이 바로 L2 Cache의 적절한 설정이다. 이 부분은 BIOS Setting에서 이루어 지며 Admin이나 엔지니어가 초기 설정시 간과하기 쉬운 부분이다. L2 Cache의 처리방법에는 크게 2가지 기술이 있다. Write-Through기술과, Write-Back기술이 있다.
● Write-Through L2 Cache - CPU Write to Cache → Cache Write to Memory → Write Ack returned to CPU → CPU ready for next Cycle의 Mechanism으로 처리되는 기술을 말한다. 역쉬 말로 쓰면 무슨말인지 도통... 그리하여 그림으로 간단히 설명하겠다.
위 그림을 보면 TCP 전송과 비슷하다는 느낌을 받을것이다. Write-Through 기술은 TCP 전송방식과 비슷하다고 생각하면 된다. 이러한 기술은 Data전송이 Ross율을 줄이는 이점이 있다. 그리하여 Random한 Data를 처리하는 DB서버나 Java 기반의 Application 사용서버, Exchange서버와 같은 Mail서버에 설정하는 적이 대부분 권고하는 사항이다.
● Write-Back L2 Cache - CPU write to cache → CPU ready for next Cycle → Cache writes to memory의 Mechanism으로 처리되는 기술을 말한다. 이 Mechanism의 특징은 UDP전송처럼 Ack신호를 보내는 처리가 없다. CPU에서 Cache로 전송하고 바로 다음 처리 신호를 기다리는 형태이다. 이러한 설정을 하는 이유는 Static Data를 처리하는 DNC, AD, Web, File Server서버 구축시 이러한 설정을 하며 Web서버 구축시에는 MS에서 L2 Cache 처리 방법을 Write-Back으로 설정하라고 권고하고 있다.
대부분의 운영 Site에서는 전문화된 NT H/W엔지니어서 설치하는 경우보다는 직접 OS Setting이나 H/W Setting을 하는 경우가 있다. Admin으로써 이정도 사항은 Check하는것이 향후 Performance저하로 튜닝이 필요할 때 Bottleneck 요소를 줄여가는데 도움이 되는 사항 이라고 생각되어 간단하게 내용을 살펴 보았다.
Processor에서 다룰 내용중의 마지막을 남겨 두고 있다. 바로 Hyper-Threading기술이다. 대부분의 운영Site에서는 성능 저하의 이유로 Hyper-Threading 적용하지 않은 Site도 있을 것이다. 이러한 Hyper-Threading기술은 Single Core일 경우 효과는 뛰어나다고 할 수 있다. (이론적으로 2배로 뻥튀기 하는 기술이기 때문에.... 실질적으로는 2배의 성능이 나오지는 않는다) 그러나 현재 운영되고 있는 Site 서버 기준으로 보면 Single Core는 사용을 안하고 있는 실정이며 대부분 SMP 방식의 CPU 운영을 하고 있기 때문에 이러한 운영 환경속에서는 Hyper-Threading기술이 오히려 필요 악이 되는 경우가 있다. H/W Vendor 사들이 하는 사항으로는 Web서버일 경우 2Way 장비급에는 약 30%정도 성능 향상이 있다는 보고가 있으며 8Way급 이상이 되는 장비에 적용시 오히려 성능 감소 현상을 느낄수도 있다. 요즘 같은 시대에 Hyper-Threading기술을 적용하여 Performance 향상을 꽤하는 사람이 있을까? 하는 생각도 해보면서... 튜닝에 대한 첫번째 부분을 마무리 하고자 한다. 휴~~