sondevvvv

Dynamo 카산드라는 분산형 Key-value 시스템인 Amazon 의 Dynamo 에 많은 기능들을 의존한다. Dynamo 시스템의 각 노드들은 아래와 같은 세개의 주요 요소가 있다. 분할된 Datset 에 대한 조정 요청 Ring 멤버십과 실패 탐지 Local 의 지속 저장 엔진 카산드라는 Log Structured Merge Tree(LSM) 기반의 스토리지 엔진을 사용하면서 위에서 두가지 클러스터링 요소들을 주로 이끌어냈다. 특히 카산드라는 Dynamo 의 아래 스타일들을 의존한다: 변하지 않는 Hashing 을 사용한 데이터 Partitioning 버전으로 관리된 데이터를 사용하는 Multi Master Gossip 프로토콜을 사용하여 실패 탐지와 분산 클러스터 멤버십 하드웨어의 증분 scal..

Overview 카산드라는 오픈소스, 분산, NoSQL 데이터베이스이다. 카산드라는 넓게 분할된 Column 기반 스토리지 모델을 제공한다. 카산드라는 최초에 Facebook 에 의해서 디자인 되었으며 Amazon 의 Dynamo 분산 스토리지를 구현하기 위한 Event Driven 아키텍쳐, Replication 기술, 구글의 Bigtable 데이터와 스토리지 Engine Model 들을 사용하였다. Dynamo 와 Bigtable 은 둘 다 확장성, 안정성과 고가용성 Storage System 을 위해 개발되었지만 개선할 부분들이 존재했다. 카산드라 는 이 두가지 시스템의 조합으로 동종 최고의 성능으로 디자인 되었다. Application 이 read, write 에 낮은 latency 가 필요해지고..

pmap 커맨드를 사용하면 linux process 의 가상 메모리 주소의 대역과 Mapping 된 결과를 확인할 수 있다. 10: java -Xms30m -Xmx30m -verbose:gc -XX:+UseG1GC Main Address Kbytes RSS Dirty Mode Mapping 00000000fe200000 31232 30364 30364 rw--- [ anon ] 00000000fe200000 0 0 0 rw--- [ anon ] 0000000100080000 1048064 0 0 ----- [ anon ] 0000000100080000 0 0 0 ----- [ anon ] 0000562ecc068000 4 4 0 r-x-- java 0000562ecc068000 0 0 0 r-x-- ja..

https://woooongs.tistory.com/85 -Xms 보다 Memory 사용량이 더 적은 이유 Logstash 는 JVM 에서 동작중이며 -Xms (최소 힙 크기 사이즈) 는 1g 로 실행되었다. 하지만 메트릭에서 보는 것 처럼 Java process 가 사용하는 메모리는 572MB 로 최소 힙 크기보다 적은 양의 메모리를 사 woooongs.tistory.com 위 글에서 최소 힙 사이즈보다 사용중인 물리 메모리가 더 작은 이유에 대해서 확인해보았다. JVM 은 가상메모리에는 최소 힙 사이즈 만큼 공간을 할당하지만 실제로 객체를 힙에 저장하기 전까지는 물리 메모리를 점유하지 않는다. 하지만 위 글에서 해결되지 않는 의문이 있었다. 객체가 실제로 힙에 저장될때 Java process RSS ..

Logstash 는 JVM 에서 동작중이며 -Xms (최소 힙 크기 사이즈) 는 1g 로 실행되었다. 하지만 메트릭에서 보는 것 처럼 Java process 가 사용하는 메모리는 572MB 로 최소 힙 크기보다 적은 양의 메모리를 사용하고 있다고 메트릭은 표현하고 있다. 어떻게 최소 힙 크기보다 적은 양의 메모리를 사용하고 있을까? 라는 궁금증이 생겼다. 우선 해당 메트릭은 Kubernetes 의 cAdvisor 에 의해서 수집되는 지표이다. cAdvisor 가 수집하는 여러가지 메모리 지표중 container_memory_working_set_bytes 를 사용하여 메모리 사용량을 나타내고 있다. cAdvison 코드에 보면 container_memory_working_set_bytes 는 아래와 같이..

Latency 측정을 위해 Logstash 를 이용해 Nginx 의 access.log 를 분석하여 수집하고있다. logstash:2.4.1 -> logstash:7.16.2 로 버전을 올리면서 OOM 이 발생하여 원인을 파악하기 시작하였다. 서버 환경 Logstash 가 배포되는 서버는 Kubernetes 환경의 WorkerNode 에 배포되고 있으며 컨테이너의 리소스. requested_memory: 1G requested_cpu: 500m 증상 logstash 의 Base Image 를 logstash:2.4.1 -> logstash:7.16.2 로 변경하면 아래와 같이 logstash 가 시작되자마자 OOM Killed Last Termination State: Exit Code: 137 Reas..

RedirectAttributes 를 찾아보게 된 계기 운영중인 서비스에서 로그인 인증에 실패하면 아래와 같이 인증 실패 문구를 보여주고있다. 하지만 실패 문구가 보일때가 안보일때가 있다는 문의가 인입되었다. 실패 문구 노출 조건은 아래와 같이 Handlebars 로 작성되어있다. {{#if fail}} 비밀번호가 맞지 않습니다. {{else}} 로그인 시도시 동작 흐름은 아래와 같다. Login 에 실패할 경우 로그인 Page 로 다시 redirect 시키고 있다. 하지만 로그인에 실패하였을때 fail 여부를 전달하기 위해 Parameter 로 전달하지 않고 있다. 또한 Login Controller 에서 fail 에 대한 Attribute 를 넣어주고 있지도 않았다. 하지만 운영에서는 간헐적으로 동작..

lsof -i TCP:{PORT_NUMBER} - TCP 포로토콜의 PORT_NUMBER 를 사용하고 있는 프로세스 조회 $ lsof -i TCP:10001 COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME Postman 91813 root 71u IPv4 0x92ae7c0d52fa547 0t0 TCP localhost:53614->localhost:scp-config (ESTABLISHED) java 92001 root 151u IPv6 0x92ae7c0c98a283f 0t0 TCP *:scp-config (LISTEN) java 92001 root 153u IPv6 0x92ae7c0b765b83f 0t0 TCP localhost:scp-config->local..

현상 평소와 같은 요청량을 처리하는 서버에서 간혹 Minor GC 가 튀는 것을 Alert 과 Metric 으로 확인하였다. 요청량이 증가하지 않았는데 하나의 노드에서만 Minor GC 가 증가하였다. 각 매트릭의 의미는 아래와 같다. Minor GC count : 1분동안 발생한 gc log 에 기록된 Minor GC 수의 합. Minor GC Time : 1분동안 발생한 gc log 에 기록된 Minor GC 가 걸린 시간의 총 합. Minor GC 가 튀는 것은 당장의 문제가 되지는 않지만 문제가 누적되면 후에 장애로 발전할 수 있기 때문에 원인을 파악해보기로 결정. 분석 어떤 요청에 의해서 Minor GC 가 튀는건지 확인. 동일한 버전으로 서빙되는 서버중 특정 서버에서만 Minor GC 가 튀는..

Unreachable 객체 필터링 방법 우선 Unreachable 객체까지 파싱되도록 설정하여 힙덤프를 불러온다 https://woooongs.tistory.com/78 Heapdump 의 크기와 Mat 으로 Parsing 한 힙 크기가 다르다면 Heapdump 크기 : 1.5G Parsing 결과 : Total 357.3MB Unreachable (GC 대상) 객체는 MAT 기본 설정으로 파싱하지 않도록 되어있다. Unreachable 객체까지 Parsing 하기 위해서는 Preferences > Memory Analyzer.. woooongs.tistory.com Java Basics > GC Roots 버튼 클릭 Unreachable 항목이 GC 대상이 되는 참조가 없는 객체들 하지만 아래와 같이 ..