teraWeb/backend/REPLACEMENT_UI_PERFORMANCE_20260909.md

# 교체 장비 UI 지연 진단 — 2026-09-09

대상: 192.168.0.223, HTTP 80, COM4, 커널 5.10.160 #23. 사용자가 보고한 화면은 PC 브라우저이다.

## 확인 결과

1. 초기 설정은 11:35:45에 완료됐다(`runtime synchronization completed elapsed_ms=35358`).
2. 이후 11:55:19부터 11:58:17까지 시리얼 상태 조회, 로그 기록 및 저장 공간 조회에서 응답 실패가 발생했다. API 로그에 degraded 메시지가 10개 있었다. 11:58:36에는 시리얼 재조정 복구가 기록됐다.
3. 커널은 부팅 2700.237766초에 CPU0 RCU stall, 2832.568711초에 `irq 95: nobody cared`, 2832.732864초에 `Disabling IRQ #95`를 기록했다. IRQ95 핸들러는 `wch_interrupt`이고 /proc/interrupts의 카운터는 1500000이었다. API 응답 실패와 시간대가 겹친다.
4. 이 장비의 stall 스택에는 네트워크 수신/softirq 및 readlink 경로가 포함된다. task 이름이 tera-seriald라는 사실만으로 사용자 공간 시리얼 코드가 직접 원인이라고 단정하지 않는다. 이전 장비의 #22 스택과도 구분해야 한다.
5. 내부 브라우저는 `matrix-browser -no-sandbox --disable-gpu 127.0.0.1`로 실행된다. matrix-browser와 렌더러를 몇 초간 SIGSTOP한 비교에서, vmstat의 구간별 전체 CPU 사용량은 약 43%에서 12~16%로 감소했다. SIGCONT와 자동 복구용 watchdog으로 원상 복구했고 두 프로세스의 실행 상태를 확인했다. 서비스 시작 설정은 변경하지 않았다.
6. 장애 기록 이후 시점의 설정 읽기 및 두 시리얼 상태 요청을 포함한 진단 helper는 52ms에 완료됐다. 이 수치는 장애가 발생한 시간대의 API 지연이나 로그인된 PC 화면의 응답 시간을 대체하지 않는다.

## 판단과 한계

- 설정 완료 이후에도 운영 중 장비 측 정체가 발생한다. 로그인 대기 연장으로 이후 장애를 예방할 수 없다.
- 내부 브라우저의 지속적인 CPU 부하는 별도로 확인됐으나, 이것만으로 PC 화면 지연의 단독 원인이라고 단정할 수 없다.
- API의 복구 메시지는 WCH IRQ 또는 실제 시리얼 송수신 복구를 보장하지 않는다.
- 커널/드라이버의 최초 장애 유발 조건과 개별 PC 메뉴의 지연 시간은 아직 확정하지 않았다. 로그인된 진단 브라우저가 필요하다.
- 이번 확인에서는 커널, IRQ 설정, HTTP 포트, 9600bps 설정, 배포 파일을 변경하지 않았다.

## 후속 확인

- 로그인된 PC 화면에서 메뉴별 응답 및 표시 지연을 기록하고 장비 로그와 비교한다.
- 커널 담당자에게 #23의 RCU stall 및 WCH IRQ95 차단 로그를 전달해 인터럽트 처리 원인을 확인한다.
- 내부 화면이 필요한 운영 조건을 유지하면서 불필요한 렌더링 부하를 줄인다.

## 로그인 후 PC 브라우저 확인

사용자가 진단 브라우저에 로그인한 뒤, 설정을 적용하거나 저장하지 않고 메뉴를 전환했다. 시간은 자동 클릭 시작부터 접근성 화면 확인까지의 관측 시간이며, 브라우저 자동화 왕복/관측 비용을 포함한다. API 단독 소요 시간이나 정밀 렌더링 프로파일은 아니다.

| 화면 | 관측 시간 |
| --- | --- |
| 네트워크 설정 | 390ms, 재확인 251ms |
| 포트 설정 | 388ms, 재확인 350ms |
| 포트 상태 | 447ms, 재확인 384ms |
| 대시보드 | 336ms, 재확인 318ms |
| 시스템 로그 | 100건 표시 확인 813ms |

확인 중 수집된 브라우저 error/warn 로그는 없었고, 수초 단위의 심한 지연은 재현하지 못했다. 포트 설정 화면의 9600bps도 확인했다. 진단 후 대시보드로 돌아왔다. 부팅 직후나 앞서 기록된 장비 장애 중의 동작은 이 결과로 검증되지 않는다. 현재의 정상 전환을 근거로 장애 해결을 선언하지 않는다.

## 사용자 승인 재부팅 후 확인 (12:17경 재부팅)

- COM4에서 정상 종료 및 새 커널 부팅, 로그인 프롬프트를 수집했다. 원시 기록은 `../runtime/reboot-ui-20260909.log`에 있다.
- 사용자의 콘솔 로그인 후 12:22:47(가동 약 5분)에 vmstat를 수집했다. 구간별 user+system은 52%, 62%, iowait는 16%, 13%였다. 이 시점은 전원 인가 직후 수십 초와는 구분한다.
- `/api/v1/auth/startup` 응답은 ready=true, 12/12, elapsed_ms=327015였다. 로그인 화면도 준비 시간 327초를 표시했다.
- 현재 부팅의 dmesg 검색에서는 RCU stall/IRQ 차단 메시지를 찾지 못했다. 이전 부팅에서 발생한 장애를 이번 부팅에 발생했다고 간주하지 않는다.
- uptime 409.27초에서 411.32초 사이 IRQ95는 398728에서 400840으로 증가했다(약 1030회/초). IRQ99는 1772에서 1782로 증가했다. 발생 횟수만으로 IRQ 장애라고 판정하지 않는다.
- tera-api의 stdout/stderr는 /dev/null이다. 완료된 startup 응답에는 단계별 소요 시간이 없어, 이번 준비 327초의 지배 단계나 PC 시간 동기화 대기 비중을 사후 확정할 수 없다.
- 기존 진단 탭은 종료되어 사용자 로그인 후 UI 측정이 이어지지 않았다. 새 진단 탭을 열었고 로그인 입력을 요청했다. 이 구간의 로그인 후 메뉴 지연을 측정했다고 보고하면 안 된다.

다음 부팅 검증에는 부팅 전에 단조 시간 기준의 단계별 준비 상태·CPU·API 소요 시간 수집을 마련해야 한다. 현재 결과로 로그인 준비 단계 누락 또는 커널 장애 하나를 원인으로 확정하지 않는다.

## 이번 부팅의 로그인 후 지연 재현 (12:25경, uptime 약 8분)

- 새 진단 탭 로그인 후 메뉴 전환을 실행했다. 클릭 후 첫 접근성 관측(약 250~350ms)은 이전 화면을 표시했다. 따라서 이 관측 시간을 화면 전환 완료 시간으로 사용하면 안 된다.
- 포트 설정 이동에서 URL 변경과 화면을 기다린 관측은 2773ms였다. 그 시점에는 9600 설정값이 아직 표시되지 않았고, 다음 관측에서는 표시됐다. 별도 네트워크 메뉴 전환 대기도 시간 초과 후 다음 관측에서 완료돼 지연이 확인됐다.
- integration.js의 navigateWithinConsole는 navigating=true이면 새 요청을 반환해 무시하고, initializeCurrentPage의 데이터 로딩을 기다린 다음에야 navigating=false로 바꾼다. 연속 메뉴 클릭이 반영되지 않는 체감에 기여하는 구현이다. HTML/API/브라우저 각각의 지배적 지연 시간은 아직 분리하지 못했다.
- 이 시점 vmstat는 user+system 약 54%, iowait 0%였다. dmesg에는 새 RCU stall/IRQ 차단 검색 결과가 없었다. 앞선 iowait 13~16%가 계속 유지된다고 보고하지 않는다.
- 장비 내부 loopback에서 비인증 로그인 HTML을 wget으로 읽는 시간은 7ms, 10ms, 6ms였다. 인증된 화면/API 및 PC 네트워크의 지연을 이 측정으로 배제하지 않는다.
- 브라우저 error/warn 로그는 없었다. 설정 변경이나 커널 수정은 하지 않았다.

## 적용 수정

- 메뉴 초기화 중 마지막 이동 요청을 보존한다. 초기화를 겹쳐 실행하지 않으므로 이전 화면 요청이 새 폼에 값을 기록하는 경쟁을 피한다. 인증 만료 시 이동 대기는 폐기한다.
- 포트 설정 화면은 `GET /api/v1/ports?limit=48&runtime=false`로 저장된 실행 설정을 먼저 읽는다. 이 선택적 조회에서는 시리얼/세션 런타임 수집을 호출하지 않는다. 권한 검사와 포트별 필터는 동일하며, 기본 API 응답은 기존 실시간 동작을 유지한다.
- 선택적 설정 응답은 미관측 링크를 unknown으로 취급한다. 설정 폼을 채운 뒤 기존 런타임 폴링을 별도로 시작한다. PATCH/적용·로그인 준비 판정·9600bps·HTTP80 설정은 수정하지 않는다.
- 검증: JavaScript 49개 통과, backend internal/api·adapters/mock·startup 통과, frontend internal/handlers·service 통과. ARM64 API/웹 빌드 성공.
- 이 수정은 포트 설정의 런타임 대기와 메뉴 클릭 무시를 줄이는 범위다. 모든 메뉴의 장비 측 지연 또는 커널 장애가 해결됐다는 뜻은 아니다.

## 배포 시도 및 복구

API/웹 두 파일만 교체하는 배포를 시도했다. 12:36:28 백업 위치는 `/userdata/tera-backups/config-read-20260909-123628`이다. 준비 상태가 7/12에서 지연돼 자동 복구했고 12:40:39 복구 완료 로그를 확인했다. 이 과정에서 새 부팅의 커널에 uptime 1308초 RCU stall, 1411.077981초 `Disabling IRQ #95`, GPU dvfs timeout이 기록됐다. 수정된 설정 조회가 이 장애를 촉발했다는 증거는 없으며, 기존 부팅에서도 같은 유형의 IRQ 차단이 있었다.

복구 후 API SHA256은 `ef466f00788868617d8528a10ee597e2119ca6965eb81ed5e5e89bfc8a87536f`, 웹은 `2b7001dd33ad07c9a1886712926384e065c0c09c0715873f30b107969bc23eb9`로 이전 파일과 일치했다. 준비 상태는 12/12, 8383ms, CAPTCHA true였다. 이는 IRQ 또는 실물 포트 송수신 복구의 증거가 아니다. 수정 빌드는 `build/linux-arm64`에 있으며 장비에는 적용되어 있지 않다. 전송 및 커널 원시 기록은 `../runtime/config-read-transfer.log`에 있다.