소개
네이버 클라우드, 카카오, 위버스 컴퍼니를 거쳐 지금은 당근마켓에서 안정적인 서비스 운영을 위해 SRE 로 일을 하고 있습니다.
리눅스 커널 이야기와 기초부터 다지는 ElasticSearch 운영 노하우 두 권의 책을 집필 했습니다.
강의
전체2수강평
- 정말 유익한 강의였습니다!
dami12.jung
2024.04.30
0
- 강추합니다.
서민호
2024.04.23
1
게시글
질문&답변
2024.04.24
좀비프로세스,자식프로세스
네 안녕하세요. 고아 프로세스는 부모 프로세스가 죽은 것이 맞고, 좀비 프로세스는 자식이 부모에게 자신의 종료를 제대로 전달하지 못해서, 부모가 자식 프로세스의 정보를 정리하지 못하는 경우를 의미 합니다. kill 명령 등으로 강제로 죽일 수 있지만, 그런 외부의 방법이 아니고서는 프로세스가 정리되지 않습니다. 자식프로세스를 호출하지 못한다는 의미가 좀 애매한데, 좀비가 된 자식 프로세스는 이제 자신이 해야 할 모든 일을 마쳤기 때문에 스케쥴링 되지 않고 따라서 CPU 와 메모리 같은 리소스를 사용하지 않습니다. 따라서 자원회수가 안된다기 보다는 PID 회수가 안된다고 보는 게 더 정확 합니다. swap cached 는 강제로 스왑을 다시 생성할 경우 정리가 되지만 그 외의 경우는 특별히 없어지진 않습니다. 메모리가 부족해서 메모리 영역의 재할당이 필요할 경우에는 정리가 될거구요. 스왑 영역을 재할당 하는 방법은 ( https://brunch.co.kr/@alden/22 ) 를 참고 하시면 됩니다. 하지만 운영 환경의 서버에서는 특별한 경우가 아니면 하지 않기를 권고 합니다. 어떤 부작용이 일어날지 알 수 없기 때문 입니다. I/O가 갑자기 증가하거나, CPU 사용량이 증가할 수 있습니다. 현업에서는 특별히 고아 프로세스가 문제를 일으킨 적은 없기 때문에 따로 확인하진 않았습니다. 실제로 좀비 프로세스의 경우도 문제가 되는 경우는 극히 드물었습니다.
- 0
- 1
- 42
질문&답변
2024.04.23
좀비프로세스 자원 관련 질문입니다
네. 좀비 프로세스는 CPU나 메모리를 사용하진 않습니다. 다만 PID를 차지하고 있기 때문에 다수가 쌓이게 되면 PID 고갈 현상이 발생할 수 있습니다. 좀비 프로세스를 확인하려면 ps aux | grep Z 와 같이 입력해서 확인할 수 있습니다.
- 0
- 1
- 45
질문&답변
2024.04.02
네트워크 소켓 옵션 확인 방법 관련
답변이 늦었습니다. 사실 제가 지금까지 네트워크 트러블슈팅을 경험할 때에는 소켓 옵션까지 확인할 필요는 없었어서 SO_REUSEADDR과 같은 소켓 옵션이 적용되어 있는지 여부를 확인하진 않았습니다. 찾아보니 ss , netstat 명령으로도 소켓 옵션은 확인이 불가능 한 것 같습니다. 저는 보통 ss -s , netstat -napo 명령을 주로 사용 했었습니다. 특히 netstat -napo 는 소켓 킵얼라이브 타이머를 함께 볼 수 있어서 좀비 커넥션 같은 것들을 추적하는데 유용하게 사용 했었습니다.
- 0
- 1
- 62
질문&답변
2024.03.14
Elastic Search 동작 이해하기 색인 설명 관련
네. 말씀 드렸던 것처럼 샤드를 도중에 변경할 수는 없습니다. 그래서 운영 환경에 적용하기 전에 충분히 테스트를 해야 합니다. 예를 들어 프라이머리 샤드의 개수가 몇 개일 때 우리가 원하는 성능이 나오는지 수차례 테스트 하면서 그 최적의 값을 찾아야 합니다. 그리고 만약 운영 환경에 이미 적용한 후에 이런 과정을 거치려면 Reindex API를 통해서 새로운 인덱스에 재색인을 하는 방식으로 진행 해야 합니다.
- 0
- 2
- 82
질문&답변
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
- 164