プロセス生成時間、シェルスクリプト、システムコールのオーバーヘッド

プロセス生成時間、シェルスクリプト、システムコールのオーバーヘッド

Arch LinuxとUbuntu(16.04)でデュアルブートマシンがあります。

最近使い始めました。カクーンテキストエディタそして、私が使用しているOSによって起動時間が大きく異なることがわかりました。しかし、私が考える根本的な問題はいいえカクウネに直接帰属します。

起動時に、kakouneは複数のシェルスクリプトを実行してx11とtmux、git、構文強調/カラースキームなどとの統合を有効にします。この機能は、フラグを使用して「バニラ」エディタのみをロードするように無効にできます-n

コマンド:kak -e qkakouneを起動し、すべての起動スクリプトを実行してすぐに終了します。

アーチ上:
time kak -e q必須1秒
time kak -n -e q(シェルスクリプトなし) 以下完了20ミリメートル

Ubuntu:
time kak -e q約かかります。450ミリメートル
time kak -n -e q再び20ミリメートル

脂肪をトリムしていくつかの起動スクリプトを削除した後、削除された量に比例して両方のオペレーティングシステムで改善が見られました。

いくつかのベンチマークを実行してみました。Unixベンチ2つのシステム間の主な違いは、「プロセス生成」および「シェルスクリプト」テストで見つかりました。

シェルスクリプトテストは、プロセスが一連の変換をデータファイルに適用するシェルスクリプトセット(1、2、4、8の同時コピー)を開始して取得できる1分あたりの数を測定します。

関連出力は次のとおりです。 「1秒あたりのサイクル」単位が多いほど良いです。

Process creation (1 parallel copy of tests)
Arch:    3,822
Ubuntu:  5,297
Process creation (4 parallel copies of tests)
Arch:   18,935
Ubuntu: 30,341

Shell Scripts (1 concurrent) (1 parallel copy of tests)
Arch:      972
Ubuntu:  5,141
Shell Scripts (1 concurrent) (4 parallel copies of tests)
Arch:    7,697
Ubuntu: 24,942

Shell Scripts (8 concurrent) (1 parallel copy of tests)
Arch:      807
Ubuntu:  2,257
Shell Scripts (8 concurrent) (4 parallel copies of tests)
Arch:    1,289
Ubuntu:  3,001

Ubuntuシステムのパフォーマンスがはるかに良くなったことがわかります。

さまざまなログインシェル、ターミナルエミュレータ、kakouneの再コンパイル、ディスククリーンアップに不要なソフトウェアの削除などを使用してテストしました。私はこれがボトルネックであると確信しています。

私の質問は次のとおりですこの問題をさらに調査し、Ubuntuと一致するようにArch Linuxシステムのパフォーマンスを向上させるにはどうすればよいですか?カーネルチューニングを考慮する必要がありますか?

その他の注意:

  • どちらのシステムも同じタイプのファイルシステム(ext4)を使用します。
  • 私はArchlinuxシステムを使用することを好み、時間の経過とともにパフォーマンスの低下を発見しました。
  • Archは/dev/sda1にあり、サイズは約200GBです。 Ubuntuは/ dev / sda2、〜500 GBにあります。 1TBハードドライブ。
  • アーチuname -a:Linux ark 4.14.13-1-ARCH #1 SMP PREEMPT Wed Jan 10 11:14:50 UTC 2018 x86_64 GNU/Linux
  • Ubuntu uname -a:Linux sierra 4.4.0-62-generic #83-Ubuntu SMP Wed Jan 18 14:10:15 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux

ありがとう

答え1

Debian と Ubuntu は dash を/bin/shBash よりも少し速い as として使用します。

$ time for x in {1..1000} ; do /bin/bash -c 'true' ; done                                                                                                                                                                                                                                                      
real    0m1.894s

$ time for x in {1..1000} ; do /bin/sh -c 'true' ; done 
real    0m1.057s

これは図とほぼ同じ領域です(スケール基準)。

DebianとUbuntuで/bin/shBashではなくdashに変更されたのは、主にパフォーマンスのためでした。

基本シェルを切り替える主な理由は効率性です。 bashは、すべての機能を備えた優れたシェルです。しかし、ダッシュに比べてサイズがかなり大きく、起動と実行が遅いです。

https://wiki.ubuntu.com/DashAsBinSh)

答え2

ilkkachuが説明したように、Archはbashを使用し、/bin/shUbuntuはデフォルトでdashを使用します。

これをより詳細に調べて、これが違いを説明していることを確認するには、bashを使用するようにUbuntuシステムを構成し、ベンチマークがArchで得られたものと同様の結果を報告していることを確認できます。これを行うには、次を実行します。

sudo dpkg-reconfigure dash

そして「いいえ」を選択してください。その後、/bin/shポインティングを確認してbashテストを実行できます。

デフォルト値を復元するには、同じコマンドを再実行して[はい]を選択します。

これがパフォーマンスの違いの原因であれば、ArchをUbuntuに合わせて改善するのは難しいでしょう。ダッシュをインストールして使用できますが、bashを想定してダッシュで失敗する多くのスクリプトに遭遇する可能性があります/bin/sh。 Debian と Ubuntu は、すべての問題を特定して修正するのにかなり長い時間がかかりました。

答え3

他の人が同じ問題に遭遇した場合に備えて、私の答えを追加します。

for@ilkkachuの回答でループを実行するときインタラクティブbashシェルzsh または Fish を次のように使用します。私のログインシェル/bin/bashループには約13秒かかります。ルートログインシェルでループを実行または変更する場合私のログインシェルまあ/bin/bash、@ilkkachuの答えに似た結果を得ました。

/bin/bash私はこれがログインシェルから環境を継承する/bin/zshためだと思います/bin/fishが、わかりません。

とにかく変更して問題を解決しました。私のログインシェル/bin/bash端末を実行する/bin/fishか、/bin/zsh対話型シェルに設定します。

関連情報