신우섭의 도서관

KOTITI 시험연구원 직원식당 점심 메뉴

신우섭 — Tue, 12 Nov 2024 11:25:36 +0900

그림을 통한 좌표계(X, Y, Z) 및 회전방향(Pitch, Yaw, Roll) 외우기

신우섭 — Tue, 19 Apr 2022 23:42:38 +0900

X, Y, Z 좌표계

회전 방향

FRotator

UE4 FRotator Document

엘라스틱 서치 클러스터 내부 구조

신우섭 — Thu, 24 Mar 2022 10:38:16 +0900

클러스터 내부 구조

프라이머리 샤드는 인덱스 생성 후 불변하다
프라이머리 샤드는 클러스터링 된 노드에 분산 생성된다.(예: 전체 노드의 수가 3개 이고 Number_of_shards : 3 이면 각 노드별로 1개의 프라이머리 샤드가 생성)
레플리카 샤드는 클러스티링 된 노드에 각각 생성된다. (예: 전체 노드의 수가 3개 이고 Number_of_replicas : 3 이면 각 노드별로 3개의 레플리카 샤드가생성)
각 노드의 레플리카 샤드는 현재 노드에 생성되어있는 프라이머리 노드가 아닌 다른 노드의 프라이머리 노드를 복사한다
클러스터링 된 노드의 다수가 다운되면 해당 클러스터는 정상 동작할 수 없다

대용량 데이터를 소규모의 Bulk로 너무 잘게 쪼개면 데이터 소실의 위험이 존재한다!

신우섭 — Wed, 23 Mar 2022 17:41:18 +0900

패킷 사이즈 제한때문에 100만 Document를 insert하는 BulkInsert를 100개의 Document씩 잘개쪼개면 Elasticsearch write 풀의 대기큐 공간만 많이 잡아먹게된다.

그렇다고 또 큰데이터를 한번에 다 보낸다고 해서 무조건 한칸의 대기 큐 공간을 차지하는 것도 아니다.

너무 크면 elasticsearch내부에서 알아서 대용량 Bulk를 쪼개서 대기 큐에 적재하는 것 같다.

그러니 너무 커서 패킷 사이즈를 초과하지 않고, 너무 작아서 write 대기큐의 공간을 많이 잡아먹지 않도록 쪼개는게 중요하다.

싱글톤(Spring Bean) 객체 사용 꼭!! 지켜야할 주의점!

신우섭 — Mon, 14 Mar 2022 22:52:13 +0900

무상태(stateless)로 설계해야 한다!

특정 클라이언트에 의존적인 필드가 있으면 안된다.
특정 클라이언트가 값을 변경할 수 있는 필드가 있으면 안된다.
가급적 읽기만 가능해야 한다.
필드 대신에 자바에서 공유되지 않는, 지역변수, 파라미터, ThreadLocal 등을 사용해야한다.

왜?

싱글톤 객체는 단일 객체다(유일함) 이 객체가 내부에 변수를 가지고있고 쓰기를 허용한다면, 여기저기서 이 값을 막 바꾸게 된다.
내가 원하는 시점에 싱글톤 객체를 사용했는데 이 타이밍에 다른 녀석들이 똑같이 싱글톤 객체를 사용한다면 원하는 값이 나오지 않을 가능성이 높아진다.

Elasticsearch 스냅샷 사용 방법 (링크)

신우섭 — Mon, 14 Mar 2022 09:36:00 +0900

공식문서가 너무 잘 설명되어있어서 별다른 포스팅없이 링크로 대체합니다.

https://www.elastic.co/guide/en/elasticsearch/reference/current/snapshots-take-snapshot.html

java 프로세스 메모리가 계속 증가한다..! 메모리 누수일까?

신우섭 — Sun, 13 Mar 2022 15:34:00 +0900

java 프로세스 메모리가 계속 증가한다..! 메모리 누수일까?

CentOS7에 java 프로세스를 가동시키고 해당 java service가 제공하는 api를 계속 호출했더니 메모리가 야금야금 증가해서 증가한 메모리를 유지하는 현상을 발견했습니다
과연 이게 메모리 누수인지 아니면 다른 이유인지 확인해 보겠습니다.

Java Service 실행 환경

api version : 2.3.1
os : CentOS Linux release 7.7.1908 (Core)
jdk : openjdk "14.0.1"
java options : -server -Xms2g -Xmx2g -Xss256k -XX:MetaspaceSize=256m -XX:MaxMetaspaceSize=256m -Dfile.encoding=UTF-8

Java options 설명

server : 해당 옵션은 최고 작동 속도를 최대화하도록 특별히 조정되었습니다. 빠른 시작 시간 또는 더 작은 런타임 메모리 풋 프린트보다 가능한 가장 빠른 작동 속도가 필요한 장기 실행 서버 애플리케이션을 실행하기위한 것입니다.
64bit JDK 는 암시적으로 무조건 server 옵션이 적용됩니다.
Xms : 설정은 Java 힙의 초기 크기를 제어합니다. 이 매개변수를 적절하게 조정하면 가비지 콜렉션의 오버헤드를 줄여서 서버 응답 시간 및 처리량을 개선합니다. 일부 응용프로그램의 경우, 이 옵션에 대한 기본 설정이 너무 낮아서 사소한 가비지 콜렉션의 수가 높아질 수 있습니다.
Xmx : Java 힙의 최대 크기를 제어합니다. 이 매개변수를 늘리면 Application Server에 사용 가능한 메모리가 늘어나고 가비지 콜렉션 빈도가 줄어듭니다. 이 설정을 늘리면 서버 응답 시간 및 처리량이 개선될 수 있습니다. 그러나 이 설정을 늘리면 가비지 콜렉션이 발생할 때 해당 콜렉션의 지속 기간이 늘어납니다. 이 설정은 Application Server 인스턴스에 대해 사용 가능한 시스템 메모리 이상으로 증가해서는 안됩니다. 설정을 사용 가능한 시스템 메모리 이상으로 늘리면 시스템 페이징 및 상당한 성능 감소를 유발할 수 있습니다.
Xss : 스레드 스택 크기(바이트)를 설정합니다
-XX:MetaspaceSize : 가비지 컬렉션을 처음 초과할 때 트리거할 할당된 클래스 메타데이터 공간의 크기를 설정합니다. 가비지 수집에 대한 이 임계값은 사용된 메타데이터 양에 따라 증가하거나 감소합니다. 기본 크기는 플랫폼에 따라 다릅니다.
-XX:MaxMetaspaceSize : 클래스 메타데이터에 할당할 수 있는 최대 네이티브 메모리 양을 설정합니다. 기본적으로 크기는 제한되지 않습니다. 응용 프로그램의 메타데이터 양은 응용 프로그램 자체, 실행 중인 다른 응용 프로그램 및 시스템에서 사용할 수 있는 메모리 양에 따라 달라집니다.

oracle options doc : https://docs.oracle.com/javase/8/docs/technotes/tools/windows/java.html

분석

코딩 실수로인한 메모리 누수(Memory leak) 여부

코딩상의 실수로 메모리가 누수가 발생하였는지 판단합니다.

1. Eclipse Memory Analyzer를 이용한 Heap Dump 분석

2.4gb 로 동작중이던 Java process의 memory가 2.6gb로 증가되고 유지되었습니다.
증가량은 약 0.2gb입니다.

메모리 누수 여부를 확인하기 위하여 jmap으로 증가한 java service의 Heap Dump를 가져와 Eclipse Memory Analyzer 로 분석합니다.

jmap 을 이용한 heap dump 생성 방법

./jmap -dump:format=b,file=<파일명> <PID>

분석 결과

해당 service의 dump를 확인 결과 현재 사용중인 heap memory 영역은 43.3mb이며 메모리 증가로 가정되었던 0.2gb에 현저히 미치지 못하는 사용률을 보입니다.

2. Jconsole 을 이용한 실시간 Heap Memory 모니터링

위 Dump를 근거로 실제 Heap Memory사용이 비슷하게 이루어지나 실시간 모니터링을 실시합니다.

Jconsole 사용 방법

감시하고싶은 java process를 시작할때 아래와 같은 java options 을 추가한다.

-Dcom.sun.management.jmxremote=true
-Dcom.sun.management.jmxremote.port=임의의 PORT
-Dcom.sun.management.jmxremote.ssl=false
-Dcom.sun.management.jmxremote.authenticate=false
-Djava.rmi.server.hostname=서비스할 PC IP

모니터링을 진행할 PC에서 Jconsole을 실행합니다.
실행 된 Jconsole에서 Remote Process에 위에서 지정한 -Djava.rmi.server.hostname의 값을 넣어 연결합니다.

분석 결과

위 이미지를 통하여 Heap memory는 java prcess를 실행할때 지정했던 option Xmx2g 를 상회하지 않고 할당과 해제가 뚜렷하게 보이며 위 그래프를 통해 Heap memory 즉 개발자가 임의적으로 할당하는 메모리 영역에 대한 누수는 확인되지 않았습니다.

메모리 누수가 발생하는 Java Process의 예시

결론

그렇다면 메모리 누수가 아닌대 오르고있는 메모리는 무엇인가?

메모리 누수가 아니다, 그렇다면 실제로 오르고있는 저 메모리는 무엇일까요?
java 프로세스의 메모리 영역은 크게 Heap Memory 와 Native Memory 영역이 있습니다.

위 그림과 같이 영역 구분이 가능하며 이중에서 사용자가 크기를 설정할 수 있는 부분은 Java Heap과 Metaspace 영역입니다.
그 외 영역은 JVM과 OS가 사용하는 영역이며 최대 사용량에 대한 예측은 JVM native memory tracking 으로 JVM이 임시로 잡아두는 영역인 reserved(임시 메모리) 값을 통하여 확인가능합니다.

JVM의 reserved 와 committed 의 예

메모리 누수처럼 보이던 java service의 메모리 사용량이 증가하는 것은 JVM이 사용하는 Native Memory의 committed(실제 사용중인 메모리) 가 reserved(임시 메모리) 크기 안에서 증가하는 것이며, 최대 reserved(임시 메모리) 크기를 벗어나지 않을 것 입니다.

기타 설명

Heap Memory

힙 영역은 모든 자바 클래스의 인스턴스(instance)와 배열(array)이 할당되는 곳으로, 런타임(run time) 데이터를 저장하는 영역이다. 힙 영역은 JVM이 시작될 때 생성되어 애플리케이션이 실행되는 동안 크기가 커졌다 작아졌다 한다. 힙 영역의 크기는 -Xms VM option으로 지정된다고 한다. 힙 영역의 크기는 가비지 컬렉션의 전략에 따라 고정된 크기일수도 있고, 유동적으로 변경될 수도 있다.
oracle heap-memory doc : https://docs.oracle.com/cd/E13150_01/jrockit_jvm/jrockit/geninfo/diagnos/garbage_collect.html

Native Memory

JVM은 클래스 메타데이터, 애플리케이션 코드, JIT에 의해 생성된 코드, 내부 데이터 구조 등을 유지하기 위해 네이티브 메모리에서 상당히 큰 청크를 할당합니다
JVM이 Native Memory 영역에 사용하는 항목들은 아래와 같습니다.

Metaspace
Threads
Code Cache
Garbage Collection
Symbols
Native Byte Buffers
Additional Tuning Flags

jvm native-memory doc : https://www.baeldung.com/native-memory-tracking-in-jvm

JVM native memory tracking 방법

java 실행인자에 -XX:NativeMemoryTracking=detail
터미널 명령어 <jdk설치위치>/bin/jcmd <pid> VM.native_memory detail 실행
결과

5746:

Native Memory Tracking:


Total: reserved=2914585KB, committed=2390505KB
-                 Java Heap (reserved=2097152KB, committed=2097152KB)
                            (mmap: reserved=2097152KB, committed=2097152KB)

-                     Class (reserved=315585KB, committed=68929KB)
                            (classes #12549)
                            (  instance classes #11710, array classes #839)
                            (malloc=2241KB #37324)
                            (mmap: reserved=313344KB, committed=66688KB)
                            (  Metadata:   )
                            (    reserved=59392KB, committed=58624KB)
                            (    used=57333KB)
                            (    free=1291KB)
                            (    waste=0KB =0.00%)
                            (  Class space:)
                            (    reserved=253952KB, committed=8064KB)
                            (    used=7290KB)
                            (    free=774KB)
                            (    waste=0KB =0.00%)

-                    Thread (reserved=85475KB, committed=31611KB)
                            (thread #294)
                            (stack: reserved=84088KB, committed=30224KB)
                            (malloc=1045KB #1766)
                            (arena=343KB #586)

-                      Code (reserved=249522KB, committed=25962KB)
                            (malloc=1834KB #9033)
                            (mmap: reserved=247688KB, committed=24128KB)

-                        GC (reserved=122444KB, committed=122444KB)
                            (malloc=11576KB #25778)
                            (mmap: reserved=110868KB, committed=110868KB)

-                  Compiler (reserved=513KB, committed=513KB)
                            (malloc=348KB #916)
                            (arena=165KB #5)

-                  Internal (reserved=4879KB, committed=4879KB)
                            (malloc=4843KB #4118)
                            (mmap: reserved=36KB, committed=36KB)

-                     Other (reserved=4735KB, committed=4735KB)
                            (malloc=4735KB #53)

-                    Symbol (reserved=11979KB, committed=11979KB)
                            (malloc=10756KB #310319)
                            (arena=1223KB #1)

-    Native Memory Tracking (reserved=6634KB, committed=6634KB)
                            (malloc=353KB #4976)
                            (tracking overhead=6282KB)

-        Shared class space (reserved=11324KB, committed=11324KB)
                            (mmap: reserved=11324KB, committed=11324KB)

-               Arena Chunk (reserved=3384KB, committed=3384KB)
                            (malloc=3384KB)

-                   Logging (reserved=5KB, committed=5KB)
                            (malloc=5KB #198)

-                 Arguments (reserved=14KB, committed=14KB)
                            (malloc=14KB #454)

-                    Module (reserved=508KB, committed=508KB)
                            (malloc=508KB #3665)

-                 Safepoint (reserved=8KB, committed=8KB)
                            (mmap: reserved=8KB, committed=8KB)

-           Synchronization (reserved=423KB, committed=423KB)
                            (malloc=423KB #2695)

StackOverFlow 연속 질문 불가

신우섭 — Sat, 5 Mar 2022 23:05:39 +0900

StackOverFlow 질문을 게시하고 바로 이어서 다른 질문을 올리려했는데 딱히 에러팝업도 안뜨고 질문이 게시되지 않는 현상이 있습니다.

Response를 확인해보니

연속 질문 불가!

"You can only post once every 90 minutes" 라는 메세지가 반환되네요

90분... 텀이 너무 긴거 아닙니까ㅠ

추상화 된 빈 설정 메타 정보 BeanDefinition(빈 정의)

신우섭 — Fri, 4 Feb 2022 01:34:23 +0900

추상화 된 빈 설정 메타 정보 BeanDefinition(빈 정의)

스프링 XML, JAVA 코드, Groovy 등의 다양한 설정 형식을 지원합니다.
이렇게 다양한 설정을 지원할 수 있는 이유는 "BeanDefinition" 이라는 추상화가 있기에 가능합니다.

XML을 읽어서 -> BeanDefinition
자바 코드를 읽어서 -> BeanDefinition
Groovy 코드를 읽어서 -> BeanDefinition

스프링 컨테이너는 JAVA 코드인지, XML인지 몰라도 됩니다, 오직 BeanDefintion 만 알면 됩니다.

스프링 컨테이너는 이 BeanDefintion 즉 빈 설정 메타정보를 기반으로 스프링 빈을 생성합니다.

추상 구문 트리(abstract syntax tree, AST)란?

신우섭 — Wed, 2 Feb 2022 20:58:57 +0900

java로 elasticsearch를 사용하는 중 쿼리 만들기가 너무 빡세(?) 룸북의 @Getter @Setter 어노테이션과 같이 컴파일 타임에서 자동으로 쿼리를 만들어주는 라이브러리를 만들어보려고 조사하다보니 AST라는 생소한 단어를 접하게되어 이것이 무엇인지 찾아 보았습니다.

추상 구문 트리(abstract syntax tree)

추상 구문 트리(abstract syntax tree) 줄여서 AST 라고 쉽게 부르며,
java에서만 볼 수 있는 용어가 아닌 컴파일러가 필요한 프로그래밍 언어라면 들을 수 있는 용어입니다

컴파일러와의 관계

컴파일러가 필요한 언어에서 AST를 접할 수 있는 이유는 AST가 컴파일 단계 중 구문 분석(syntax analyzing) 단계의 결과물이기 때문입니다.

컴파일 단계

1. 어휘 분석(lexical analyze) or 스캔(scan)
2. 구문 분석(syntax analyzung) - 결과물로 구문트리(syntax tree) 또는 추상 구문 트리(abstract syntax tree)가 생성됨!
3. 의미 분석(semantic analysis)
4. 중간 표현의 생성(intermediate representation)
5. 코드 생성(code generation)
6. 최적화(optimization)
7. 어셈블러

본문에서는 편의를 위하여 AST라 부르겠습니다.

AST는 프로그래밍 언어로 작성된 소스 코드의 추상 구문 구조의 트리이며, 이 트리의 각 노드는 소스코드에서 발생되는 구조를 나타냅니다.

쉽게 말하면 우리가 작성한 소스코드를 문법에 맞게 노드들로 쪼개서 만든 트리라고 생각하면됩니다.

추상(abstract) 인 이유?

추상 이라는 용어가 쓰인 이유는 이해하기 어렵거나 추상적 인 형태를 가지기 때문에가 아니라 코드에 필연적으로 나타나는 괄호 및 기타 기호와 같은 코딩 구문을 포함하지 않기 때문에 추상이라고합니다.