
목차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)는 일반적으로 다음과 같은 특징을 가집니다.공간적 지역성: 인접한 위치일수..
- Total
- Today
- Yesterday
- the unix timesharing system
- Kafka
- Cesium
- ear cut
- z-order curve
- gltf
- bgsave
- cpu i/o
- z-order
- 3d tiles
- 역수 근사
- 삼각분할
- .b3dm
- ear clipping
- implict titling
- b3dm to glb
- redis bgsave
- event streaming
- reciprocal approximation
- * to gltf
- append only
- * to glb
- user space
- sendfile()
- b3dm
- kernel space
- transferto()
- zero-copy
- event srource
- 3d tiles 1.0
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
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 |