SPA(단일 페이지 응용 프로그램)로 HTTP를 통해 GUI/Cockpit 보기를 제공하는 컨트롤러가 있습니다.
지금 내 프로젝트는 이 "웹사이트"(SPA)를 표시하기 위한 조종석 컴퓨터를 갖는 것입니다.
저는 초고속으로, 이상적으로는 Chromium으로 10~15초 만에 부팅되는 Linux가 필요합니다.
...누구도 엔진 데이터(예: 현대 자동차의 HUD 디스플레이)를 보기 위해 30분 정도 기다리고 싶어하지 않기 때문입니다.
이 Linux 시스템에서는 이외에도
- Intel 드라이버가 포함된 Xorg
- 크롬
Intel Atom x5-Z8350 x64에서 실행됩니다. EFI에는 1초가 걸립니다.
Naked Debian을 사용해 보았지만 24초밖에 단축할 수 없었습니다(페이지 로드 시 부팅)
누구든지 올바른 방향으로 나를 가리킬 수 있습니까? 내 사용 사례에 완벽하게 맞는 배포판이 있나요? 이와 같은 검색어를 모르겠습니다.
Systemd-analyze plot:
창업 과정을 영상으로 만들어 봤습니다. 테스트 사이트에 노란색 "two.js" 텍스트가 표시되면 시스템이 시작됩니다.
답변1
생성된 SVG를 살펴보면 일반적으로 시스템 시스템에서 시작 프로세스를 최적화하는 것이 잘 작동합니다 systemd-analyze. IIRC에서는 루트 액세스도 필요하지 않습니다.
systemd-analyze plot > boot.svg
firefox boot.svg
이제 필요하지 않은 모든 시스템 장치를 실제로 비활성화하거나 차단했다고 생각하고 네트워크 파일 시스템 마운트를 지연하거나 DHCP를 기다리는 대신 IPv4 주소를 하드코딩하는 등 할 수 있는 일이 없다면 시간이 걸립니다. 스토리지 부팅입니다. 예를 들어 내 경험상 Ext4는 XFS보다 부팅 시 로그를 확인하는 데 시간이 조금 더 걸리는 경향이 있지만 eMMC에서는 이것이 눈에 띄지 않을 것이라고 생각합니다. 더 큰 영향을 미칠 수 있는 것은 압축된 루트 파일 시스템을 사용하는 것입니다. 전체 OS를 로드하거나 압축되지 않은 eMMC에서 더 나쁜 크롬을 로드하는 것은 압축을 푸는 것보다 더 오래 걸릴 수 있습니다. 병목 현상은 CPU 성능보다는 스토리지 대역폭 때문일 것입니다. Btrfs 및 ZFS는 압축을 지원합니다. eMMC 장치의 경우 zstd 압축을 사용하여 F2FS에 상주하는 것이 좋습니다(Linux 5.7 이상 필요, 그렇지 않으면 기본 LZO 사용). 이 사용 사례에 맞게 최적화되었습니다.
예를 들어, 나는 내 모든 시스템에서 LVM을 사용합니다(원칙적으로는 적용되지 않습니다. "아, 이 파일 시스템을 디스크 전체로 확장할 수 있다면 어떨까요?" 또는 "안전한 방법이 없습니다"라는 문제를 처리하고 싶지 않습니다. 이" 다시 말함) 그리고 슬프게도 btrfs도 신뢰하지 않습니다. 나쁜 경험으로 인해 모든 저장 장치의 물리적 볼륨을 스캔해야 합니다. /etc/lvm/lvm.conf및 섹션의 지침을 사용하여 스캔을 제한할 수 있습니다. .filterglobal_filterdevices/etc/lvm/lvm.conf
이 중 어느 것도 도움이 되지 않고 데비안이 그림과 같이 중요한 경로에서 시스템을 기다리게 하는 서비스에만 의존한다면 systemd-analyze critical-chain아마도 데비안은 여러분에게 정말 너무 과할 것입니다! (가능합니다: 몇 퍼센트 포인트를 더 줄일 수 있지만, 피할 수 있는 모든 장애물 이후에는 동일한 기능을 가진 시스템이 마술처럼 세 배 더 빠르게 시작되지는 않습니다.)
하지만 시도해 보고 싶다면 자동차 인포테인먼트 시스템에 대한 거의 표준적인 접근 방식은 자신만의 개방형 임베디드 배포판을 만드는 것입니다! OpenEmbedded에는 현재 수행 중인 작업과 크게 다르지 않은 기본 x86 예제가 함께 제공됩니다. 누군가 어딘가에서 키오스크 시스템을 구축하는 방법에 대한 문서를 작성했을 것입니다. ;)
(나는 루트 이외의 buildroot에 대한 경험이 없기 때문에 여전히 그다지 마음에 들지 않습니다.)