TCP 패킷 디버깅

1. SYN 없이 ACK만 보이는 이유 캡처 시작 전에 이미 연결이 맺어진 상태라서그렇다. Wireshark 켰을 때 세션이 살아있으면 3-way handshake는 이미 끝난 거고 중간부터 잡히는 것. BPF 필터로 연결 과정만 골라서 캡처할 수 있음. # SYN만 tcpdump -i eth0 'tcp[13] = 2' # SYN-ACK만 tcpdump -i eth0 'tcp[13]

NIC의 RingBuffer 확인

네트워크 대역폭은 크지만 서버의 네트워크 속도가 느릴때 패킷이 드랍되는 현상이 발견되었을때 조치방법중 하나 1. 게이트웨이로 나가는 디폴트 이더넷 인터페이스를 확인한다. - ip route show를 사용   2. ethtool -g eth0 명령어로 ringBuffer Parameter 확인 진행 * maximums 로 NIC의 RX, TX 최대 링버퍼 슬롯 개수를 확인 * current로 현재 설정된 RX, TX 슬롯

슬랙이 연결을 끊었다.

슬랙 웹훅 알림 메시지 유실로인한 문제를 tcpdump를 활용하여 디버깅했던 내역을 정리   1. 증상 신규 운영환경 모니터링 시스템 구축 중 슬랙 메시지가 간헐적으로 오지않는것을 확인  * 서버에서 Slack webhook 메시지 전송 시 간헐적 실패 * 상대편이 연결을 끊었다는 로그 확인 * 약 10건 중 1~2건 실패, 랜덤하게 발생 * 같은 webhook URL을 쓰는 다른

로드밸런서 세션 테이블 & DSR & Idle Timeout

핵심 개념 로드밸런서 세션 테이블 * L4 로드밸런서는 클라이언트 패킷을 어떤 백엔드로 보낼지 추적하기 위해 세션 테이블을 메모리에 유지 * 자원이 유한하므로 idle timeout 이후 엔트리 삭제 * 삭제 후 클라이언트가 같은 연결로 패킷을 보내면 → 로드밸런서가 RST 반환 DSR (Direct Server Return) * 응답 트래픽이 로드밸런서를 우회하여 서버 → 클라이언트로 직접 전달 * 로드밸런서가 응답 패킷을

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분 파라미터 파라미터

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이

NUMA (Non-Uniform Memory Access) 아키텍처

1. UMA vs NUMA UMA (Uniform Memory Access) * 모든 CPU가 하나의 공유 메모리에 동일한 접근 시간으로 접근하는 구조 * 구조가 단순하고 프로그래밍이 쉬움 * CPU 수가 늘어나면 메모리 버스에 병목 발생 * 소규모 시스템(데스크탑, 노트북, Raspberry Pi 등)에서 사용 NUMA (Non-Uniform Memory Access) * 각 CPU(또는 CPU 그룹)가 자기만의 로컬

메모리 증설포인트

메모리 사용량의 선형 증가 → 메모리 누수 의심 * 시간이 지날수록 꾸준히 우상향하는 그래프 * 재시작하면 일시적으로 회복되지만 다시 증가 * 해결책: 누수 원인 코드 수정 (해제 안 된 힙 메모리, 참조 카운트 버그 등) * 증설은 임시방편일 뿐 — 결국 늘어난 메모리도 다 채워버림 메모리 사용량의 급격한 증가 → 워크로드 자체가 커진 것 * 특정 시점(트래픽

커널의 메모리 재할당

1. /proc/smaps — 프로세스 메모리 상세 분석 /proc/[pid]/maps의 확장판으로, 각 VMA(Virtual Memory Area)별 상세 메모리 통계 제공 핵심 필드 필드 의미 Size가상 주소 공간 크기 (top의 VIRT)Rss실제 물리 메모리 점유량 (top의 RES)Pss공유 비율 보정된 실질 메모리 비용Shared_Clean공유 라이브러리 코드 — 언제든 해제 가능Private_Dirty프로세스가

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 세부 구성 항목 역할

버퍼와 캐시 | /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 가 높아도 메모리 부족이 아님 — 커널이 자발적으로 채운 것이며, 필요

Load Average & 스케줄러 진단

Load Average & 스케줄러 진단 정리 1. Load average 정의 실행 중(R 상태) + 실행 대기 중 + I/O 대기(D 상태) 프로세스 수의 지수 이동 평균. CPU만이 아니라 I/O 대기도 포함된다는 점이 중요합니다. 2. 상대적인 값 절대적인 높낮이 기준은 없으며 CPU 코어 수 기준으로 판단합니다. load average 4.