crowny-terminal 감사 조회 메모리 폭증 수리
개요
crowny-terminald(포트 9830) GET /api/audit 엔드포인트가 요청 1회당 원장 크기에
이차적으로(O(n²)) 비례하는 메모리를 소비하던 결함 수리. 원장이 89줄(9.2KB)인데도
rows 모드 조회 1회 피크가 19,431KB(24행 처리)였다 — 행당 800KB의 비정상 증폭.
원장이 커지면 즉시 crownyc STR_ID_MAX(480000)/힙 한계에 걸려 OOM할 위험이 있었다.
원인
한선씨/감사.한선의 감사재생행()(rows 모드)·감사재생()(replay 모드) 둘 다:
- 매 줄
분리(줄들[i], "|")— hanseonc_high의분리()/찾기뒤()는 순수 한선씨
부분()을 호출하고, 부분()은 매 호출
O(len) UTF-8 재스캔이라 사실상 줄당 O(len²) + 후보위치마다 문자열핸들 1개씩 소모.
결과 = 결과 + ...(7필드 중첩 연결)을 매 행마다 반복 — 문자열은 불변 bump-pool이라
수리
crowny-canvas/한선씨/검색.한선의검색_샤드누적()정본 패턴("찾아서 자르기")을
버퍼파일읽기(64KB 절단 없음) → 버퍼찾기(BUF_FIND, C memcmp, 핸들 소모 없음)로
"|"/"\n" 경계를 찾고 버퍼잘라로 필드를 잘라 즉시 버퍼해제 — 배열 리터럴을 전혀
쓰지 않아 "함수 재호출 배열 지역변수 재사용" 함정(요청마다 반복 호출되는 함수라
실제 위험군)도 회피.
- outer 누적은
버퍼추가(BUF_APPEND, O(1) 상각 배가재할당)로 전환 — 문자열 "+" 전체
감사재생행()에오프셋/제한(기본 0/200) 파라미터 추가,total도 함께 반환.
터미널데몬.한선메인 루프:GET /api/audit(rows/replay 둘 다 읽기 전용, 영속
문자열마크()/문자열되감기()로
임시 문자열 풀의 페이지 단조증가를 막음. POST 계열(세션/예산/확인 등 영속 쓰기)은
"문자열되감기 vs 설정() 전역배열 갱신" 함정 때문에 의도적으로 제외.실측
- rows 모드: 19,431KB/req → 20,152B/req(약 965배 개선), steady-state 재측정
- replay 모드: 830KB/req → 21,954B/req.
- 원장 2,500행(227KB, 250행 대비 10배) 격리 스트레스: peak RSS 25,264,128B(250행)
데이터/감사.psv(89줄)는
MD5 불변 확인.
- STRICT 컴파일 0경고(감사.한선·터미널데몬.한선). 셀프테스트 3회 연속 동일:
- curl 기능회귀: 7필드 구조·내부구분자(ᆭ) 미유출·주체/시각 필터·페이지네이션(offset/
관련 파일
/Users/ef/crowny-terminal6561/한선씨/감사.한선—감사재생(),감사재생행()재작성/Users/ef/crowny-terminal6561/한선씨/터미널데몬.한선—GET /api/audit쿼리파싱
- 정본 참조:
/Users/ef/crowny-canvas/한선씨/검색.한선검색_샤드누적()
잔여 이슈
- 다른 POST 엔드포인트(세션/예산/확인/도구호출 등)는 여전히 per-request 메모리
문자열보호() 동반이 필요한 더 큰 작업이라 별도 태스크로 분리 권장.
- 학습:
crownycode-learn.sh add로감사조회_버퍼누적_O1,감사조회_페이지네이션_offset_limit