서재/밥벌이

Troubleshooting Java

눈써비 2024. 10. 10. 04:10

강의 때문에 책을 읽다가 내가 모르는 부분들을 많이 발견하니 좋다.

기초에서도 내가 모르는게 수두룩.

역시 시간을 들여 틈틈히 공부를 해야한다.

 

Chapter1 앱에서 모호한 부분 밝히기

오픈 소스를 분석해보라고 추천.

나도 잘은 안하지만 반드시 필요한 부분이긴하다.

특히 스프링시큐리티와 하이버네이트 소스 파헤친 부분을 강조.

[스프링 시큐리티 인 액션](위키북스,2022)

 

Chapter2 디버깅 기법으로 앱 로직 이해하기

디버가 사용법 등

 

Chapter3 고급 디버깅 기법으로 문제의 근본 원인 찾기

1. 조건부 브레이크 포인트

2. 실행 중단하지 않고 브레이크 포인트 사용 - 고급 설정에서 Suspend 체크하기

3. 조사 시나리오 동적으로 변경하기 - 디버깅 중 데이터 바꾸기

4. 조사 케이스를 되감기 

    일종의 rewind 이고, 가끔씩 절실히 필요했던 기능인데 모르고 있었다.

    책에는 IJ 메뉴에서 drop frame라고 캡쳐되어 있는데, 버전 탓인지 뭔지 모르지만 나의 IJ는 Reset Frame

    stack trace에서 해당 method 들어갔다가 stack 하나를 날리고 앞으로 돌아가는 기능

Chapter4 원격 앱 디버깅

java -jar -agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address='*:5005' da-ch4-ex1-0.0.1-SNAPSHOT.jar

우리도 개발환경에서 종종 써먹을만 하다.

가끔 진짜 필요하면 운영에서도..

소스 버전에 주의하라고. 이건 git branch를 잘 맞추면 될 듯.

Chapter5  로그를 활용하여 앱 동작 감시하기

추천도서 : [Logging in Action](Manning,2022) /필 윌킨스(Phil Wilkins) , 4부 추천됨

로그는 딱히 현재상황에서 얻을 것은 없었던 듯.

Chapter6 프로파일링 기법으로 리소스 사용 문제 파악하기

VisualVM 소개.

프로파일링 기법 소개.

메모리 누수가 있는 소스를 두고 설명이 펼쳐짐.

내용 자체는 알겠고, 우린 보통 apm 툴을 사용하는데, 로컬에서 이렇게 하는 방법도 좋은 듯.

설치해서 사용해야겠다. 어차피 chapter7 이후로 고급 기법이 더 나온다.

(지금 20분째? 소스 돌려보고 있는데 자꾸 GC가 일어나서 책에 나온데로 메모리 누수가 안생기고 있다.)

 

Chapter7 프로파일링 기법으로 숨겨진 이슈 찾기

우리 업계(나는 업계를 양분한다.)에서는 상상도 못할 코드가 넘쳐난다.

덕분에 돈을 벌어먹고 있지만, 아마 네카라 급의 인원들은 사람이 짠것인가 싶을 정도로 상상이상이다.

 

최근 기억나는 것 중에, 

한명이 비밀번호 초기화를 하니 mybatis에서 분기가 잘못되어 where=1을 통해 전체 인원의 비밀번호가 업데이트 되는 사건.

정말 멋진 소스였다.

 

어쨋든 처음 소스를 받으면 분석하기도 하고,

급하게 쿼리르 찾아야하는 일도 많은데, 이 프로파일링 기법을 이제 알게되다니!

 

1. 샘플링으로 실행되는 코드 관찰

   이것을 통해 Controller부터 쿼리까지 쭉 소스 흐름 파악이 좋다.

   그리고 저자는 성능 이슈에서 CPU 사용양과 사용시간을 통해 

2. 프로파일링으로 메서드의 실행 횟수 파악

   이 부분도 우리한테 꼭 필요하다. 그리고 필터를 통해 패키지를 줄 수 있다. 

3. SQL 쿼리 파악

    이것도 절실하다. mybatis를 사용하는 다수의 경우 ? 로 나와서 전체 쿼리 세팅을 해도 어려운 경우가 많다.

    저자는 JPA에 대한 설명이 주류인데, 솔직히 우리 업계에서 JPA를 짜는 정도의 인간이라면 왠만해서는 미친짓을 덜 하는 편이긴하다.

    물론 JPA에서도 많이 사용할 예정이다.

 

Chapter8 프로파일링한 데이터에 고급 시각화 도구 적용하기

Jprofiler(유료)로 JDBC 접속 누수 감지(Connection Leaks)를 보여준다.

이외에 전체 시간 그래프로 보기, NoSQL 등도 나온다.

실제로 한스킨에서 몇 년 전에 터졌던 사고가 기억났다.

부랴부랴 재니퍼를 붙여서 처리했고, 현재도 사용 중인데, 로컬에서 프로파일링 할 수 있다는 것을 너무 늦게 알았네 ^^

아 Jprofiler에서는 프로파일링이라는 용어대신 Instrumentation 라는 용어를 사용한다.

유료툴이 필요할 때 구매를 검토해보면 되시겠다.

 

Chapter9 멀티스레드 아키텍처의 락 문제 조사하기

사실 졸업 후 현업에 종사하면서 멀티스레드라는 것을 고민한 적은 별로 없는 듯 하다.

다만 가끔씩 봐야할 일이 있고, 학부때 배웠던 지식이 아직 덜 휘발되어서 읽어냈다.

(사실 나중에 필요하면 보고 읽지 말까 살짝 고민)

부록 D 부터 읽었다. 부록도 따로 정리하마.

 

간단하게 쓰레드가 대기하게 구현해두고, 개선시키는 아이디어를 내서 실행해본다.

다만 개선시킨 소스가 대기 횟수는 적은데 대기 시간은 훨씬 길다.

이장까지 읽고 이후에 다른 아이디어를 내면서 발전시키나 생각했었는데, 그냥 끝

Chapter10 스레드 덤프로 데드락 문제 조사하기

1.데드락을 발생시킨 후 덤프 수집법 알려줌

1) 프로파일러로 스레드 덤프 수집 : 버튼 사용

2) 커맨드 라인에서 스레드 덤프 수집

jstack <<PID>>

3) 스레드 덤프파일을 프로파일러로 가져와서 읽기

2.그다음에는 스레드 덤프 읽는 방법

1)일반 텍스트 읽기

2)도구로 읽기 : fastThread

 

fastthread.io

Thread Dump Analysis REST API In this modern world, thread dumps are still analyzed in a tedious & manual mode. i.e., Operations engineer captures thread dumps from the production servers; then he transmits those files to developers. Developers use thread

fastthread.io

 

Chapter11 앱 실행 중 메모리 관련 이슈 찾기

이 부분은 조금 중요하다.

가끔씩 나도 heap의 덤프 파일을 읽은 적이 있다.

메모리 누수가 참 어렵지.

기존에 eclipse나 IntelliJ로 읽었던 기억이 있는데 이제 새로운 툴을 배웠다.

일단은 샘플링과 프로파일링으로 메모리 이슈 진단을 하라고 했고,

 

1. 실제로 덤프 수집 방법

1) 메모리 이슈 때문에 앱 크래시가 발생할 때 미리 지정된 위치에서 힙 덤프를 자동 생성하도록 생성한다.

  => 우리가 사용하는 방법

-XX:+HeapDumpOnOutOfMemoryError
-XX:HeapDumpPath=heapdump.bin

2) 프로파일링 도구(VisualVM등) 사용 : 버튼사용

3) 커맨드 라인 도구(jcmd or jmap)를 사용 : 필요할 때 찾아보자

 

2. 힙 덤프 읽는 방법

VisualVM과 같은 프로파일링 도구 사용

당장 우리한테 heap이 터진 로그가 하나 있다. (2024.10.10)

수업을 미친듯이 듣는 날에 로그가 백만건 이상.

덤프를 봤더니 byte가 2G가 넘는다. 사실 이 부분에 대해서는 딱히 좋은 생각이 안 떠오른다.

당장은 일정 row 수를 정해서 해당 row가 넘는 건에 대해서는 개발자에게 문의하세요.

우리가 직접 엑셀을 잘라서 가공해서 줘야한다. 물론 이 것이 된다는 것은 row별로 나눠서 엑셀을 내려줄 수는 있지만,

앓느니 죽지. 당장 구현하느니 엑셀을 가공해준다.

현실에서 시간은 돈이기에 어쩔 수 없는 대안.

 

그런데! 오전에 윗 글을 쓰고 현재 14:03인데 처리되었다.

chatGodPT인듯

어차피 file에 기록하니 buffer 정도 두고 흘리라는 아이디어

액셀 시트당 100만건이 제한이니 그 이상일 경우 시트만 루프돌면서 찍어내면 되것다. 

 

3. OQL 콘솔에서 힙 덤프 쿼리

VisualVM에서 OQL(Object Query Languae)을 사용하라. 객체를 쿼리같은 문법으로 조회하는 방식

 

Chapter12 대규모 시스템에 배포된 앱의 동작 조사하기

마이크로 서비스에 대한 저자의 의견.

마이크로서비스에 대해 솔직히 이야기해보자. 앞으로 여러분이 작업할 많은 시스템이 마이크로서비스를 자처할 것이다. 그러나 이는 대부분 사실과 다르며, 그냥 서비스 지향 아키텍처일 뿐이다. 마이크로서비스는(솔직히 내게는 이해가 안 되는 어떤 이유에서) 요즘 꽤나 잘 팔리는 브랜드로 굳혀졌다.
중략..
마이크로서비스만 붙이면 개발자도 모집되고, 고객도 좋아하고, 강의도 잘된다는 의견 등등

아마 여기에 cloud native라는 용어도 더불어 만능키.

일단 내 주변에 이거 제대로 아는 사람은 그나마 나모정도인데, 특히 우리나라에서 제대로할 수 있는 사람 몇이나 되려나.

 

잠깐 헛소리 했고, 다시 본론.

 

JProfiler로 보면 http 요청만 따로보기, 소켓 내용만 따로보기 이런 메뉴가 있다.

그런 안내가 나왔고,

 

통합 로그 모니터링의 중요성을 강조하며 센트리(Sentry) 를 강추했다.

아마 이런 부분들도 우리가 나아갈 방향 중 하나이다.

코로나 이후로 원격근무가 많아지면서 로컬에 설치된 센트리로 통제했다 라는 자랑도 나온다.

아마 개발하다가 오류나느 등등을 메일로 받아서 고충을 해결했다 라는 자랑!

 

다음으로 배포 도구도 강추

서비스 메시 기법을 음.. 이것도 필요하면 그때 보자.

이것도 하려면 일단 쿠버네티스로 배포하는 방식으로 간 후 고려해야할 듯.

 

부록도 정리

부록 C 기타 참고 도서

[프로그래머의 뇌](제이펍,2022)

[마이크로서비스 도입, 이렇게 한다](책만,2021)

[마이크로서비스 아키텍처 구축(전면 개정판)](한빛미디어,2023)

[마이크로서비스 패턴](길벗,2020) : 마이크로서비스 하려면 읽어야하는 필독서라는 군.

[파이브 라인스 오브 코드](위키북스,2023) : 본인 책 홍봌ㅋㅋㅋㅋㅋㅋㅋㅋㅋ

[좋은 코드, 나쁜 코드](제이펍,2022)

[리팩터링(2판)](한빛미디어,2020) : 2판이 나온 것 알고 있었다. 아직 못 봄

 

부록 D 자바 스레드 이해

스레드는 고려해본지 진짜 오래됐다.

개념이랑 synchronized는 대충알고 있다.

멀티스레드 아키텍처의 일반적인 문제

1) 경쟁 상태

2)데드락

3)리브락 (데드락의 반대, 서로 계속 살아감) : 리브락은 생소한 용어다.

4)기아 : 현대 JVM에서는 가능성이 낮다 라고, 이것을 해결하는 방법은 에이징이 있었나? ㅋㅋ 

 

추천 책 중에

[기본기가 탄탄한 자바 개발자](제이펍,2024) 가 눈에 띈다. 강의를 위해 이것도 봐두자.

 

부록E 자바 메모리 관리 체계

이 부분도 오랫만에 다시 정리가 되었다.

스택에는 로컬 데이터 저장.

힙에는 객체가 저장이고,

스택에 객체가 선언되면 객체의 레퍼런스가 저장.

특정 객체의 레퍼런스가 자꾸 생기면, 객체가 GC가 일어날 수 없어서 메모리 릭이 발생할 수 있고,

스택은 전부 개별로 선언되지만 힙은 공유되니까,

힙이 터진 순가 오류문구로 나온 녀석보다는 다른 녀석이 메모리 문제의 근원이 되는 경우가 많음.

 

위 내용이 체계적으로 잘 나옴.

내가 잘 기억하고 있는지 나만의 언어로 정리해봤음.

 

메타스페이스 메모리!!

이미지 출처 : https://jaemunbro.medium.com/java-metaspace%EC%97%90-%EB%8C%80%ED%95%B4-%EC%95%8C%EC%95%84%EB%B3%B4%EC%9E%90-ac363816d35e

이건 부연 설명이 필요해서 검색 좀 했다.

https://www.programmersought.com/article/4905216600/

 

Garbage Collection Algorithm and JVM Memory Management - Programmer Sought

Because some people have shared the contents of the G1 recycler before, many people have heard the clouds (including me). Some people even ask what is the use of GC, is it helpful to write code? I think this question cannot be ignored. There is a saying in

www.programmersought.com

 

너무 길게 썼다 끝!

 

반응형