Chromium専用Linuxをすばやく起動する

Chromium専用Linuxをすばやく起動する

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」テキストが表示されると、システムが起動します。

https://www.youtube.com/watch?v=2_XqE-hTYcg

ベストアンサー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.conffilterglobal_filterdevices/etc/lvm/lvm.conf

これらのどれも役に立たず、Debianが図のように重要なパスでシステムを待つようにするサービスにのみ依存している場合、systemd-analyze critical-chainおそらくDebianはあなたに本当に過度に過ぎるでしょう! (可能です:数パーセントポイントを減らすことができますが、避けることができるすべての障害物の後に、同じ機能を持つシステムが魔法のように3倍速く起動するわけではありません。)

しかし、試してみたい場合は、自動車インフォテインメントシステムへのほぼ標準的なアプローチは、独自のオープンな組み込みディストリビューションを作成することです! OpenEmbeddedには、現在実行中の作業とは大きく異なる基本的なx86の例が付属しています。誰かがどこかでキオスクシステムを構築する方法についてのドキュメントを書いたでしょう。 ;)

(私はルート以外のbuildrootの経験がないので、まだそれほど気に入らない。)

おすすめ記事