|
순 서 |
| 1. |
Q. |
|
|
A. |
몇가지 예를 들어 보겠다.
| |
| 2. |
Q. |
|
|
A. |
초기 문서는 BigAdmin DTrace page에서 찾을 수 있다. | |
| 3. |
Q. |
|
|
A. |
절대 그렇지 않다. 심지어 어플리케이션을 재시작할 필요도 없다. | |
| 4. |
Q. |
|
|
A. |
DTrace가 비활성화 되있으면 전혀 퍼포먼스 저하가 없다. DTrace 프레임웍은 3만개 이상의 probe를 제공해 주기 ?문에 그중 일부만 사용하면 상대적으로 퍼포먼스 저하가 적고 모두 사용한다면 인지 할수 있을 만큼의 퍼포먼스 저하가 일어난다. 그러나 퍼포먼스 저하가 시스템이 다운될 정도로 심하진 않다. | |
| 5. |
Q. |
|
|
A. |
물론이다. DTrace는 SPARC과 x86 플랫폼 모두에서 완전히 작동한다. 사실 제공되는 데모의 99%는 x86 플랫폼의 랩탑에서 개발이 이루어 졌다. | |
| 6. |
Q. |
DTrace의 Blueprints Book을 만들 계획은 없는가?드인 솔라리스 OS로 업그레이드할때, 그들은 기존의 데이터를 다시 로드하거나, 다시 포멧을 해야합니까? |
|
A. |
우리는 여러가지로 DTrace 교육자료 배포에 대해 생각하고 있다. 현재는 blueprint스타일의 문서들을 모으고 있다(Dynamic Tracing Guide 포함) 만약 blueprint에 대한 아이디어나 꼭 포함되어야할 문서가 있다면 의견을 주면 고맙겠다. | |
| 7. |
Q. |
|
|
A. |
DTrace와 truss(1)은 크게 두가지면에서 다르다. 첫번째로 DTrace가 정보를 모으는 방식은 truss에 비해 상당히 가볍다. 두번째로 DTrace는 프로세스 단위 뿐만 아니라 시스템 전체의 정보를 제공한다. 좀 더 자세히 설명을 해보겠다. truss(1)는 프로세스의 시스템 콜을 추적하여 주고 proc(4) 파일 시스템을 이용하여 정보를 모은다. /proc는 기존의 디버깅 유틸리티들을 위해 디자인 되어 졌고 기본적으로 프로세스의 동작을 잠시 멈추면서 정보를 얻어 온다. 프로세스를 중단시키고 다시 실행 시킨다는 면에서 퍼포먼스의 저하가 있다. 추적 프레임웍으로써 DTrace는 truss의 방식과는 조금 다르게 동작한다. DTrace는 시스템의 다양한 통로로 동적으로 작업을 수행하여 자료를 버퍼에 저장시킨다음 사용자 영역으로 복사한다. 그러므로 DTrace로 집입할때 코드의 흐름이 잠시 멈추게 되지만 thread나 process차원에서는 프로세스가 정지했는지를 전혀 알지 못한다. 그러므로 DTrace와 /proc 기반의 truss와는 퍼포먼스의 영향이 완전히 틀리다 두번째로 다른점은 DTrace는 시스템의 모든것을 관찰 할 수 있다는 것이다. DTrace는 D 라는 스크립트 언어를 통해 프로그램되어질 수 있다. 그러므로 truss같이 command-line의 명령 뿐만 아니라 복잡한 커맨드도 입력이 가능하다. Dynamic Tracing Guide Chapter 1 을 본다면 DTrace로 turss의 간단한 버전을 구현해 놓은 것을 볼 수 있다. DTrace proc, syscall provider가 /proc가 할 수 있는 일과 거의 유사하게 동작이 가능하므로 이러한 provider를 조합하여 i/o나 cpu, vm 통계, 유저 함수 나 다른 모든 정보를 볼 수 있다. 또한 시스템 전체, 프로세스 단위, 파일 단위 등 원하는 단위의 관찰도 마음대로 할 수 있다. DTrace는 일반 적인 목적에 쓰일 수 있고 기본적인 문제에 대한 해답을 줄 수 있는 프로그래밍 가능한 장치이다. 동시에 truss(1)는 아직 문제 해결에 쓰임새가 많은 유틸리티이다. 특정 분야에서는 truss가 아주 유용하게 쓰일 수 있을것이다. | |
| 8. |
Q. |
내 어플리케이션에 무슨 문제가 있는지 모르겠습니다. 메모리, io, cpu에 의존적이진 않습니다.(vmstat, iostat, mpstat정보를 봤을때) DTrace로 병목현상을 찾기 위해선 어디서 부터 시작해야 합니까? sched provider에 대해 간략히 일어 봤지만 아직 잘 모르겠습니다. 적당한 조언을 부탁드립니다. |
|
A. |
중요한 점은 당신의 어플리케이션이 이러한 물리적 리소스들중 하나에만 의존적이지 않는가? 입니다. (퍼포먼스 측면에서 봤을때) 가장 이상적인 어플리케이션은 오직 하나의 물리적 리소스에만 의존하는 것입니다. 왜냐하면 한가지 물리적 리소스에만 의존적인 어플리케이션의 성능향상은 단순히 그 물리적 리소스의 제한을 해결해 주는 것 만으로 문제 해결이 가능하기 때문입니다. 보통의 일반적인 어플리케이션에서 아마 당신은 cpu 의존적이 길 원할 것입니다. 만약 당신의 어플리케이션이 cpu 의존적이지가 않다면 문제는 간단합니다. 왜 당신의 어플리케이션은 cpu 의존적이지 않습니까? 이 질문에 답하기 위해선 sched provider를 사용하여 왜 당신의 어플리케이션의 cpu를 양보하는지 알아보면 됩니다. sched provier에 관해서는 Guide에서 자세히 알아보기로 하고 여기선 간단히 예만 제시 합니다. # dtrace -n sched:::off-cpu '/execname == "my_app"/{@[ustack()] = count()}' 이 결과로 문제점을 찾을 수 있을것이고 그 문제 또한 DTrace로 해답을 얻을 수 있을 것입니다. DTrace의 기능은 실로 놀랍습니다. 파워풀한 DTrace의 기능을 직접 경험해 보시기 바랍니다. | |
| 9. |
Q. |
|
|
A. |
이러한 일을 위해 더 좋은 툴은 libumem(3LIB)이라는 Solaris 10의 새로은 메모리 할당자이다. umem_debug의 멘페이지를 참고하기 바라고 http://blogs.sun.com/roller/page/ahl/?anchor=solaris_10_top_11_20 에서도 정보를 찾을 수 있을 것이다. Purify와는 다르게 libumem은 아주 작은 퍼포먼스 저하로 동작이 가능하다. gcore와 ::findleaks를 사용하여 현재 동작하는 사용자 어플리케이션의 메모리 누수 현상을 잡아 낼 수 있다. DTrace또한 그만의 역할이 있다. libumem을 사용하면서 메모리 누수나 에러 의 원인에 대한 가설을 세울 수 있을 것이다. 그때 DTrace를 이용해서 빠르게 가설을 검증해 볼 수 있다. DTrace와 libumem은 좋은 팀이다. 이 둘을 이용하면 빠르게 문제 현상을 진단 할 수 있다. | |
| 10. |
Q. |
|
|
A. |
DTrace는 보안툴과 별다른 충돌이 없으므로 별 걱정없이 둘다 돌리는 것이 가능하다. DTrace는 독립적인 추적방법을 사용하므로 DTrace가 사용되지 않는 시스템은 아예 인스톨되지 않은 상태와 같다. DTrace가 disable되었을때의 퍼포먼스 영향은 0이다. 그러므로 DTrace를 선택적으로 사용한다면 그에 따란 퍼포먼스 저하가 생기게 될것이다. 보안 종사자들은 Solaris Dynamic Tracing Guide의 Security 챕터를 읽어 보길 권한다. 여기서 DTrace의 security 속성들에 대해 기술하였다. DTrace에 대한 일반 사용자에게는 상당히 제한적이다. 또한 DTrace 프로그램의 오류가 시스템을 다운 시킬 수도 없다. |
날씬한곰의 블로그 | 날씬한곰
http://blog.naver.com/hyun43/40013617959 
댓글 없음:
댓글 쓰기