일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | ||||
4 | 5 | 6 | 7 | 8 | 9 | 10 |
11 | 12 | 13 | 14 | 15 | 16 | 17 |
18 | 19 | 20 | 21 | 22 | 23 | 24 |
25 | 26 | 27 | 28 | 29 |
Tags
- 데이터유통
- functional thinking
- 알고스팟
- 테스트주도개발
- 동시성
- wait region split
- Raw-Request-URI
- 클린코드
- 박종천
- 해커컵
- 코딩인터뷰
- 개발자로살아남기
- clean code
- 함수형 사고
- 단위테스트
- kafka
- coursera
- 2016년회고
- 개발7년차매니저1일차
- 데이터플랫폼
- spray
- hackercup2017
- 개발자
- 데이터레이크
- 켄트백
- 2017회고
- 실전사례
- datalake
- 데이터야놀자
- 회고
Archives
- Today
- Total
목록2024/02 (1)
Software Engineering Note
application 이 out of memory 로 죽을 때 개선 사례
책을 읽던 중 사례 연구를 다루는 부분을 읽다가 생각이 나서 작성해 본다. 평화롭던 어느 날 서버 애플리케이션이 내려가기 시작했다. 동일한 어플리케이션이 수십대 서버에서 돌아가고 있었는데 하나씩 차례대로 내려갔다. 우선은 서비스 복구가 먼저이므로 한 명은 애플리케이션을 재시작하기 시작했고, 다른 팀원들은 원인 분석에 들어갔다. 원인은 너무 큰 데이터가 들어왔고, 이 데이터를 읽어 객체로 변환하는 과정에서 발생한 것이었다. 다만, 무조건 발생하는 건 아니었다. 이 애플리케이션은 요청한 size 만큼 결과를 내어주는데, 요청 size 가 작으면 버틸만했다. 원인을 알아냈으니 이제 개선을 해야 한다. 어떻게 개선을 할 수 있을까? 생각해 보자. 너무 큰 데이터를 읽으려고 하면 에러를 발생시켜 에러 응답이 나가..
일하며 개발하며
2024. 2. 19. 00:40