리눅스 모니터링 도구들

회사에서 크롬쓰는데 - 구글 써서 검색하고 클릭하면 세이브... 합니다 - 어째저째 덕덕고 쓰는 중. 처음엔 검색잘 안되는 거 아닌가 싶었는데 잘 찾아줍니다 - 리눅스 시스템 콜써서 디버그 하는 법 찾다보니 나온 리눅스 퍼포몬스 관련 도구들에 관한 내용입니다. 출처는 이미지에 나왔듯이 https://www.brendangregg.com/linuxperf.html. 출처 사이트에서 해당 이미지를 클릭하면 고해상도 이미지가 뜹니다.

리눅스 구조 및 데이타 영역에 따라 사용할 수 있는 도구들을 잘 정리해놨다고 할까요? 사실 나와있는 도구들중 제대로 쓰는 건 10%도 안되겠습니다만. 이 기회에 개인적으로 자주 쓰는 도구들을 정리해보죠.

- top/htop: 가장 대표적인 도구이고 쉽게쓰는 툴입니다. htop의 경우 왜 RHEL에서 기본툴로 쓰지 않는지 궁금할 정도로 강력하고/쓰기 쉽습니다.
- vmstat: 메모리 모니터링할 때 씁니다. top/htop도 메모리 모니터링이 가능합니다만 이건 샘플링 조절이 가능합니다. `vmstat 10 10` 이런식으로
- iostat: IO관련 도구이긴 한데 그닥 쓸모는 없었던듯.
- tracert: route tracing 할때 쓰죠. 어느 게이트에서 병목이 나는지 조사할 때 도움이 됩니다.
- lstopo/lscpu: 모니터링은 아니지만 cpu구조나 캐쉬관련 내용이 필요할 때 도움이 됩니다.
- tcpdump: 통신내용 덤프할 때 쓰는 도구이긴 한데, 쓸일은 없었던듯.
- strace: system call trace할 때 씁니다. 개인적으로, consulting하면서 제일 도움이 되었던 도구중의 하나가 아닌가 싶은데요 - 예를 들자면 - 사용자 A/B가 동일한  상용 소프트웨어를 쓰는데... configuration 이 다르게 나옵니다. shell type 도 같고 내부의 ~/.configure 나 ~/.local을 봐도 별차이가 없는데 왜 이런일이 벌어지나~ strace 를 찍어보니,  ~/.ik_XX.inc 라는 괘상한 hidden folder를 읽고 있더만요. 즉 초기화 내용을 담은 히든 폴더인데 - 메뉴얼에도 안나오는 이걸 어떻게 찾냐 -  strace 가 찾아줍니다. 해당 어플리케이션이 돌아가면서 상호작용하는 내부 시스템콜을 덤프해주고, 이걸 역추적해가면서 어떤 파일들을 열고/읽는지 확인 할 수 있습니다.

오늘은 이 정도로.




Udemy 강좌 research

1년반 정도 전에 udemy에 관한 글을 쓴 적이 있는데 이번에 한 번 더 써볼까 합니다...

예전에 언급했듯이, 강좌의 퀄리티나 수준은 가격만큼이나 들쑥날쑥합니다 - 연말에는 연말세일, 연초에는 연초 세일. 거의 매달 세일 쿠폰이 나오는군요. 눈팅해 놓고 나중에 할인 쿠폰 나올때 구입하곤 합니다.

어쨌거나 -  세상 많이 좋아졌다고 할까요. 90년대 makefile만드는 법을 몰라서 헤매고 있을 때 - 종로서적이나 pc 통신 뒤져봐도 뭐가뭔지 모르겠고 - 결국  이런저런 시행착오를 겪으며 "야매"로 배우게 되곤 했죠. 즉 뭔가 체계적으로 배운다기 보다는 뭔가 이것저것 찔러보면 이런 반응이 나온다~ 는 정도?

물론 유튜브나 stackoverflow에서도 무수한 정보/자료가 나옵니다만, 수업듣는 것 마냥 체계적으로 새로운 내용을 공부할 수 있다는 건 꽤나 편리하군요.

주로 programming lanuage (C++, design pattern)를 배우는 데 쓰긴 했지만, 그외에도 여러 분야가 많습니다 - 대충 찍어보면, regex, assembly, cmake, docker, kubernetes, DB, Linux admin정도? 사실 지금 하는 일의 절반이 Linux admin인지라  야매 vs 정석을 실감하게되는군요.

아쉬운 점은 HPC에 관한 강좌가 거의 없다는 정도? MPI나 openmp를 검색해보면 거의 안나오고 - scientific computig 강좌가 일부 있긴 합니다 - cray를 검색하면 crazy가 나오는 군요 :( 
뭐 High Performance Computing이 워낙 마이너한 분야이다보니 어쩔 수 없는 듯.






AMD EPYC research

회사에 크레이 클러스터가 들어와서 돌려보고 있습니다...

노드당  AMD EPYC 7702 프로세서 듀얼 소켓이 달려서 총 64*2 = 128 (!!!) processor가 붙습니다... 인텔의 경우 노드당 16-32만 쓰다가 갑자기 자릿수가 하나 더 늘다보니 신세계... 군요 - 않좋은 의미로.

대략 6-7년 된 인텔 cpu클러스터가 있어서 속도 비교를 해보고있는데... 느려! 느립니다. 똑같이 256cpu 돌려보면 대략 70-100%정도? 모델에 따라 30%정도 속도가 쳐집니다....!!!

처음에는 노드당 코어가 너무 많다보니 메모리/NIC병목이 나는게 아닌가 싶었는데, cpu제원을 보니 - 느린게 맞네.

인텔 Xeon E5-2680의 경우 코어당 40GFlops정도 나옵니다. 문제는 소켓당 12개정도의 코어가 있는데, 듀얼소켓으로 구성해도 노드당 24개? 정도가 됩니다. 즉 노드당 24*40= 9600GFlops 혹 1TFlops정도 나옵니다. AMD 7702의 경우엔 cpu코어당 32GFlops 정도? 128개니까 노드당 퍼포먼스는 128*32= 4TFlops로 됩니다. 즉 개별 cpu는 느려도 노드 단위로 보면 4x 아니냐...라는 건데 - 미묘하군요.

바꿔얘기하면, 노드당 cpu밀도를 높이다 보니 전력문제등등으로 인해 싱글 코어 파워를 뚝뚝 떨어뜨린 듯 합니다. 실제 소켓당 24/32코어의 경우 50-60GFLOPS도 나오는 걸 보면 AMD가 기술이 없어서 32로 낮춘건 아닌데, 글쎄요, 무슨 이득이 있어서 노드당 코어갯수를 128로 맞춘건지. 게다가 노드당 사용코어를 1/4로 낮추면 터보부스터(?) 덕분인지 연산속도가 x2가 됩니다. 그렇다곤 해도 under-subscription을 굳이 써야할 이유는 없을 듯 하고.

어째 이래저래 KNL의 악몽이... 바꿔 얘기하면 AMD버전의 인텔제온파이라고 할까요. 기존 시뮬레이션 모델이 MPI rank 100개를 썼으면 이젠 400개정도 쓰란 얘긴데 - scalability가 x4로 보장될리도 없고 - rank 수 올려봐야 병렬효율 떨어질텐데 - strong scaling 돌리면서 모델별 sweet-spot부터 찾아야 할 듯.



특허 research

회사에 서류 제출했던게 2018년 여름...?
몇달 후에 변호사 만나서 이런저런 관련서류 제출하고 샤바샤바 ... 담당 변호사가 해당 분야 (deep learning/CNN)에 꽤나 해박해서 놀랐다는 - 그러고 회사 뜬게 2019년.
2020년경 서류에 사인해서 보내라고 연락와서 다시 제출 -  그러고 한참 까먹고 있다가 - 구글 검색해보니 나오네요. 벌써 두달 지났다는.
나왔으면 나왔다고 통보를 해야지 ... 1년에 한번씩 이사를 했더니 주소변경지가 제대로 업데이트되지 않았나 모르겠슴다.

US patent내려다가 WIPO로 방향을 바꾼듯 한데, 뭐 어쨌든 이로서 CV에 한줄 더 (!) 적을 수 있다능.




1 2 3 4 5 6 7 8 9 10 다음