Memory 요구사항
Memory 사용량은 ProSync 사용에 있어서 가장 민감한 부분 중 하나이다. 제품 설계 에서 보았듯이 데이터를 추출하는 쪽에선 크게 데이터를 저장할 일이 없지만 데이터를 받는 쪽에선 트랜잭션 단위로 데이터가 모여야 데이터를 peer쪽에 반영할 수 있기 때문에, 이 데이터들을 모아놓는 데에 있어서 많은 양의 메모리가 사용된다.
본 장에선 대표적으로 메모리가 사용될만한 부분을 Sender (Extract / Llob ) 와 Receiver(Apply ) 로 나누어서 설명한다.
Sender(Extract, Llob) 측의 메모리 사용
Extract 프로세스는 Non-Blocking I/O로 데이터를 전송한다. 대기 없이 데이터를 전송하려면 필연적으로 수신측에서 빠르게 데이터를 처리 해줘야 한다. TCP 의 수신버퍼에 데이터가 비워지지 않으면 Sender쪽은 Blocking이던 Non-Blocking이던 데이터를 처리하지 못한다. 이 경우 보내지 못한 데이터는 Queue에 쌓이게 되는데, 이 때 메모리 사용량이 늘어나게 된다.
ProSync는 네트워크 지연 상황 발생 시 512MB 이상의 데이터가 Queue에 쌓일 경우 데이터를 보내지 않고 대기하게 된다. 이 크기는 기본값이며 히든 파라미터로 조절은 가능하다. (_MSG_LIST_SIZE_TO_PAUSE) 하지만 지연 상황에서 이 크기 때문에 속도가 달라지는 경우가 거의 없어 히든 파라미터로 처리되고 있고, 사용자는 이 사실만 알고 있으면 메모리 사용량이 올라가는 이유를 쉽게 추측할 수 있다.
Llob 프로세스의 경우 동작이 살짝 다른데, 데이터를 보내고 받을 때 64k 단위로 데이터를 주고받게 되어있으며, 각 데이터가 Llob 과 Apply 프로세스간 송수신이 완료되어야 다음 데이터를 요청하도록 짜여져 있다. 따라서 Blocking 여부와 상관 없이, Llob 에서 사용하는 최대 Thread 갯수를 따라가고, 이 크기 자체가 미미하다.
Receiver(Apply) 측의 메모리 사용
TCP 를 통한 데이터 Receive에서 중요한 부분중의 하나는 Kernel의 Receive Buffer를 빠르게 비워주는 동작이다. 이게 늦어지면 Window Size에 여유가 없어져서 결국 Sender쪽에선 아무 데이터를 보낼 수 없는 상태가 된다. 따라서 ProSync의 Apply Process는 수신을 대기하는 file descriptor(Socket)에 데이터가 감지되면 가장 먼저 데이터를 Memory로 복사하는 동작을 수행한다.
복사된 데이터들은 자연스럽게 Apply쪽에 쌓이게 된다. 쌓인 데이터는 Apply 프로세스가 사용하는 일련의 파이프 라인에 의존하여 관리된다. 여기서 해당 내용을 자세히 다루진 않고, Apply 와 해당 문서 하단의 Flow Control 에서 더 상세하게 다루도록 한다.
간단하게 요약하면, 메모리 내에 데이터가 너무 많으면 파일로 내리는 내용이고 파일로 내릴 수 없는 데이터들이 많이 쌓이게 되면 Socket 자체로부터 들어오는 데이터를 읽지 않는다. 이렇게 되면 앞서 설명한 Sender 쪽의 Non-Blocking 동작에 의해 알아서 읽기 동작을 멈추게 된다.
Last updated