Dev
슬랙이 연결을 끊었다.
슬랙 웹훅 알림 메시지 유실로인한 문제를 tcpdump를 활용하여 디버깅했던 내역을 정리 1. 증상 신규 운영환경 모니터링 시스템 구축 중 슬랙 메시지가 간헐적으로 오지않는것을 확인 * 서버에서 Slack webhook 메시지 전송 시 간헐적 실패 * 상대편이 연결을 끊었다는 로그 확인 * 약 10건 중 1~2건 실패, 랜덤하게 발생 * 같은 webhook URL을 쓰는 다른
권동혁
Linux
로드밸런서 세션 테이블 & DSR & Idle Timeout
핵심 개념 로드밸런서 세션 테이블 * L4 로드밸런서는 클라이언트 패킷을 어떤 백엔드로 보낼지 추적하기 위해 세션 테이블을 메모리에 유지 * 자원이 유한하므로 idle timeout 이후 엔트리 삭제 * 삭제 후 클라이언트가 같은 연결로 패킷을 보내면 → 로드밸런서가 RST 반환 DSR (Direct Server Return) * 응답 트래픽이 로드밸런서를 우회하여 서버 → 클라이언트로 직접 전달 * 로드밸런서가 응답 패킷을
Linux
TCP Keepalive 와 HTTP Keep-Alive
1. TCP Keepalive — 죽은 연결 감지 * 목적: idle 연결에서 상대방 생존 여부 확인 * 동작 주체: 커널 * 프로브에 ACK 오면 → 연결 유지 * N번 무응답이면 → 연결 종료 (ETIMEDOUT or ECONNRESET) 종료 공식 종료까지 시간 = tcp_keepalive_time + (tcp_keepalive_intvl × tcp_keepalive_probes) 기본값 = 7200 + (75 × 9) = 7875초 ≈ 2시간 11분 파라미터 파라미터
Linux
TCP TIME_WAIT
1. TCP 4-Way Handshake — 연결 종료 * 먼저 FIN을 보낸 쪽이 Active closer * Active closer가 최종적으로 TIME_WAIT 상태에 진입 * 흐름: FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSED * Passive closer 흐름: CLOSE_WAIT → LAST_ACK → CLOSED 2. TIME_WAIT 존재 이유 ① 마지막 ACK 유실 보호 * Active closer의 마지막 ACK이
Linux
NUMA (Non-Uniform Memory Access) 아키텍처
1. UMA vs NUMA UMA (Uniform Memory Access) * 모든 CPU가 하나의 공유 메모리에 동일한 접근 시간으로 접근하는 구조 * 구조가 단순하고 프로그래밍이 쉬움 * CPU 수가 늘어나면 메모리 버스에 병목 발생 * 소규모 시스템(데스크탑, 노트북, Raspberry Pi 등)에서 사용 NUMA (Non-Uniform Memory Access) * 각 CPU(또는 CPU 그룹)가 자기만의 로컬
Linux
메모리 증설포인트
메모리 사용량의 선형 증가 → 메모리 누수 의심 * 시간이 지날수록 꾸준히 우상향하는 그래프 * 재시작하면 일시적으로 회복되지만 다시 증가 * 해결책: 누수 원인 코드 수정 (해제 안 된 힙 메모리, 참조 카운트 버그 등) * 증설은 임시방편일 뿐 — 결국 늘어난 메모리도 다 채워버림 메모리 사용량의 급격한 증가 → 워크로드 자체가 커진 것 * 특정 시점(트래픽
Linux
커널의 메모리 재할당
1. /proc/smaps — 프로세스 메모리 상세 분석 /proc/[pid]/maps의 확장판으로, 각 VMA(Virtual Memory Area)별 상세 메모리 통계 제공 핵심 필드 필드 의미 Size가상 주소 공간 크기 (top의 VIRT)Rss실제 물리 메모리 점유량 (top의 RES)Pss공유 비율 보정된 실질 메모리 비용Shared_Clean공유 라이브러리 코드 — 언제든 해제 가능Private_Dirty프로세스가
Linux
Linux 메모리 관리 핵심 정리
1. free 명령 구조 total used free buff/cache available Mem: 7.9G 2.1G 1.2G 4.6G 5.4G 항목 내용 used프로세스 메모리 + SUnreclaim(Slab)buff/cacheBuffers + Cached(page cache) + SReclaimable(Slab)available실제 사용 가능한 메모리 (free + 회수 가능한 buff/cache) 2. buff/cache 세부 구성 항목 역할
Linux
버퍼와 캐시 | /proc/meminfo
1. free -m — 버퍼와 캐시 total used free shared buff/cache available Mem: 3900 1200 300 150 2400 2300 항목 설명 Buffers블록 디바이스 메타데이터 버퍼 (inode, 디렉토리 등)Cached파일 데이터 Page Cacheavailable실제로 사용 가능한 메모리 (캐시 회수분 포함) buff/cache 가 높아도 메모리 부족이 아님 — 커널이 자발적으로 채운 것이며, 필요
Linux
Load Average & 스케줄러 진단
Load Average & 스케줄러 진단 정리 1. Load average 정의 실행 중(R 상태) + 실행 대기 중 + I/O 대기(D 상태) 프로세스 수의 지수 이동 평균. CPU만이 아니라 I/O 대기도 포함된다는 점이 중요합니다. 2. 상대적인 값 절대적인 높낮이 기준은 없으며 CPU 코어 수 기준으로 판단합니다. load average 4.
Linux
CPU Bound vs I/O Bound
항목 CPU Bound I/O Bound 프로세스 상태RDCPU 사용률높음낮음iowait (wa)낮음높음해결 방향CPU 증설 / 알고리즘 최적화디스크 캐싱 / 비동기 I/O vmstat r / b * r : CPU 사용 중이거나 대기 중인 프로세스 수 (R 상태) * r > 코어 수 → CPU 병목 * b : I/O 완료를 기다리는 프로세스 수 (D 상태) * b > 0
Linux
vm.overcommit_memory와 Process Status 및 Priority
1. vm.overcommit_memory 커널이 메모리 할당 요청을 처리하는 방식을 결정하는 파라미터. 오버커밋 = 실제 물리 메모리보다 많은 메모리 요청을 일단 허용하고, 실제로 쓸 때 물리 메모리를 할당하는 방식 값 이름 동작 0휴리스틱 (기본값)커널이 알아서 판단1무조건 허용모든 요청 허용, OOM 위험2엄격한 제한한도 초과 시 즉시 거절 오버커밋이 필요한 이유: fork(