피드로 돌아가기
Dev.toInfrastructure
원문 읽기
Tokio Runtime 격리 설계를 통한 로봇 제어 루프 47ms 지연 완전 제거
I Spent 3 Months Tuning a Tokio Runtime for My Robot — Here's What No Tutorial Tells You
AI 요약
Context
#[tokio::main] 기반의 단일 Runtime 구조에서 Work-stealing 스케줄러가 제어 루프와 I/O 작업을 동일 우선순위로 처리하며 발생한 병목 현상 분석. 특히 moteDB의 Batch Write 작업이 센서 폴링 태스크를 Preempt 하여 47ms 간격의 프레임 드롭이 발생하는 구조적 한계 노출.
Technical Solution
- 전용 Runtime 분리를 통한 Critical Path 격리: 제어 루프용 1-thread Runtime과 백그라운드 I/O용 2-thread Runtime을 개별 구축하여 스케줄러 간섭 차단
- OS 레벨 Thread Priority 적용: 제어 루프 전용 스레드에 Max Priority를 부여하여 커널 수준의 실행 우선순위 보장
- 동기화 프리미티브 최적화: Lock Hold 시간이 마이크로초 단위인 경우, Task Switching 오버헤드가 큰 tokio::sync::Mutex 대신 std::sync::Mutex를 채택하여 지연 시간 단축
- 스레드 풀 고갈 방지: 빈번한 센서 직렬화 작업에 spawn_blocking 대신 std::thread::spawn을 사용해 공유 Blocking Pool의 리소스 고갈 방지
- Non-blocking 쓰기 전략 도입: WAL(Write-Ahead Logging) 기반의 Append-only 쓰기 구조를 통해 인덱스 업데이트와 쓰기 경로를 분리하여 제어 루프 영향 최소화
Impact
- 제어 루프 내 발생하던 47ms 주기적 프레임 드롭 현상 완전 제거 및 3개월간의 안정적 구동 확인
실천 포인트
1. 실시간성이 중요한 임베디드 시스템에서 #[tokio::main] 사용 지양 및 Runtime Builder를 통한 물리적 격리 검토
2. Lock 유지 시간이 매우 짧은 Hot Path에서는 Async Mutex보다 Std Mutex의 성능 우위 확인
3. I/O 집약적 작업이 Critical Path의 스케줄링을 방해하지 않도록 전용 스레드 풀 및 Non-blocking 스토리지 설계 적용