背景
数日前に同志pavlinuxの記事を読んだ後、 昨夜 、先読みを発見し、蛇口をひねり、冗長なキャッシング（このプログラムのイデオロギーの観点から）を取得し、それによってプロファイルへのリアクティブなロードとログインを行ったため、非常に興味をそそられました。 Intel Atomベースの控えめなタイプライターからもう少し絞ってみませんか？
私の仕事では、sshとtelnetに加えて、Webブラウザーを使用することが多いので、シラミをチェックするように手配します。 「どのブラウザが最適か」を巡る聖戦を忘れましょう。今日、Google Chrome 29.0.1547.62（r219432）はナイフに包まれています。
準備する
あなたの謙虚な使用人はレベル1のスクリプトライターなので、小さなヘルパースクリプトにはbashを使用します。
trace_google_chrome
私は頭に灰を振りかけ、悔い改めましたが、これは同様のタスクのスクリプトの最良の例ではありません。
#!/bin/bash ENV_EXCLUDE=('^SUDO_' '^GREP_' '^LS_' '^KONSOLE_' '^_$') ENV_PERSIST=('^PATH$' '^LOGNAME$' '^USER' '^HOME$') sudo true || return 1 T0=$(mktemp) sudo -E env | cut -d'=' -f1 | tee ${T0} &>/dev/null T1=$(mktemp) for i in ${ENV_EXCLUDE[@]}; do egrep -e "$i" < ${T0} >> ${T1}; done T2=$(mktemp) for i in ${ENV_PERSIST[@]}; do egrep -e "$i" < ${T0} >> ${T2}; done rm ${T0} STRACE_ARGS='' while read L; do STRACE_ARGS=${STRACE_ARGS}" -E $L" done < ${T1}; rm ${T1} while read L; do declare -p $L &>/dev/null || continue V=$(env | egrep -e ^$L) STRACE_ARGS=${STRACE_ARGS}" -E $V" done < ${T2}; rm ${T2} U=$(whoami) date --rfc-3339=ns >d.begin sudo -E strace -ff -o zzz -v -s 256 -T \ -u ${U} -E USERNAME=${U} ${STRACE_ARGS} \ -e trace=file,signal,ipc google-chrome date --rfc-3339=ns >d.end
コメントにあなたのコメントを喜んでいます。
また、事前にテスト用のSpartan条件を作成します。ブラウザーキャッシュとシステムキャッシュ（ pagecache 、 dentries 、およびiノード ）をクリアします。
$ find .cache/google-chrome/ -mindepth 1 -delete $ sync $ sudo sysctl -w vm.drop_caches=3 vm.drop_caches = 3
テスト中
ブラウザを起動し、コンテンツでオーバーロードされたさまざまなサイトから多くのタブを開きます。 あなたは常にこれを行うことを知っています。つまり、状況は非常に規則的です。
$ trace_google_chrome Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. [19883:19883:0904/013557:ERROR:profile_sync_service.cc(1240)] History Delete Directives, Sync Error: Delete directives not supported with encryption. Fontconfig warning: "/etc/fonts/conf.d/50-user.conf", line 9: reading configurations from ~/.fonts.conf is deprecated. [19883:19909:0904/013606:ERROR:native_backend_kwallet_x.cc(848)] Error obtaining KWallet handle ATTENTION: default value of option force_s3tc_enable overridden by environment. [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED [WARNING:flash/platform/pepper/pep_module.cpp(63)] SANDBOXED ATTENTION: default value of option force_s3tc_enable overridden by environment. ATTENTION: default value of option force_s3tc_enable overridden by environment.
一部の人にとっては通常の写真ですが、私にとってはストレスです。
しばらくサーフィンをした後（私の場合は1時間強でした-もう我慢できませんでした）、ブラウザーを閉じて出力の解析を開始します。
$ egrep -He^ d.* d.begin:2013-09-04 01:35:39.040184387+04:00 d.end:2013-09-04 02:57:34.084098826+04:00 $ du -ch zzz.* | tail -n 1 34M
すべてのトレースファイルを1つにまとめて並べ替えます。
$ cat zzz.* > z $ sort < z > z.sorted $ wc -l < z.sorted 243048
呼び出しに関係のない出力行から削除します（「+++ exited with 0 +++」など）：
$ egrep -ve '^\+' < z.sorted > z.clean $ wc -l < z.clean 242474
呼び出しが失敗したとき、ファイルからこれらの行のみを選択します （ pavlinuxヒントのおかげです）：
$ fgrep -e ' = -' < z.clean > z.fail $ wc -l < z.fail 39810
失敗したコールの割合は16.418％です。
たくさん、しかしもっと深く見て、失敗の統計を見つけましょう：
$ cut -d'(' -f1 < z.fail | uniq > z.fail.names $ cat z.fail.names | > while read SYSCALL; do > echo -n "${SYSCALL}:" > egrep -ce "^${SYSCALL}\(" z.fail > done access:16807 chmod:2 execve:56 faccessat:6 fstatat64:46 lstat64:91 mkdir:8 openat:155 open:7812 readlinkat:4909 readlink:86 rt_sigaction:59 rt_sigreturn:8 shmctl:1 sigreturn:47 stat64:9658 statfs64:39 unlink:20
失敗したopenとstat64に加えて、 accessとreadlinkatもあります 。
もちろんこれはすべて興味深いものであり、より詳細な分析に値します。
しかし、これらの非常に失敗した呼び出しに費やされた時間を調べる時間です。
ファイルから呼び出し実行時間の特定の値を選択します。
$ sed -nre '/^.* <([0-9\.]+)>$/{s##\1#;p}' < z.fail > z.fail.timing
ここでのタスクは、約4万の値の合計を取得することです。 私は面倒で、 ここから完成したコードを取りました ：
#include <stdio.h> #include <stdlib.h> int main(void) { ssize_t read; char *line = NULL; size_t len = 0; double sum = 0.0; while (read = getline(&line, &len, stdin) != -1) { sum += atof(line); } printf("%f\n", sum); return 0; }
このコードを実行します：
$ gcc sum.c -o sum; ./sum < z.fail.timing 4.173705
結果は少し予測可能です。GoogleChromeシステムコールの失敗と、彼が起動したすべてのプロセスに4秒かかりました。
実際のリードタイムは1時間11分55秒、つまり4315秒です。
「失われた」時間の割合：4/4315 =〜0.093％。 わずか1％でも、わずかに伸びた1ppmです。
結論
誰もが自分で決めましょう。 一方で、この種のシラミによく使用するアプリケーション/システムをチェックし、ボトルネックがどこにあるのか、そしてそれらをどのように処理するのかを見つけることは決して不要ではありません。 一方、すべてのアクションには対策が必要であり、ライブラリ/ファイルの場所の偏執狂的な最適化により、アプリケーションの起動が一瞬だけで、場合によっては動作もスピードアップしますが、これはほんの一瞬です。 それらは蓄積されるので、クレイジーなアップタイムで動作するシステムで役立ちますが、その値は比較的短時間実行されるアプリケーションでは消えます。 結局、それはすべてあなたが設定したタスクとあなたがあなた自身の時間をどれだけ大切にしているかに依存します。
ある程度まで、私も時間を大切にしません。この論争の的となっている問題の研究に時間を費やし、「飛行機の飛行を妨げる必要はない」という事実に関する記事を書きました。
あとがき
この記事は、仲間のpavlinuxや彼の記事に屈辱を与えるのではなく、無視されたニュアンスを指摘することを目的としています。 さらに、最初の記事がなければ、毎晩調査を
PS：これらの非常に4.17秒はとらえどころのないジョーです。