gcloud CLI를 사용하며 알게 된 CLI 명령어들을 공유합니다. 1. 기본 설정 및 초기화 gcloud init # 대화형 초기 설정 (계정/프로젝트/리전) gcloud version # 설치된 gc...

Series 3 1편에서 리액티브는 “블로킹을 하지 않는다”는 데까지 봤습니다. 그런데 블로킹을 하지 않으면 서버 스레드는 구체적으로 어떻게 동작할까요. “적은 스레드로 많은 요청을 처리한다”는 말의 실체는 무엇이고, netty가 쓰는 메모리는 왜 JVM 힙 바깥(off-heap)에 있을까요. 이번 글에서는 Spring WebFlux의 실행 모델인 e...

Series 1 3편에서 Spring MVC는 thread-per-request, 즉 “요청당 워커 스레드 1개가 I/O를 기다리는 동안에도 묶여 있다”고 했습니다. Series 3은 그 블로킹을 하지 않는 다른 모델 - 리액티브(WebFlux) - 을 다룹니다. 그 첫걸음으로 이번 편은 리액티브의 개념과 Reactor의 기초를 잡습니다. TL...

앞 편에서 G1의 기계장치(pause 목표, adaptive IHOP, mixed collection)를 봤습니다. Series 2의 마지막인 이번 편은 그 손잡이를 튜닝하거나, JDK 버전이 G1의 휴리스틱을 바꿀 때 메모리 곡선이 어떻게 달라지는지를 다룹니다. 흔한 증상 하나: “런타임(JDK) 업그레이드 후 Old gen이 예전보다 높게 유지된...

ep2~3에서 메모리가 “어떻게 잡히나”(Heap + Non-heap, buildpack이 -Xmx 계산)를 봤습니다. 이번 편은 그 Heap 안에서 GC가 메모리를 어떻게 회수하는지입니다. 그리고 이게 다음 편(업무 메모리/GC 이슈)의 토대가 됩니다. TL;DR GC는 도달 가능성(reachability) 으로 live/garb...

앞 편에서 “컨테이너 메모리 = Heap + Non-heap + 여유”라는 걸 봤습니다. 그런데 -Xmx(Heap)를 누가 정할까요? 내가 명시하지 않으면, Spring Boot 컨테이너 이미지에서는 buildpack의 Memory Calculator가 자동으로 계산합니다. 그리고 그 계산식이 앞 편의 분해 그대로입니다. 이 편은 Series 1 4...

앞 편에서 프로세스 메모리가 stack/heap 등으로 나뉜다는 CS 기초를 다시 잡았습니다. 이번 편은 그 위에서 JVM이 자기 메모리를 어떤 영역으로 조직하는지를 봅니다. JVM도 하나의 프로세스지만, 자기만의 “런타임 데이터 영역(runtime data areas)”으로 메모리를 관리합니다. 이 편의 한 문장: -Xmx는 Heap만 제한한다. ...

Series 1에서 “요청이 흐르는 길”을 위에서 아래로 따라왔고, 3편에서 “스레드 스택은 힙이 아니라 native 메모리”라고 했습니다. 그 stack과 heap이 정확히 뭘까요? Series 2는 한 계층 더 내려가 JVM과 메모리를 다룹니다. 그 첫걸음으로, JVM 이야기를 하기 전에 까먹기 쉬운 CS 기초 - 프로세스가 메모리를 어떻게 쓰는...

지금까지 당연하게 넘긴 것들이 있습니다. 1편에서 내장 Tomcat이 알아서 떴고, 3편에서 DispatcherServlet이 알아서 등록됐으며, 2편에서 @Service/@Repository가 알아서 빈으로 스캔됐습니다. 누가 이걸 다 해줬을까요? 답은 Spring Boot의 auto-configuration(자동설정) 입니다. Series 1의 ...

1편에서 “DispatcherServlet이 front controller로 모든 요청을 받아 분배한다”, “요청당 스레드 1개를 쓴다”고 선언만 했습니다. 이번 편에서는 그 안을 해부합니다. DispatcherServlet 내부가 어떻게 동작하는지, 그리고 “요청당 스레드 1개”가 정확히 무슨 의미이고 왜 그게 메모리/동시성의 갈림길인지를 다룹니다....