
목차1. 문제 배경: Redis는 왜 갑자기 죽었을까?2. 배경 지식: Redis의 BGSAVE와 Copy-on-Write3. 실험 목적: Copy-on-Write가 실제로 OOM을 유발하는가?4. 실험 환경: Docker 기반 Redis 컨테이너 구성5. 실험 과정: Copy-on-Write 상황 유발 및 메모리 관측6. 실험 결과: Copy-on-Write로 인한 메모리 폭증은 실제로 발생했다7. 실험을 통해 알게 된 것8. 결론9. Github 링크1. 문제 배경: Redis는 왜 갑자기 죽었을까?Redis가 예고 없이 종료될 수 있습니다.Redis의 maxmemory는 6GB로 설정되어 있었고,컨테이너의 메모리 제한은 7GB였으며,메모리 사용량이 한계에 가까운 시점에서 BGSAVE가 실행되었고,그..

들어가기에 앞서 현대의 지도 서비스, 자율주행 시뮬레이션 등에서는 방대한 공간 데이터를 빠르게 탐색해야 합니다.하지만 데이터를 단순히 행렬 순서(예: row-major)로 저장하면, 지리적으로 가까운 두 점이 메모리 상에서 멀리 떨어져 있어 캐시 효율이 낮고 접근 성능이 떨어집니다. 이 문제를 해결하는 대표적인 방식이 바로 Z-order 인덱싱입니다.목차공간 데이터의 일반적 특성 – Z-order가 필요한 이유Z-order 개요 및 정의Z-order의 이점Z-order Index 계산 방식 – Bit Interleaving요약참고 자료1. 공간 데이터의 일반적 특성 – Z-order가 필요한 이유공간 정보(Spatial Data)는 일반적으로 다음과 같은 특징을 가집니다.공간적 지역성: 인접한 위치일수..

들어가기에 앞서 일반적인 서버의 목적은 클라이언트 요청에 대해 적절한 응답을 빠르고 효율적으로 반환하는 것입니다.즉, 대부분의 서버는 다음과 같은 단순한 I/O 루틴을 반복합니다. "입력(요청)을 받고 → 출력(응답)을 보낸다." 예를 들어, 웹 서버는 클라이언트의 요청에 따라 정적 파일(HTML, 이미지 등)을 전송하고,WAS(Web Application Server)는 DB에서 읽어온 사용자 데이터를 API 응답으로 보내며,FTP 서버는 파일을 반환합니다. 이러한 동작들은 모두 단순한 코드로 표현할 수 있습니다.read(fd, buffer, size);send(socket, buffer, size);하지만 이 단순한 동작 이면에서는 여러 번의 데이터 복사와 사용자 공간(user space)과 커널..

로그는 왜 중요할까요?단순한 기록처럼 보이던 로그가, 어떻게 시스템 간 데이터 흐름, 복구, 재처리, 확장을 가능하게 만드는 걸까요?이 글에서는 로그 기반 아키텍처의 핵심 철학을 정리했습니다. 들어가기에 앞서 우리는 서비스를 만들 때 다양한 시스템을 함께 사용합니다.데이터베이스(DB): 사용자 정보, 거래 내역 등 구조화된 데이터를 저장캐시(Redis 등): 빠른 응답을 위해 임시로 데이터를 저장검색엔진(Elasticsearch): 텍스트 기반 검색과 분석을 지원분석 시스템(Hadoop, Spark): 데이터를 수집하고 집계하여 비즈니스 인사이트를 도출이 각각의 시스템은 서로 다른 목적과 다른 형식의 데이터 처리 방식을 갖고 있습니다. 문제는 여기서 시작됩니다.이 시스템들이 하나의 흐름 속에서 유기적으로..

시분할(Time Sharing)은 하나의 컴퓨터 자원을 여러 사용자가 시간을 나눠가며 동시에 사용하는 것처럼 보이게 만드는 기술입니다.혹은, 한 사용자가 여러 작업을 동시에 수행하는 것처럼 보이게 만들기도 합니다. 예를 들어, 컴퓨터로 노래를 들으면서 게임을 하고 있는데, 그 와중에 친구에게 카카오톡 메시지가 도착했다고 해봅시다.사실 컴퓨터는 한 번에 하나의 작업만 처리할 수 있는 구조입니다.하지만 CPU는 각 작업에 아주 짧은 시간(몇 밀리초)을 번갈아가며 배정해주기 때문에 사용자는 마치 노래, 게임, 메신저가 동시에 작동하는 것처럼 느끼게 됩니다.이처럼 짧은 시간 단위로 작업을 나누어 번갈아 실행하는 방식이 바로 시분할(Time Sharing)입니다. UNIX는 이 시분할(Time Sharing) 개..

개요우리가 눈으로 보는 도형은 사각형, 오각형, 심지어 원이나 구처럼 생겼지만,컴퓨터 그래픽스의 세계에선 모든 도형이 결국 삼각형으로 쪼개집니다왜일까요?삼각형은 항상 평면 위에 존재하고, 수학적으로 안정적이며, GPU가 직접 처리할 수 있는 기본 단위이기 때문입니다. 이런 이유로 복잡한 다각형을 삼각형으로 나누는 과정, 즉 삼각화(Triangulation)는 컴퓨터 그래픽스, 게임, CAD, 심지어 로봇의 경로 탐색(Path Planning)까지 다양한 분야에서 사용됩니다. 이 글에서는 삼각화 알고리즘 중 하나인 Ear Clipping 알고리즘을 소개하고,그 원리와 구현 방법, 시각화를 통해 삼각화 과정을 직접 따라가 보겠습니다. Ear Clipping 알고리즘을 수행하기 위해서는 폴리곤이 그림1의 si..
- Total
- Today
- Yesterday
- user space
- b3dm to glb
- event streaming
- 3d tiles 1.0
- kernel space
- * to glb
- gltf
- * to gltf
- Kafka
- morton order
- sendfile()
- cpu i/o
- z-order curve
- 3d tiles
- ear clipping
- z-order
- 삼각분할
- bgsave
- event srource
- append only
- 역수 근사
- transferto()
- Cesium
- b3dm
- ear cut
- zero-copy
- the unix timesharing system
- redis bgsave
- implict titling
- .b3dm
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 | 30 |