Sunday Service
Ye의 9집 티셔츠는 도저히 못입고 다니겠다. 음악만 사랑하는걸로 바이닐이 이쁘기로 소문난 앨범 실물로 보아야 더 이쁘다. 0:00 /0:10 1×
Latest
mybloodyvalentine 3집 loveless
마이블러디발렌타인의 정규 2집 loveless 엘피를 김밥레코즈에서 5만원가량의 금액으로 구매. 요건 평생 들어도 질리지않을거같아 바이닐로 구매했다. 물리적인 이슈가 발생하지않는 한 이제 스트리밍 플랫폼의 의존성없이 평생 청취 가능하다 내부 크레딧 개인적으로 빌린다 부처의 맥아리없는 보컬을 참 좋아한다. 바이닐 커버를 벗기면 평범하다 0:00 /0:12 1× 2집 loveless만큼 3집 mbv도 좋아해서 아마
Audio-Technica at-lp60
오디오 테크니카에서 하나 장만했다. 그냥 제일 싸서 샀다. 자주 들을거같지도 않고 사실 뭐가 좋은지도 모르겠다 그냥 LP판 올리니까 뭐가 막 들린다. 다 돌아가면 판떼기도 내가 직접 뒤집어줘야된다. Mission Control 오직 Bully Physical에서만 불리 머천다이즈로 마무리..
strace
1. 개요 strace는 프로세스가 커널에 요청하는 시스템 콜(system call) 을 실시간으로 추적하는 도구. 내부적으로 ptrace() 시스템 콜을 이용해 user space → kernel space 전환 시점을 가로챔. User Space → syscall → Kernel Space ↑ strace가 ptrace()로 가로챔 2. 주요 시스템 콜 시스템 콜 의미 open() / openat() 파일 열기 read() / write() 파일/소켓
Ye
어제 진행된 Ye의 Sofi stadium LIVE 실황을 보다가 생각나서 작년 7월이 생각나는
Ghost Blog Infra Architecture
GitHub - kwon93/ghost-blog: ghost-blog-infraghost-blog-infra. Contribute to kwon93/ghost-blog development by creating an account on GitHub.GitHubkwon93 1. ec2에 띄울까 고민하다.. Blog다 보니까 경제적으로 관리측면에서나 가벼운 라이트세일로 결정 ec2에 비해 커스텀이 제한된다는게 아쉽긴하지만 확실히 비용적인 측면에서는 마음에 든다. 2. user data 변경시에 라이트세일 인스턴스가 모두 초기화가 된다. 기존 인스턴스의 60gb의
Linux I/O 스케줄러 학습 정리
1. HDD 성능 최적화: 병합(Merge)과 정렬(Sort) HDD는 물리적 헤드 이동 비용이 크기 때문에 커널 I/O 스케줄러가 두 가지 최적화를 수행한다. 병합 (Merge) 인접한 I/O 요청을 하나로 합쳐 헤드 이동 횟수와 시스템 콜 오버헤드를 줄인다. 요청 A: sector 100~107 요청 B: sector 108~115 → 병합:
TCP 재전송과 Read, Connection timeout
1. 세 개념의 정의 주체 레이어 무엇을 기다리나 RTO 커널 TCP 커널 ACK Connection Timeout 애플리케이션 앱 3-way handshake 완료 Read Timeout 애플리케이션 앱 데이터 수신 2. Connection Timeout의 범위 * SYN / SYN-ACK 구간만 해당 * 이 시점은 RTT 샘플이 없으므로 initRTO = 1초 고정 사용 * 3번째 ACK부터는 RTT 측정 완료 → 동적 RTO
tux
TCP 재전송 (Retransmission)
1. RTO (Retransmission Timeout) 종류 구분 설명 initRTO 연결 초기, RTT 샘플이 없을 때 사용하는 초기값 (기본 1초) RTO RTT 샘플 기반으로 동적 계산되는 재전송 타임아웃 RTO 계산 (RFC 6298) RTO = SRTT + 4 × RTTVAR SRTT : Smoothed RTT (평활 왕복 시간) RTTVAR : RTT 분산 (변동폭) * ACK가 돌아올 때마다 SRTT, RTTVAR 갱신
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 슬롯
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(