CStory

PyToch Basic 우선 파이토치에서는 Tensor의 구조를 사용한다. 그리고 numpy 기능들을 거의 다 지원한다. Tensor numpy의 ndarray와 비슷하다. import torch t_array = torch.FloatTensor(n_array) 이외의 Data to Tensor, ndarray to tensor방법 등이 있다. GPU 사용 ~.device를 하면 cpu인지 gpu 사용중인지 알 수 있다. if torch.cuda.is_available(): data_cuda = data.to('cuda') data_cuda.device 위의 코드로 gpu사용 가능하면 gpu로 바꾸도 아니라면 cpu를 그대로 출력한다. Tensor Handling view reshape과 비슷하고 ten..

파이토치와 Tensorflow차이 팀플하다 보면 파이토치를 쓸지 텐서플로우를 쓸지 정하는데, 나는 파이토치를 주장하는 편이다. 사실 그 이유는 최근에 자주 사용하는 게 파이토치여서 그렇긴 한데😂 그러면 꼭 둘이 뭐가 다르냐는 질문을 받는다. 그럴 때 답변하기 위한 포스팅이라고 할 수 있다.😎 DCG(Dynamic Computational Graph) Backward에서 자동미분할때 실행시점에서 그래프를 정의하는 방법이다. Define and run 말 그래도 정의하고 실행하는 것이다. 그래프를 먼저 정의 → 실행시점에 데이터를 feed한다. TF, Pytorch Pytorch는 Define by run(DCG)를 사용하여 실행하면서 그래프를 생성하고 Tensorflow는 Define and run으로 실..

가끔 내가 짠 코드도 아닌데 에러 났다고 하고... 그냥 다른 거 하나 고쳐봤는데 디버깅이 되는 어이없는 상황들을 마주하기 쉽다. 이번 포스팅은 그 늪에서 탈출하기 위한 방법들이다. Troubleshooting OOM (Out-Of-Memory) 이런 문제는 왜 발생했는지, 어디서 발생했는지 알기 어렵다... Error backtracking이 이상한데로 갈 때도 있고 메모리 이전 상황을 파악하기도 어렵다. 그러면 이런 문제들은 어떻게 해결할까? 가장 기본적인 방법으로는 Batch Size 줄이고 ⇒ GPU clean ⇒ RUN GPU Util 사용하기 nvidia-smi 처럼 GPU의 상태를 보여주는 모듈이다. Colab 환경에서 GPU상태 보기 편하다. Iter마다 메모리가 늘어나는지 확인할 수 있다..

도커란? 도커를 소개하기 전에 먼저 가상화란 개념이 필요하다. 가상화 등장 배경 개발할 때, 서스 운영에 사용하는 서버에 직접 들어가서 개발하지 않는다. Local환경에서 개발하고 완려되면 Staging서버, Production 서버에 배포한다. 개발을 진행한 local 환경과 Production 서버 환경이 다른 경우가 존재한다. 예를 들면 로컬은 윈도운, 서버는 리눅스일 때이다. 또한 로컬 환경과 서버가 같은 OS여도, 환경변수 등에 의해 서버에 올바르게 작동하지 않을 수 있다. 그래서 다양한 설정들을 README 등에 기록하고 항상 실행하도록 한다. 여기서 만약 운영하고 있는 서버가 많다면, 이 중 하나의 서버가 업데이터 되었다면 나머지 서버도 모두 업데이트를 해줘야한다. 이런 상황에서 서버 환경까..

HDFS 명령어 모음 대부분 리눅스 command와 비슷해서 큰 설명없이도 이해가 쉬웠다. Dir, File 조회 ls hdfs dfs -ls / 파일 출력 lsr hdfs dfs -lsr / 하위 디렉토리 포함하여 파일 출력 du hdfs dfs -du -h / 파일 용량을 확인, h는 사람이 보기 편하게 만들어주는 것이다. hdfs dfs -du -h -s / s 를 붙이면 summary 용량을 확인할 수 있다. cat hdfs dfs -cat filename 파일 내용 출력 text hdfs dfs -text filename 파일 내용 출력하며 압축된 형태도 가능 mkdir hdfs dfs -mkdir dirname dir 생성 head, tail hdfs dfs -head filename hdfs..

Fair Call Queue Client의 요청을 담아놓는 Queue이다. heavy한 클라이언트로 인해 전체 요청의 처리가 늦어지지 않도록 하기 위해 만들어졌다. 이전 방식 FIFO Queue Fair call queue가 도입되기 전에는 FIFO방식의 큐를 사용하였다. 하지만 이러한 방식은 heavy user로 인해 전체 응답 속도를 느리게 만들었다. 그리고 high load를 발생시키면 전체 시스템에 과부하가 걸려 분산 서비스에 대한 공격이 가능하기에 DDoS방식으로 공격이 가능하다. Fair Call Queue 구성 multi-level queue가 multiplxer와 scheduler로 연결되어있다. RPC Scheduler Listen queue에 RPC요청이 도착하면 reader threa..