증상 운영 중인 서비스 사이트 접속이 눈에 띄게 느려졌습니다. 페이지 하나 뜨는 데 5초 가까이 걸렸고, 어떤 요청은 응답이 아예 안 오다시피 했습니다. 서버는 Oracle Cloud 인스턴스에서 Docker로 여러 서비스를 함께 돌리고 있었고, 최근에 딱히 뭔가를 바꾸지도 않은 상태였습니다. 원인을 좁혀나간 과정 1. 구간별로 나눠서 시간을 재기 막연히 “느리다”에서 시작하면 어디를 고쳐야 할지 알 수 […]
문제 상황 어느 날 서버 메모리 사용률을 확인했는데 심상치 않았다. 전체 23Gi 중 19Gi가 실사용 중이었고, 이미 캐시(buff/cache)까지 다 밀어내고 스왑을 3.2Gi나 쓰는 상태였다. 스왑까지 밀린다는 건 물리 메모리가 완전히 고갈됐다는 뜻이라, 방치하면 서비스 응답 지연이나 최악의 경우 OOM(Out Of Memory)으로 컨테이너가 강제 종료될 수 있는 위험한 신호였다. 첫 번째 용의자: Nextcloud 마침 Nextcloud 앱을
Proxmox VM(Ubuntu 24)에서 개인 서버를 운영하면서 겪은 세 가지 트러블슈팅을 기록해둔다. 1. DuckDNS 와일드카드 인증서 발급 배경 기존에 쓰던 apex 도메인(example.duckdns.org)은 이미 여러 nginx 설정에서 광범위하게 사용 중이었다. 여기에 와일드카드 인증서를 추가로 발급하려다 보니, DuckDNS의 근본적인 제약을 다시 마주쳤다. DuckDNS는 서브도메인당 TXT 레코드를 1개만 저장할 수 있다. apex와 와일드카드를 같은 인증서에 넣으면 둘 다 _acme-challenge.example.duckdns.org라는
집이나 사무실에서 VPN을 켜면 보통 모든 트래픽이 다 그쪽으로 몰리죠. 근데 저는 특정 사이트 하나만 골라서 우회하고 싶었습니다. 유튜브도, 카톡도, 다른 브라우저 탭도 평소처럼 쓰고, 딱 그 사이트만 서버를 거쳐서 나가게 하고 싶었어요. 찾아보니 “크롬 확장이 알아서 탭 단위로 VPN을 태워준다” 같은 건 없더라고요. 그래서 직접 만들어봤습니다. 이 글은 그 과정과 원리를 정리한 겁니다. 왜
자체 개발한 라이브 스트림 녹화 도구(Python/FastAPI + yt-dlp 기반)에 작은 기능 하나를 추가한 이야기다. 새로운 스케줄러나 백그라운드 작업을 새로 만들지 않고, 기존에 이미 돌고 있던 감시 루프를 그대로 활용해서 구현했다. 문제 이 도구는 채널을 등록해두면 방송이 시작되는 걸 자동으로 감지해서 녹화를 시작한다. 그런데 녹화 도중 Stop 버튼을 눌러 수동으로 멈춰도, 몇 초 뒤 감시 루프가
배경 집에서 운영 중인 Proxmox 호스트에는 이미 VM 상태와 로컬 저장소 사용량을 정리해서 매일 메일로 보내주는 쉘 스크립트가 하나 있었다. qm list, pvesh 같은 Proxmox 전용 명령으로 VM별 CPU/메모리/디스크 정보를 뽑고, df로 로컬 스토리지 현황을 더해 HTML 메일로 발송하는 구조였다. 문제는 이 스크립트가 딱 “이 서버 자신”의 정보만 알고 있다는 점이었다. 클라우드에 따로 띄워둔 인스턴스
Docker Compose로 운영 중인 자체 개발 라이브 스트림 녹화 도구(Python/FastAPI + yt-dlp 기반)에서 겪은 문제를 정리한다. 증상 한 채널의 녹화 파일을 열어보니 재생시간은 3시간에 가까운데 용량은 200MB 남짓으로 비정상적으로 작았다. 재생해보면 앞부분은 정상적으로 나오는데, 재생 위치를 중간으로 옮기면 그대로 멈췄다. 원인 추적 앱이 채널별로 남기는 실행 로그를 다시 확인해보니, 방송 도중 이런 에러가 있었다. 이
블로그를 서브도메인(ts.world-currency.org)에서 루트 도메인(world-currency.org)으로 옮기는 작업을 하던 중, sitemap이 새 도메인으로 안 뜨는 문제를 겪었다. 원인이 한 겹이 아니라 세 겹으로 쌓여 있어서 정리해둔다. 증상 브라우저로 열면 XSLT 스타일시트를 cross-origin으로 못 불러와서 빈 화면처럼 보이기도 했다. 원인 1: nginx가 엉뚱한 컨테이너로 프록시 중이었음 루트 도메인의 location /이 이미 안 쓰는 다른 컨테이너로 프록시되고 있었고, 그
Docker Compose로 운영 중인 자체 개발 라이브 스트림 녹화 도구(Python/FastAPI + yt-dlp 기반)에서 며칠에 걸쳐 겪은 문제들을 시간 순으로 정리한다. 겉으로는 서로 다른 증상이었지만, 되짚어보면 몇 가지 반복되는 패턴이 있었다. 1. 특정 채널만 녹화가 계속 실패한다 증상 특정 라이브 채널만 이 에러를 반복하며 녹화에 실패했다. 원인 화질(quality) 설정값을 yt-dlp 포맷 셀렉터로 변환하는 로직에 “lowest”(최저화질) 값을
Docker Compose로 운영 중인 자체 개발 라이브 스트림 녹화 도구(Python/FastAPI + yt-dlp 기반)에서 겪은 상태 동기화 버그를 정리한다. 증상 매일 자정 cron으로 발송되는 “어제 하루 녹화 요약” 메일에서, 실제로는 자정 시점에 라이브 녹화가 진행 중이었는데도 메일에는 “현재 녹화 중 – 0건”으로 표시됐다. 요약 메일 발송 스크립트는 별도로 동작하며, 앱이 디스크에 기록하는 상태 파일(state.json)을 직접 읽어서