9.1 KiB

Raw Blame History

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

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

확인 결과

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

9.1 KiB Raw Blame History