bruni.log
인덱스·트랜잭션·장애·배포에서 실제로 터지는 문제를 증상 → 원인 → 고치는 법 순서로 한 편씩 정리해요.
AI 모델은 파이썬으로 짜는데 토크나이저·safetensors·Polars·추론 서버 속은 왜 Rust 로 바뀔까요. GPU 앞단의 CPU 일과 GIL, 메모리 안전, PyO3·maturin 패키지 코드까지 보여 주고, 언제 Rust 를 꺼낼지 순서를 정리했어요.
7분 읽기느린 쿼리 로그 1등을 고쳐도 지표가 안 움직이는 건 자주 도는 짧은 쿼리가 로그에 안 잡히기 때문이에요. pg_stat_statements 를 total_exec_time 으로 정렬해 우선순위를 정하고, 호출 수·최댓값·사용자 경로까지 함께 보는 법을 담았어요.
5분 읽기쿼리도 인덱스도 그대로인데 조인 순서가 뒤집혀 느려졌다면 원인은 대개 행 수 추정이에요. EXPLAIN ANALYZE 에서 rows 추정과 actual 이 처음 벌어진 노드를 찾고, ANALYZE·CREATE STATISTICS·서브쿼리로 바로잡는 순서를 정리했어요.
5분 읽기124편 중 1–12
「구글 부업」 90분 영상을 끝까지 보고 정리했어요. 애드센스 수익 배분 68%와 지급일처럼 공식 문서와 맞는 주장, 확인할 수 없는 숫자, 따라 하면 계정이 막힐 수 있는 방법(AI 글 대량 발행·블로그 매매·명의 대여)을 표로 나눠 보여 드려요.
AI 모델은 파이썬으로 짜는데 토크나이저·safetensors·Polars·추론 서버 속은 왜 Rust 로 바뀔까요. GPU 앞단의 CPU 일과 GIL, 메모리 안전, PyO3·maturin 패키지 코드까지 보여 주고, 언제 Rust 를 꺼낼지 순서를 정리했어요.
느린 쿼리 로그 1등을 고쳐도 지표가 안 움직이는 건 자주 도는 짧은 쿼리가 로그에 안 잡히기 때문이에요. pg_stat_statements 를 total_exec_time 으로 정렬해 우선순위를 정하고, 호출 수·최댓값·사용자 경로까지 함께 보는 법을 담았어요.
쿼리도 인덱스도 그대로인데 조인 순서가 뒤집혀 느려졌다면 원인은 대개 행 수 추정이에요. EXPLAIN ANALYZE 에서 rows 추정과 actual 이 처음 벌어진 노드를 찾고, ANALYZE·CREATE STATISTICS·서브쿼리로 바로잡는 순서를 정리했어요.
EXPLAIN 에 Index Scan 이 찍혔는데도 쿼리가 느릴 때 볼 숫자를 정리했어요. shared read·Rows Removed by Filter·loops·Heap Fetches 중 큰 값으로 원인을 가르고 커버링 인덱스·random_page_cost 로 고쳐요.
테이블은 그대로인데 인덱스만 커지는 인덱스 팽창이 무작위 UUID 키·잦은 갱신·대량 삭제에서 빨라지는 이유를 설명해요. 테이블 대비 인덱스 크기 비율로 확인하고, PostgreSQL 12 부터 되는 REINDEX CONCURRENTLY 로 줄이는 법과 예방책을 담았어요.
목록 조회는 빠른데 전체 개수를 세는 COUNT(*) 만 몇 초씩 걸리는 이유를 MVCC 로 설명해요. pg_class 의 reltuples 로 근삿값 읽기, LIMIT 101 로 세다가 멈추기, 집계 테이블, 무한 스크롤로 총 개수 없애기 중 무엇을 고를지 정리했어요.
NOT IN 서브쿼리에 NULL 이 하나라도 있으면 결과가 통째로 비는 이유를 NULL 비교 규칙으로 풀어요. NOT EXISTS 로 바꾸는 법, IS NULL 조회용 부분 인덱스, DB 마다 다른 NULL 정렬 위치와 유니크 제약의 함정도 함께 다뤄요.
다른 컬럼을 OR 로 묶으면 인덱스 하나로 풀 수 없어 순차 스캔으로 빠지기 쉬워요. 같은 컬럼이면 IN 으로, 다른 컬럼이면 UNION ALL 로 나누는 법과 EXPLAIN 에서 BitmapOr·Seq Scan 을 가려 보는 법까지 정리했어요.
같은 커넥션에서 다섯 번은 빠르다가 여섯 번째부터 느려지면 PostgreSQL 이 맞춤 계획에서 일반 계획(generic plan)으로 바꾼 거예요. 치우친 데이터에서 느려지는 이유, 재시작하면 낫는 이유, plan_cache_mode 로 맞춤 계획을 강제하는 법을 정리했어요.
EXPLAIN 에 Sort Method: external merge 가 뜨면 정렬이 work_mem 을 넘어 디스크로 간 거예요. work_mem 이 정렬 작업 하나당 값이라 트래픽이 높을 때만 느려지는 이유와 인덱스로 정렬 없애기, 세션 단위로 올리기를 정리했어요.
필요한 컬럼을 다 넣었는데 PostgreSQL 이 테이블을 다시 읽는 건 가시성 맵 때문이에요. VACUUM 이 표시를 붙이기 전에는 Index Only Scan 이어도 Heap Fetches 가 생겨요. 포함 컬럼(INCLUDE)과 쓰기 많은 테이블의 한계를 정리했어요.
조건에 맞는 글이 없어요. 브루니가 숨었나 봐요.