좀비프로세스 자원 관련 질문입니다

네. 좀비 프로세스는 CPU나 메모리를 사용하진 않습니다. 다만 PID를 차지하고 있기 때문에 다수가 쌓이게 되면 PID 고갈 현상이 발생할 수 있습니다. 좀비 프로세스를 확인하려면 ps aux | grep Z 와 같이 입력해서 확인할 수 있습니다.

네트워크 소켓 옵션 확인 방법 관련

답변이 늦었습니다. 사실 제가 지금까지 네트워크 트러블슈팅을 경험할 때에는 소켓 옵션까지 확인할 필요는 없었어서 SO_REUSEADDR과 같은 소켓 옵션이 적용되어 있는지 여부를 확인하진 않았습니다. 찾아보니 ss , netstat 명령으로도 소켓 옵션은 확인이 불가능 한 것 같습니다. 저는 보통 ss -s , netstat -napo 명령을 주로 사용 했었습니다. 특히 netstat -napo 는 소켓 킵얼라이브 타이머를 함께 볼 수 있어서 좀비 커넥션 같은 것들을 추적하는데 유용하게 사용 했었습니다.

Elastic Search 동작 이해하기 색인 설명 관련

네. 말씀 드렸던 것처럼 샤드를 도중에 변경할 수는 없습니다. 그래서 운영 환경에 적용하기 전에 충분히 테스트를 해야 합니다. 예를 들어 프라이머리 샤드의 개수가 몇 개일 때 우리가 원하는 성능이 나오는지 수차례 테스트 하면서 그 최적의 값을 찾아야 합니다. 그리고 만약 운영 환경에 이미 적용한 후에 이런 과정을 거치려면 Reindex API를 통해서 새로운 인덱스에 재색인을 하는 방식으로 진행 해야 합니다.

Compressed OOP 조건에 따른 ES Heap Size 제약

_bulk 인덱싱 할 때 데이터 노드들에게만 REST API로 요청을 하셨을까요? ES는 클러스터 이기 때문에 마스터 노드, 코디네이팅 노드에게 인덱싱을 해도 내부에서 데이터 노드로 라우팅이 되는 구조이기 때문에 명시적으로 데이터 노드를 통해서만 인덱싱을 하는 게 좋습니다. 쿠버네티스로 구성 하셨다고 하니 인덱싱을 위해 생성한 엔드포인트 URL 이 데이터 노드들만 가리키는지를 확인해 볼 필요가 있습니다. 데이터 노드 파드들이 죽을 때 OOM으로 죽은 걸까요? 파드가 죽을 때 죽는 이유가 나올 텐데 그 이유가 명확하게 어떤 게 나오는지 궁금합니다. 위에 말씀해 주신 제약 조건 이면 데이터 노드들의 힙 메모리로 30GB 정도 주는 것은 충분할 것 같습니다. 서킷브레이킹 리밋을 줄이는 건 임시 방편이고, 메모리가 제대로 비워지지 않는 이유를 확인해야 합니다. Old GC가 발생해도 Old 영역에 메모리가 비워지지 않는 이유를 봐야 하는데요 필드 데이터 때문에 이런 경우가 발생할 수 있으니 텍스트 타입의 필드들에 필드 데이터가 켜져 있는지 살펴 보시면 좋을 것 같습니다. ( https://www.elastic.co/guide/en/elasticsearch/reference/current/text.html#fielddata-mapping-param )

top 명령어 살펴보기 (2)에서의 좀비 프로세스에 대한 질문입니다.

네. 이건 제가 표현을 제대로 못한 것 같네요. 자식 프로세스가 부모 프로세스보다 먼저 종료된다기 보다는 (대부분 자식이 먼저 종료되는 게 맞긴 하겠죠~) 자식 프로세스의 종료를 부모 프로세스가 정리하지 못하게 되는 경우, 즉 부모 프로세스가 wait() 를 호출하지 못하는 경우에 발생 합니다. 이를 부모 프로세스가 먼저 죽은 경우로 표현 했는데 이 부분은 제가 잘못 알고 실수 한 것 같습니다. (사진)이 그림과 이 다음 그림 (사진)에서 부모가 exit() 로 끝나는 게 아닌 어떤 이유로 wait() 를 호출하지 못하는 경우로 바꿔야 할 것 같네요. 알려 주셔서 감사합니다. 강의는 최대한 빠르게 수정 하도록 하겠습니다.