kdh93

1. TCP Keepalive — 죽은 연결 감지목적: idle 연결에서 상대방 생존 여부 확인동작 주체: 커널프로브에 ACK 오면 → 연결 유지N번 무응답이면 → 연결 종료 (ETIMEDOUT or ECONNRESET)종료 공식종료까지 시간 = tcp_keepalive_time + (tcp_keepalive_intvl × tcp_keepalive_probes)기본값 = 7200 + (75 × 9) = 7875초 ≈ 2시간 11분파라미터파라미터 기본값 의미tcp_keepalive_time7200초마지막 데이터 후 첫 프로브까지 대기tcp_keepalive_intvl75초프로브 재전송 간격tcp_keepalive_probes9회최대 프로브 횟수종료 방식상황 종료 방식호스트 다운 (응답 없음)ETIMEDOU..

1. TCP 4-Way Handshake — 연결 종료먼저 FIN을 보낸 쪽이 Active closerActive closer가 최종적으로 TIME_WAIT 상태에 진입흐름: FIN_WAIT_1 → FIN_WAIT_2 → TIME_WAIT → CLOSEDPassive closer 흐름: CLOSE_WAIT → LAST_ACK → CLOSED2. TIME_WAIT 존재 이유① 마지막 ACK 유실 보호Active closer의 마지막 ACK이 유실되면 Passive closer가 FIN을 재전송TIME_WAIT 동안 소켓을 살려둬야 재전송 FIN에 ACK 응답 가능소켓이 없으면 커널이 RST로 응답 → 비정상 종료② 지연 패킷(Stale packet) 차단동일 4-tuple로 새 연결이 즉시 맺어지면 이전 ..

1. UMA vs NUMAUMA (Uniform Memory Access)모든 CPU가 하나의 공유 메모리에 동일한 접근 시간으로 접근하는 구조구조가 단순하고 프로그래밍이 쉬움CPU 수가 늘어나면 메모리 버스에 병목 발생소규모 시스템(데스크탑, 노트북, Raspberry Pi 등)에서 사용NUMA (Non-Uniform Memory Access)각 CPU(또는 CPU 그룹)가 자기만의 로컬 메모리를 보유다른 CPU의 메모리에도 접근 가능하지만, 인터커넥트를 경유하므로 시간이 더 걸림대규모 멀티소켓 서버에서 확장성을 확보하기 위해 사용접근 구조 비교UMA: CPU → 공유 버스 → 메모리 (모든 CPU가 동일 지연시간)NUMA: CPU₁ → 로컬 메모리₁ (빠름) / CPU₁ → 원격 메모리₂ (느림..

메모리 사용량의 선형 증가 → 메모리 누수 의심시간이 지날수록 꾸준히 우상향하는 그래프재시작하면 일시적으로 회복되지만 다시 증가해결책: 누수 원인 코드 수정 (해제 안 된 힙 메모리, 참조 카운트 버그 등)증설은 임시방편일 뿐 — 결국 늘어난 메모리도 다 채워버림메모리 사용량의 급격한 증가 → 워크로드 자체가 커진 것특정 시점(트래픽 급증, 대용량 배치 처리 등)에 스파이크피크 사용량을 측정해 적정 증설 규모 계산이 경우엔 증설이 실질적인 해결책추가로 고려할 포인트패턴 진단 도구 조치선형 증가valgrind, heap profiler, /proc/[pid]/smaps코드 수정급격한 증가sar -r, free -s, 피크 시점 top 스냅샷증설 또는 캐시 튜닝혼합형두 도구 병행누수 수정 후 재측정, 그 다..

1. /proc/smaps — 프로세스 메모리 상세 분석/proc/[pid]/maps의 확장판으로, 각 VMA(Virtual Memory Area)별 상세 메모리 통계 제공핵심 필드필드 의미Size가상 주소 공간 크기 (top의 VIRT)Rss실제 물리 메모리 점유량 (top의 RES)Pss공유 비율 보정된 실질 메모리 비용Shared_Clean공유 라이브러리 코드 — 언제든 해제 가능Private_Dirty프로세스가 실제로 소유한 메모리 (힙, 스택, CoW 후 수정)Swap스왑으로 내보내진 페이지 수Anonymous파일 백킹 없는 익명 메모리 (malloc, 스택 등)PSS가 중요한 이유4개 프로세스가 400KB 공유 라이브러리 사용 시RSS: 각 400KB → 합계 1600KB (과대계상)PSS: ..

1. SYN 없이 ACK만 보이는 이유캡처 시작 전에 이미 연결이 맺어진 상태라서그렇다.Wireshark 켰을 때 세션이 살아있으면 3-way handshake는 이미 끝난 거고 중간부터 잡히는 것.BPF 필터로 연결 과정만 골라서 캡처할 수 있음.# SYN만tcpdump -i eth0 'tcp[13] = 2'# SYN-ACK만tcpdump -i eth0 'tcp[13] = 18'# 둘 다 (3-way handshake 전체)tcpdump -i eth0 'tcp[13] = 2 or tcp[13] = 18'tcp[13]이 TCP 헤더에서 플래그 필드 위치고, SYN=2, SYN+ACK=18 이렇게 값이 나온다.2. Seq랑 Ack가 뭔지Seq = 내가 보내는 데이터가 전체 스트림에서 몇 번째 바이트부터인지..

1. free 명령 구조 total used free buff/cache availableMem: 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 세부 구성항목 역할Buffers블록 디바이스의 메타데이터 캐시 (슈퍼블록, inode 테이블 등)Cached한 번 읽은 파일 내용을 보관하는 page cacheSReclaimable해제 ..

1. free -m — 버퍼와 캐시 total used free shared buff/cache availableMem: 3900 1200 300 150 2400 2300항목 설명Buffers블록 디바이스 메타데이터 버퍼 (inode, 디렉토리 등)Cached파일 데이터 Page Cacheavailable실제로 사용 가능한 메모리 (캐시 회수분 포함)buff/cache 가 높아도 메모리 부족이 아님 — 커널이 자발적으로 채운 것이며, 필요 시 즉시 회수됨메모리 여유 판단 기준 = available2. /proc/meminfo — 상세 메모리 정보free -m ..

1. ORDER BY 절에서 인덱스 활용인덱스 구성인덱스: (장비번호, 변경일자, 변경순번)인덱스를 활용하는 경우SELECT *FROM 상태변경이력WHERE 장비번호 = 'C'ORDER BY 변경일자, 변경순번WHERE 장비번호 = 'C'로 첫 번째 컬럼 고정ORDER BY 변경일자, 변경순번이 인덱스의 두 번째, 세 번째 컬럼 순서와 일치Sort Order By 생략 가능 → 성능 향상인덱스를 활용하지 못하는 경우SELECT *FROM 상태변경이력WHERE 장비번호 = 'C'ORDER BY 변경일자 || 변경순번변경일자 || 변경순번은 연산식(함수 표현식)인덱스는 개별 컬럼별로 정렬되어 있지, 연결된 문자열 기준이 아님별도 정렬 작업 필요 → 성능 저하핵심 원리검색: 두 쿼리 모두 인덱스를 잘 활용정렬..

Load Average & 스케줄러 진단 정리1. Load average 정의 실행 중(R 상태) + 실행 대기 중 + I/O 대기(D 상태) 프로세스 수의 지수 이동 평균. CPU만이 아니라 I/O 대기도 포함된다는 점이 중요합니다.2. 상대적인 값 절대적인 높낮이 기준은 없으며 CPU 코어 수 기준으로 판단합니다. load average 4.0은 1코어면 포화 상태지만 4코어면 딱 적정 수준입니다.3. 절대적으로 신뢰하면 안 된다 커널 버그(D 상태 계산 오류 등)로 실제와 다르게 튀는 사례가 있습니다. 진단 도구로 /proc/sched_debug를 쓸 수 있지만, Raspberry Pi처럼 CONFIG_SCHED_DEBUG=y임에도 파일이 없는 경우도 있습니다. 대안으로 /proc/schedstat..