Prelinkを使用することにもう意味はありますか?


11

何年もの間、さまざまなLinuxボックスを使用して、アプリケーションのロード時間を短縮するためにprelinkを儀式的に使用する習慣になりました。

ただし、prelinkを実行することの利点は、パッケージを再インストールするたびに無効になります。そのため、すべての依存関係と依存関係を再リンクする必要があります。

この事前リンクは複数の問題を引き起こす可能性があり、そのようなものとしてバイナリMD5無効化があります。これは、MD5とアップストリームリビジョンを比較したり、バイナリが変更されたためパッケージ削除時にクリーンアップしたくないかどうかを判断するためにMD5を使用するものに問題があります。

最近、コンピューターの処理速度が大幅に向上し、プリリンクがもたらす利点はほとんど目立ちません。

プレリンクを使用することは依然として合理的な概念ですか、それとも過去の時代の何かとして何気なく捨てて取り残されますか?

回答:


4

LWN.netにサブスクライブしていない限り、2009年7月23日まで読むことができませんが、http://lwn.net/Articles/341244/が役立つ場合があります。


次に、この記事への「購読者リンク」を提供できます。
wazoox 09

5
購読者リンクを使用するのはいつも気分が悪い。私はそれらまたは何かを食い物にしているように。
デビッドパシュリー

2
同意する。興味深い記事に出くわしたときに、直接の連絡先(友人または同僚)へのサブスクライバーリンクを提供しても構いませんが、一般に投稿するのは間違っていると感じています。
クリストファーキャシェル2009

1

勝手に捨てるべきだとは言いませんが、使用についてはもう少し考えるべきだと断言できます。

頻繁に更新される最新のハイエンドマシンでは、prelinkは有効な最適化ではない場合があります。ただし、使用する価値がある場合がまだいくつかあります。たとえば、古いマシンやローエンドマシン、またはかなり静的で頻繁に変更や更新が行われないマシン。繰り返し実行されるプログラムの割合が高い場合にも価値があります(プログラムが高速で連続して実行されるか、または事前リンクによってパフォーマンスが向上する可能性のある並列実行が行われる状況が考えられます)。

全体として、特定の状況を検討し、追加の作業と労力を上回るメリットがあるかどうかを判断する必要があります。


1
「繰り返し実行されるプログラムの割合が高い」-その状況にある場合、バイナリとライブラリはファイルシステムのキャッシュに保存されます。あなたは非常に少ないfsが利用可能なキャッシュされていることを飢えメモリようであれば、一度プレリンクはヘルプがあるでしょう
ダニエルローソン

2
プログラムがファイルシステムキャッシュに保存されている場合でも、事前リンクはプログラムの起動を高速化します。確かに、プログラム(および関連するライブラリ)がキャッシュされると、パフォーマンスの向上はそれほど目立ちません。ただし、実行されているプログラムの速度によっては、数マイクロ秒が加算されて最終的に違いが生じる場合があります。
クリストファーキャシェル2009

1

prelinkは、たとえば学校やネットカフェで使用されるLTSPサーバーなどのマルチユーザーデスクトップサーバーで間違いなく役立つと思います。プレリンクはアプリケーションのロードを高速化するだけでなく、ユーザー間の競合によるRAM使用率とディスクスラッシングを改善し、サーバー上でより多くの同時ユーザーを許可します。


0

メモリの価格が下がると、プリリンクはあまり役に立たなくなってきていると思います。それでも少し速度を上げたい場合は、プリロードを調べることができます。


プリロードを試してみましたが、先読みを行うために両方のコアを噛んで座っている間に起動時間が遅くなったことがわかりました。また、何らかの理由で、起動中にXが死んでしまうこともありません。また、頻繁にリブートしないと、プリロードはまったく役に立ちません。
ケントフレドリック

0

その決定はOSバージョンに任せます。デフォルトでOSがcronを使用してprelinkを定期的に呼び出すことを選択した場合、それ以外の場合はあまり役に立たない可能性があります。デフォルトでprelinkオプションを追加/削除する前に、ディストリビューションの作成者が考えを与えてくれたことを願っています。だから私は物事を自分で分析するのではなく、彼らと一緒に行きます。


ええ、実際にはデフォルトではありません。インストールする必要のあるパッケージです。インストールされていない場合、事前リンクされたものは取得されません。インストールされている場合、cronスクリプトを作成する傾向がありますが、これはデフォルトではオフになっているため、手動で有効にする必要があります。
ケントフレドリック

fedoraのデフォルトはオフではなく、デフォルトです。19にレニケートされますが、オフにはなりません。Fedora 6または7以降同じです。
SaurabhBarjatiya 09

0

Gentooはprelinkを使用します。ハッシュを計算するプリリンク情報を無視することで、md5sumの問題を回避します。

Prelinkは常に速度を向上させますが、ハードウェアの速度が上がるにつれて目立たなくなります。ハードウェアで確実に知る唯一の方法は、プレリンクをオフにして、アプリの起動の遅延をどのように確認するかです。

補足:OS Xは、以前は事前リンクの形式も使用していましたが、リンク自体が保持するリンクキャッシュを優先して廃止されました。両方の長所、バイナリ変更なし、実際のオーバーヘッドと通常のリンクなし。Linuxがいつかこのアイデアを取り入れてくれることを願っています:)

アップデート:私は最近、Linux上でプレリンクしようとした、と多くのファイルやプロセスとのcscopeのコンパイルのために、私は、5%の速度向上を得ました。


1
ので、それは本当に...あなたがインストールして設定する必要があり、その静止何かが、私はこれを言っていない私は Gentooを使用しています。また、プレリンクを正確に「オフ」にすることはできません。プレリンクの実行を停止するか、システム全体のプレリンクを解除してください。また、私には知られていない何らかの理由で、paludisには事前リンクされたバイナリに関する問題があり、元に戻す-事前リンクフック(サポートされていない)がないと、バイナリが残され、問題が発生します。最近、私はフックをインストールする前にあるため、実際の後ろに残っていたいくつかのKDEアプリケーションを発見し、彼らは別の場所に新しいものの前にパスにあった、ワンセグの原因
ケントフレドリック

おそらく、リンカーの最適化(-Wl、-O1)を有効にし、gnuハッシュの割り当ての新しい変更は、OSXが移行したものに似ており、おそらくより効果的な選択です。
ケントフレドリック

gentooを使用してからしばらく経っていることを認めなければなりません...それからOS Xに移行しました:)。私はかつてOS Xで行ったテストを覚えています。すべてのアプリケーションを一度に開始し、その時間(約1分iirc)にします。次に、すべてのプレリンク情報を削除し、すべてのアプリを再起動します。その時間は5分かかった...これは2005年にタワーマック、本当の獣であった。
w00t

1
事前リンクの高速化はあまり目立たないかもしれないというあなたの考えへのカウンターとして:ランタイムのロード可能なライブラリの使用でプログラムが急増するにつれて、それらはより重要になるでしょう。2009年のgvimは55個のランタイムライブラリを使用していました。2年前の1つは73を使用しました。2009年の「マウント」は7を使用し、今日からマウントし、10を使用して4つを/ usr / lib64に、6つを/ lib64に... 。-これまでと同じ-ハードウェアが高速になると、SWはより複雑になり、ブーストを吸収します。
アスタラ

@astara trueですが、ライブラリの使用の増加は、ハードディスクとメモリの速度の増加ほど速くありません。
w00t
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.