세상의 모든 Software 지식을 정리

Initial Mark Phase : 싱글 쓰레드에서만 사용한다. 애플리케이션이 중지되고 애플리케이션에서 직접 Reference(Root set에서 한 단계의 Reference관계)되는 Live Object 만 구별한다. Suspend 상태지만 빠르다. Concurrent Mark Phase 단계 : 싱글 쓰레드에서만 사용한다. 애플리케이션은 수행되고, GC Thread외 Working Thread는 애플리케이션 수행이 가능하다. Initial Mark Phase에서 선별된 Live Object가 Reference하고 있는 object를 추적해 Live여부를 구별한다. Remark Phase 단계: 멀티 쓰레드가 사용되며 애플리케이션이 중지된다. 이미 Marking된 오브젝트를 다시 추적, Live 여부 확정, 모든  Resource를 투입한다. Concurrent Sweep Phase 단계 : 싱글쓰레드만 사용한다. 애플리케이션은 수행되고 최종 Live로 판명된 오브젝트를 제외한 Dead Object를 지운다. 단, sweep 작업만하고 Compaction작업은 수행 안한다.항상 Compaction은 Heap의 Suspend를 전제로 하는데 반복된 Sweep은 단편화를 유발한다. 때문에 Free List를 사용하여 단편화를 줄이는 노력을 한다.

DataLoader클래스란? 데이터를 배치로 만드는 작업을 돕는 유틸 클래스로, 배치 데이터를 만드는 여러한 복잡한 작업을 추상화 한다. 해당 클래스는 파이토치의 utils 모듈에 위치한다. 또한 tochvision과 torchtext를 제공한다. 이 두 클래스는 이미지 분석과 자연어 처리를 다룰 때 사용한다.

도커 컨테이너마다 자체적으로 네트워크 스택을 갖추고 있다. 이는 리눅스 커널의 네트워크 네임스페이스를 통해 제공되는 곳으로, 컨테이너 마다 net 네임스페이스에 대한 인스턴스가 새로 생성되기 때문에 다른 컨테이너나 외부에는 드러나지 않고 해당 컨테이너 내부에서만 사용된다. 1. docker0 브릿지 docker0 브릿지는 도커 네트워킹에서 가장 기본적인 기능을 제공한다. 도커서비스가 구동할 때마다 호스트 머신에 리눅스 브릿지가 생성된다. 이렇게 생성된 브릿지는 컨테이너의 인터페이스를 통해 통신하며, 외부에 대한 프록시 역할도 한다.  한 호스트에서 구동하는 여러 컨테이너는 리눅스 브릿지를 통해 서로 통신한다. docker0는 네가지 모드를 제공하며, 다음과 같이 --net 플래그를 통해 설정한다. --net=default: 컨테이너 끼리 연결하기 위한 브릿지로 디폴트 브릿지를 사용한다. --net=nonde: 컨테이너를 완전히 격리된 형태로 구동하며 네트워크에 연결하지 않는다. --net=container:$container2: $container2라는 이름의 컨테이너에서 사용하는 네트워크 네임스페이스를 공유하도록 컨테이너를 생성한다. 1-1. 도커 브릿지 설정 관련 문제의 해결 방법 컨테이너 포트를 호스트의 포트와 매핑하는 방법을 살펴보고, 컨테이너를 외부와 연결할 때 발생할 수 있는 문제를 보자 두 컨테이너 모두 상대방에게 핑(ping)을 보낼 수 있을 뿐만 아니라 외부 네트워크에도 연결 할 수 있다. 외부와 연결하기 위해서는 컨테이너의 포트를 호스트의 포트와 매핑해야 한다. 앞서 설명한 바와 같이 컨테이너마다 네트워크 네임스페이스를 갖고 있다. 컨테이너가 생성될 때, 그 컨테이너에 대한 네트워크 네임스페이스도 새로 생성된다. 컨테이너와 리눅스 브릿지는 가상 이더넷(Virtual Ethernet)=veth 링크를 통해 연결한다. 컨테이너의 eth0 포트...

1. 메모리 크기 레디스는 메모리에 데이터를 저장하기 때문에 레디스가 사용할 메모리의 크기를 지정하는것은 성능과 가장 밀접한 관련이 있다. 실제로 저장되는 데이터의 크기는 redisObject와 키가 저장된 크기를 뺀 나머지가 된다. 저장되는 데이터가 작은 크기의 문자열이라면 redisObject를 저장하기 위한 오버헤드가 더 크게 된다. 이럴 떄는 문자열을 숫자로 바꾸어 저장하거나, 다른 데이터형을 사용하면 더 많은 데이터를 저장할 수 있다. 만약 레디스에 저장될 데이터의 크기를 산정하지 못하여 redis.conf와 maxmemory 설정에 값을 지정할 수 없게 되었다고 하자. 그러면 레디스에 데이터가 계속 추가되어 물리 메모리를 모두 사용하게 된다. 이때 운영체제에서는 애플리케이션이 시스템에서 사용 가능한 물리 메모리 보다 더 많은 메모리를 사용하려고 할 때 스왑이라는 가상 메모리 공간을 하드디스크에 생성하여 사용하는데, 이 영역을 스왑공간이라 부른다. 이떄 스왑 공간이 충분하지 않으면 운영체제는 메모리에서 동작 중인 프로세스를 제거하여 사용가능한 메모리의 영역을 확보하게 된다. 이와 같이 동작 중인 프로세스를 죽이는 리눅스의 프로그램을  OOM킬러라고한다. 그러므로 OOM킬러를 피하려면 충분한 스왑공간을 확보해야한다. 그런데 데이터가 저장되기 시작하면 레디스의 응답시간은 수십 배에서 수백 배까지 늘어나게 된다. 만약 응답시간이 중요한 서비스라면 반드시 redis.conf의 maxmemory 설정에 설치된 물리 메모리 크기 이내의 값을 지정하여야 한다. 일반적으로 운영체제는 설치된 메모리 크기의 두 배를 스왑공간으로 할당한다. 여기서 말하는 두 배는 메모리가 충분하지 못했던 과거의 기준이다. 메모리의 가격이 저렴해지고 엔트리급 서버 시스템이 16GB이상의 메모리를 갖는 지금은 기준이 조금 달라졌다. 레드햇 엔터프라이즈의 가상 메모리 설정 가이드 문서에 따르면 시스템에 설치된 물리 메모리의 크기에 따라서 다른 값을 ...

레디스에 스케일 아웃을 처리하기 위한 방법으로 두 가지 기법을 제공한다. 읽기분산을 위한 복제(Replication)와 쓰기 분산을 위한 샤딩(Sharding)이 이에 해당된다. 1. 복제 복제는 동일한 데이터를 다중의 노드에 중복하여 저장하는 것을 말한다. 레디스는 복제를 위해 마스터와 슬레이브의 복제의 개념을 사용한다. 마스터는 복제를 위한 데이터의 원본 역할을 한다. 슬레이브는 마스터 노드에 데이터 복제 요청을 하고 데이터를 수신하여 데이터를 동기화 한다. 통상적으로 레디스 인스턴스 하나가 처리할 수 있는 TPS는 1만~2만이다. 또한 대부분의 레디스 명령은 읽기와 쓰기에 따른 성능편차가 없다. 복제는 슬레이브 노드가 마스터 노드의 데이터를 실시간으로 복제하여 데이터의 동기화를 유지한다. 슬레이브 노드가 시작할 때 마스터 노드에게 복제를 요청하고 최초 복제가 완료된 이후는 변경 사항만 업데이트 한다. 레디스의 복제는 마스터노드가 슬레이브노드의 정보를 가지지 않고, 슬레이브 노드가 마스터 노드의 위치만 알고있으면 복제를 할 수 있다. 1-1. 단일 복제 마스터노드와 슬레이브 노드 하나로 구성된다. 마스터 노드에 변경이 발생하면 실시간으로 슬레이브 노드에 데이터 변경사항이 기록된다. 하지만 슬레이브 노드에 변경이 발생하면 마스터 노드는 해당 변경 사항을 감지하지 못한다. 슬레이브 노드에서 데이터 변경이 일어나는 순간 데이터의 정합성이 무너지게 되므로 슬레이브 노드에서는 데이터의 변경을 수행하지 않아야 한다. 1-2. 다중 복제 단일 복제만으로는 필요한 읽기 성능을 만족하지 못할때 다중 복제를 고려할 수 있다. 단일 복제 구조의 클러스터에 슬레이브 노드를 추가하기 위해서는 마스터 노드의 위치정보를 슬레이브 노드에 설정하고 인스턴스를 실행하면 노드 추가가 완료된다. 이와 같이 단일 복제 상태에서 여러 대의 슬레이브 노드를 추가한 것을 다중 복제라고 한다. 마스터 노드의 재시작이 필요하지 않다. ...