게시글
질문&답변
2024.04.24
좀비프로세스,자식프로세스
네 안녕하세요. 고아 프로세스는 부모 프로세스가 죽은 것이 맞고, 좀비 프로세스는 자식이 부모에게 자신의 종료를 제대로 전달하지 못해서, 부모가 자식 프로세스의 정보를 정리하지 못하는 경우를 의미 합니다. kill 명령 등으로 강제로 죽일 수 있지만, 그런 외부의 방법이 아니고서는 프로세스가 정리되지 않습니다. 자식프로세스를 호출하지 못한다는 의미가 좀 애매한데, 좀비가 된 자식 프로세스는 이제 자신이 해야 할 모든 일을 마쳤기 때문에 스케쥴링 되지 않고 따라서 CPU 와 메모리 같은 리소스를 사용하지 않습니다. 따라서 자원회수가 안된다기 보다는 PID 회수가 안된다고 보는 게 더 정확 합니다. swap cached 는 강제로 스왑을 다시 생성할 경우 정리가 되지만 그 외의 경우는 특별히 없어지진 않습니다. 메모리가 부족해서 메모리 영역의 재할당이 필요할 경우에는 정리가 될거구요. 스왑 영역을 재할당 하는 방법은 ( https://brunch.co.kr/@alden/22 ) 를 참고 하시면 됩니다. 하지만 운영 환경의 서버에서는 특별한 경우가 아니면 하지 않기를 권고 합니다. 어떤 부작용이 일어날지 알 수 없기 때문 입니다. I/O가 갑자기 증가하거나, CPU 사용량이 증가할 수 있습니다. 현업에서는 특별히 고아 프로세스가 문제를 일으킨 적은 없기 때문에 따로 확인하진 않았습니다. 실제로 좀비 프로세스의 경우도 문제가 되는 경우는 극히 드물었습니다.
- 0
- 1
- 38
질문&답변
2024.04.23
좀비프로세스 자원 관련 질문입니다
네. 좀비 프로세스는 CPU나 메모리를 사용하진 않습니다. 다만 PID를 차지하고 있기 때문에 다수가 쌓이게 되면 PID 고갈 현상이 발생할 수 있습니다. 좀비 프로세스를 확인하려면 ps aux | grep Z 와 같이 입력해서 확인할 수 있습니다.
- 0
- 1
- 39
질문&답변
2024.04.02
네트워크 소켓 옵션 확인 방법 관련
답변이 늦었습니다. 사실 제가 지금까지 네트워크 트러블슈팅을 경험할 때에는 소켓 옵션까지 확인할 필요는 없었어서 SO_REUSEADDR과 같은 소켓 옵션이 적용되어 있는지 여부를 확인하진 않았습니다. 찾아보니 ss , netstat 명령으로도 소켓 옵션은 확인이 불가능 한 것 같습니다. 저는 보통 ss -s , netstat -napo 명령을 주로 사용 했었습니다. 특히 netstat -napo 는 소켓 킵얼라이브 타이머를 함께 볼 수 있어서 좀비 커넥션 같은 것들을 추적하는데 유용하게 사용 했었습니다.
- 0
- 1
- 59
질문&답변
2024.03.14
Elastic Search 동작 이해하기 색인 설명 관련
네. 말씀 드렸던 것처럼 샤드를 도중에 변경할 수는 없습니다. 그래서 운영 환경에 적용하기 전에 충분히 테스트를 해야 합니다. 예를 들어 프라이머리 샤드의 개수가 몇 개일 때 우리가 원하는 성능이 나오는지 수차례 테스트 하면서 그 최적의 값을 찾아야 합니다. 그리고 만약 운영 환경에 이미 적용한 후에 이런 과정을 거치려면 Reindex API를 통해서 새로운 인덱스에 재색인을 하는 방식으로 진행 해야 합니다.
- 0
- 2
- 76
질문&답변
2024.03.12
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 )
- 0
- 1
- 159
질문&답변
2024.03.04
top 명령어 살펴보기 (2)에서의 좀비 프로세스에 대한 질문입니다.
네. 이건 제가 표현을 제대로 못한 것 같네요. 자식 프로세스가 부모 프로세스보다 먼저 종료된다기 보다는 (대부분 자식이 먼저 종료되는 게 맞긴 하겠죠~) 자식 프로세스의 종료를 부모 프로세스가 정리하지 못하게 되는 경우, 즉 부모 프로세스가 wait() 를 호출하지 못하는 경우에 발생 합니다. 이를 부모 프로세스가 먼저 죽은 경우로 표현 했는데 이 부분은 제가 잘못 알고 실수 한 것 같습니다. (사진)이 그림과 이 다음 그림 (사진)에서 부모가 exit() 로 끝나는 게 아닌 어떤 이유로 wait() 를 호출하지 못하는 경우로 바꿔야 할 것 같네요. 알려 주셔서 감사합니다. 강의는 최대한 빠르게 수정 하도록 하겠습니다.
- 0
- 1
- 98
질문&답변
2024.02.11
6강 10분 색인 과정에 대해 질문 있습니다.
하루에 100GB의 로그가 쌓이기 때문에 인덱스 별 샤드의 최대 크기를 10GB로 가정했을 때 10개의 프라이머리 샤드가 필요하게 됩니다. 10GB * 10개 = 100GB 이기 때문 입니다. 그리고 그 데이터를 30일간 저장하게 됩니다. 즉, 인덱스가 최대 30대까지 만들어 진다고 생각하시면 됩니다. 그래서 데일리로 쌓이는 로그를 노드 별로 나누는 관점과 30일간의 모든 인덱스가 노드 상에 저장되어야 하는 관점, 두 가지 관점으로 이해 하셔야 합니다. 인덱스 하나가 6,000GB가 아니라, 하루에 100GB 씩 로그가 쌓이는 인덱스가 30개가 생긴다고 이해하셔야 합니다. 만약 지금이 1월 30일이라고 한다면 nginx-access-log-2024.01.01 ~ nginx-access-log-2024.01.30 이렇게 30개의 인덱스가 저장된다고 이해 하시면 됩니다. 혹시 답변이 되었을까요? 추가 질문 있으시면 언제든 말씀하세요.
- 0
- 2
- 109
질문&답변
2024.01.26
4강 14분51초 질문 있습니다!
샤드 하나의 크기를 몇으로 가져가느냐에 대한 문제인데 사실 이게 정답이 없습니다. 하루 30GB 쌓이는 로그라면, 만약에 저라면 노드의 증설을 고려해서 프라이머리 샤드 3개 정도로 시작해 볼 것 같습니다. 그리고 클러스터에 노드가 1개만 존재한다면 레플리카 샤드는 아무곳에도 배치 되지 않고 클러스터의 상태가 yellow 를 계속 유지하게 될 겁니다. 그래서 클러스터에 노드가 1개라면 레플리카 샤드는 사실상 사용할 수 없는 것과 마찬가지 입니다. 저도 예전에 비슷한 생각을 했었고 하나의 서버 내에 포트를 나눠서 여러 개의 ES 인스턴스를 작동 시켰었습니다. ( https://brunch.co.kr/@alden/34 ) 이 구조는 비용을 줄이거나 서버의 사용량을 극대화 하는 것에는 도움이 될지 모르겠지만 운영적인 측면에서는 복잡도가 상당히 올라가는 구조 입니다. 왜냐하면 하나의 EC2 서버에 운영을 위한 리부팅 작업 같은 게 필요할 때 영향 받는 ES 인스턴스가 여러가지가 되기 때문에 소통 비용도 늘고 고민해야 할 것들이 늘어나게 됩니다. 올바른 설계이냐 아니냐 까지는 모르겠지만 분명히 운영 복잡도를 높이는 설계이긴 합니다. Index Lifecycle Management (ILM, https://www.elastic.co/guide/en/elasticsearch/reference/current/index-lifecycle-management.html ) 을 참고하셔서 정책을 만들면 가능 합니다. 전체 인덱스 개수를 트리거링 기준으로 삼을 수 있을지는 모르겠지만, 생성된지 특정 기간이 넘어간 인덱스들 (예를 들어 1개월 이상 된 인덱스)을 트리거링 기준으로 삼아서 해당 인덱스들의 스냅샷을 생성하고 백업한 후에 지우게 하는, 일종의 라이프사이클 작업을 설정할 수 있습니다.
- 0
- 2
- 131
질문&답변
2024.01.09
안녕하세요 netstat 2번째에서 궁금한게 있습니다.
네. FIN 패킷을 받아서 CLOSE_WAIT 상태가 되고 CLOSE 로 넘어가야 하는게 정상 입니다. 그리고 그 과정은 아주 빠르게 이뤄지기 때문에 실제로 netstat 명령을 입력 하면 거의 볼 수가 없어야 합니다. 그래서 CLOSE_WAIT 상태가 netstat 명령에 보인다는 건 모종의 이유로 소켓을 닫지 못하고 CLOSE 상태로 변경되지 않는다는 의미이고, 이 때의 원인이 애플리케이션 이상 동작일 경우가 가장 큽니다. https://tech.kakao.com/2016/04/21/closewait-timewait/ 문서를 보시면 CLOSE_WAIT 를 재현하는 소스 코드가 있으니 그걸 보시면 훨씬 더 잘 이해하실 수 있을 겁니다. FIN 패킷을 받고 CLOSE_WAIT 상태가 된 후 소켓을 닫고 CLOSE 가 되어야 하는데 그 중간에 sleep() 이 있어서 프로세스가 잠자기 상태로 들어가고 이로 인해 소켓을 닫지 못하게 되는거죠. 그래서 CLOSE_WAIT 가 많다는 건 애플리케이션의 이상 동작으로 네트워크 소켓을 제대로 닫지 못하고 있다는 것을 의미 합니다.
- 0
- 1
- 67
질문&답변
2023.12.27
안녕하세요 elastic cloud를 사용하는데 cpu가 계속 칩니다 .
우선 몇가지 데이터를 수집해 보면 좋겠습니다. 데이터 노드의 역할을 하고 있는 노드들의 CPU 개수 확인 Load Average는 상대적인 개념이기 때문에 CPU 개수를 알아야 저 정도의 Load Average가 높은건지 아닌건지를 판단할 수 있습니다. 만약 CPU 개수에 비해 Load Average가 높다면 부하가 높은 상황이기 때문에 데이터 노드를 증설 하거나 데이터 노드의 사양을 높일 필요가 있습니다. 하지만 지금 상황에서는 데이터 노드를 증설해서 데이터 노드 당 보유하고 있는 샤드의 개수를 줄이는 게 더 좋은 선택이 될 것 같습니다. _cat/shards 를 통해서 노드들에 샤드가 어떻게 배치되어 있는지 확인 전체 샤드가 1,320개 인데 프라이머리 샤드와 레플리카 샤드가 노드 별로 분산되어 있는지를 확인해 볼 필요가 있습니다. 특정 노드에 몰려서 부하를 일으킬 수 있기 때문에 현재 샤드의 배치 상황을 확인해 봐야 합니다. 알려 주신 정보로만 추측해 봤을 때는 데이터 노드의 사양이 낮고 개수도 적어서 부하를 일으키는 것으로 보입니다. 저도 ElasticCloud는 사용해보지 않아서 잘 모르겠지만, 1번 부터 확인해 보고 데이터 노드 증설로 방향을 잡아 보면 좋을 것 같습니다.
- 0
- 1
- 138