システムで選択されたタイムソースのパフォーマンスへの影響の分析

DTrace 開発者の 2 人である Brendan Gregg 氏は、現在 Linux カーネルで BPF ベースのパフォーマンス分析ツールを開発しており、Netflix が Cassandra DBMS を CentOS から Ubuntu に移行するときに遭遇したパフォーマンス問題の分析から得た経験を要約しました。 Xen ベースの Amazon EC30 クラウド。移行後、CPU 負荷は XNUMX% 増加し、書き込み操作中の遅延もほぼ同じ量増加しました。結局のところ、時間情報を集中的に要求するアプリケーションのパフォーマンスは、システムで選択されている正確な時間ソースに大きく依存します。

当初、パフォーマンス低下の理由は明らかでなく、診断は、top ユーティリティと execsnoop ユーティリティを使用して、リソースを大量に消費するシステム プロセスが常に実行されている、または定期的に起動されている可能性がある影響を監視することから始まりました。しかし、特に Java で書かれた Cassandra DBMS でリソース消費が増加していることをすべて示していました。 CentOS と Ubuntu 上で並行して実行され、同じクエリを処理する 32 つの Cassandra プロセスのプロファイリング メトリクスを比較すると、合計時間の約 XNUMX% が、現在時刻に関する情報を取得するために使用される os::javaTimeMillis() の呼び出しに費やされていることがわかりました。 。

この後、System.currentTimeMillis() メソッドをループで 13 億回呼び出す単純な Java アプリケーションを作成する実験が行われました。アプリケーションを実行すると、CentOS では完了までに 68 秒、Ubuntu では約 5 秒かかったことがわかりました。 XNUMX倍遅くなります。 gettimeofday() 関数を XNUMX 億回呼び出す同様のプログラムが C で作成されましたが、実行すると同様の結果が得られました。

問題の原因が現在時刻を返す機能にあることが明らかになったので、システム内で正確な時刻のさまざまなソースを選択するときのインジケーターの変化に注意が向けられました。 「/sys/devices/system/クロックソース/クロックソース0/current_locksource」の内容から判断すると、ゲスト システムで Linux を実行する場合、デフォルトで「xen」タイマーが使用されていました。タイムソースを「tsc」に変更した後、Ubuntu でのテスト アプリケーションの実行時間は 68 秒から 3.3 秒に減少しました。 20倍速くなりました。さらに、kvm-lock タイム ソースのパフォーマンス テストが実行され、TSC と比較して遅延が 20% 増加したことがわかりました。 $ cat /sys/devices/system/クロックソース/クロックソース0/available_locksource xen tsc hpet acpi_pm $ cat /sys/devices/system/クロックソース/クロックソース0/current_locksource xen $ time java TimeBench real 1m8.300s user 0m38.337s sys 0m29.875s $ echo tsc > /sys/devices/system/クロックソース/クロックソース0/current_locksource $ time java TimeBench real 0m3.370s user 0m3.353s sys 0m0.026s

TSC ソースを選択するときに時刻を取得するには、RDTSC プロセッサ命令が使用されます。この命令の実行にはシステム コールは必要ありません (この命令は昇格された特権を必要とせず、CPU に組み込まれている時刻カウンタから値を生成します)。デフォルトでは、TSC はアクティブになっていません。これは、以前はこのソースが徐々に時間のドリフトを除外していなかったためです。他のプロセッサでは、より正確な読み取り値を達成するためにソフトウェアによって調整されています。プロセッサ開発を専門とするエンジニアによると、TSC 使用時のタイムシフトに関する懸念は長い間真実ではなく、最新のプロセッサでは、このソースは何年にもわたって安定した読み取り値を生成できます。

Netflix の実稼働サーバーを TSC ソースに切り替えると、書き込み遅延が 43% 削減され、Ubuntu を使用した場合、「xen」タイム ソースで CentOS を実行する構成よりも 4 倍高速な結果が得られました。研究結果は Amazon に転送され、Amazon は、Xen ハイパーバイザーに基づく AWS EC2 環境でデフォルトの TSC タイムソースを使用することを正式に推奨しました (Nitro ハイパーバイザーに基づく環境では、kvm-lock が引き続き推奨されます)。

出所: オープンネット.ru

コメントを追加します