問題タブ [numa]

For questions regarding programming in ECMAScript (JavaScript/JS) and its various dialects/implementations (excluding ActionScript). Note JavaScript is NOT the same as Java! Please include all relevant tags on your question; e.g., [node.js], [jquery], [json], [reactjs], [angular], [ember.js], [vue.js], [typescript], [svelte], etc.

0 投票する
2 に答える
12753 参照

java - NUMA アーキテクチャは ActivePivot のパフォーマンスにどのように影響しますか?

ActivePivot アプリケーションを新しいサーバー (4 ソケットの Intel Xeon、512 GB のメモリ) に移行しています。展開後、アプリケーション ベンチマークを開始しました (これは、リアルタイム トランザクションに同時実行される大規模な OLAP クエリの組み合わせです)。測定されたパフォーマンスは、同様のプロセッサを搭載した以前のサーバーよりもほぼ 2 倍遅くなりましたが、コアは 2 倍少なく、メモリは 2 倍少なくなりました。

2 つのサーバーの違いを調査したところ、大きなサーバーにはNUMA アーキテクチャ(不均一なメモリ アクセス) があるようです。各 CPU ソケットは物理的にメモリの 1/4 に近いですが、残りの部分からは離れています...アプリケーションを実行する JVM は大きなグローバル ヒープを割り当てます。各 NUMA ノードには、そのヒープのランダムな部分があります。私たちの分析によると、メモリ アクセス パターンはかなりランダムであり、CPU コアは頻繁にリモート メモリへのアクセスに時間を浪費しています。

NUMA サーバーでの ActivePivot の活用に関するフィードバックをお待ちしています。ActivePivot キューブまたはスレッド プールを構成したり、クエリを変更したり、オペレーティング システムを構成したりできますか?

0 投票する
5 に答える
1045 参照

parallel-processing - メニーコア CPU: 期待を裏切らないスケーラビリティーを回避するためのプログラミング手法

32 コアの Opteron マシンを購入したばかりですが、得られるスピードアップには少しがっかりしています。約 24 スレッドを超えると、スピードアップがまったく見られず (実際には全体的に遅くなります)、約 6 スレッドを過ぎると、大幅にサブリニアになります。

私たちのアプリケーションは非常にスレッド フレンドリーです。私たちのジョブは約 170,000 の小さなタスクに分割され、それぞれが 5 ~ 10 秒で個別に実行できます。それらはすべて、サイズが約 4Gb の同じメモリ マップト ファイルから読み取ります。ときどき書き込みを行いますが、書き込みごとに 10,000 回の読み取りが必要になる場合があります。170,000 個のタスクのそれぞれの最後に、ほんの少しのデータを書き込むだけです。書き込みはロック保護されています。プロファイリングは、ロックが問題ではないことを示しています。スレッドは、非共有オブジェクトごとに大量の JVM メモリを使用し、共有 JVM オブジェクトへのアクセスはほとんど行わず、書き込みを伴うアクセスはごくわずかです。

NUMA を有効にして、Linux 上の Java でプログラミングしています。128GbのRAMがあります。それぞれ 16 コアの 2 つの Opteron CPU (モデル 6274) があります。各 CPU には 2 つの NUMA ノードがあります。Intel クアッドコア (つまり 8 コア) で実行されている同じジョブは、最大 8 スレッドまでほぼ直線的にスケーリングされました。

ほとんどのルックアップが NUMA ノードに対してローカルになることを期待して、スレッドごとに 1 つになるように読み取り専用データを複製しようとしましたが、これによるスピードアップは見られませんでした。

32 スレッドの場合、「top」は、CPU の 74% が「us」(ユーザー) で、約 23% が「id」(アイドル) であることを示しています。しかし、スリープはなく、ディスク I/O はほとんどありません。24 スレッドの場合、CPU 使用率は 83% になります。「アイドル」状態を解釈する方法がわかりません。これは「メモリ コントローラーを待機中」という意味ですか?

NUMA のオンとオフを切り替えてみましたが (リブートが必要な Linux レベルの設定について言及しています)、違いは見られませんでした。NUMA が有効になっている場合、「numastat」は「割り当てとアクセスのミス」の約 5% のみを示しました (キャッシュ ミスの 95% は NUMA ノードに対してローカルでした)。[編集:] しかし、"-XX:+useNUMA" を Java コマンドライン フラグとして追加すると、10% のブーストが得られました。

私たちが持っている 1 つの理論は、アプリケーションが大量の RAM を使用し、多くのキャッシュ ミスがあると考えているため、メモリ コントローラーを使い果たしているというものです。

(a) プログラムを高速化して線形スケーラビリティに近づけるか、(b) 何が起こっているかを診断するにはどうすればよいでしょうか?

また: (c) 「トップ」の結果をどのように解釈すればよいですか? 「アイドル」は「メモリ コントローラーでブロックされている」という意味ですか? (d) Opteron と Xeon の特性に違いはありますか?

0 投票する
0 に答える
715 参照

cpu - 異なる NUMA ノードでのパフォーマンス ツールの結果の解釈

perf ツールを使用して、プログラムの興味深い動作を説明したいと思います。

いくつかの背景情報

私のマシンには 4 つの NUMA ノードがあり、メイン アプリケーションはマシン上で実行されています。cpusets を使用してマシンを分割し、アプリケーションに 3 つのノード、システムに 1 つのノードを割り当てています。同じマシンで単体テスト (ログの改善のため) を実行しているときに、perf ツールを使用して調査しようとしている予期しない動作が発生します。

予期しない動作は、アプリケーションが実行されている NUMA ノード (ノード 2 としましょう) で、単体テストでより良い時間を取得することです。ノード 3)。node2のCPU(スピンロックを行わないCPU)で実行しているように見えますが、別のnumaで実行するよりも良い結果が得られます。

ログシステムを改善しようとしているので、テストはアプリケーションによっても行われる作業を行っており、後でディスクにダンプするためにいくつかのログメッセージをキューに書き込みます (別のスレッド)。キューへの競合は、スピンロック (CAS) によって制御されます。unitest は、2 つのループを持つ 1 つのライター スレッドです。100 回、1000 個のログがキューに書き込まれ、RDTSC (私の選択) を使用して各内部ループが測定され、統計が出力されます。キューは十分に大きく、標準偏差を取得し、メモリ操作は最小限に抑えられます (memcpy なし)。リーダーは別のスレッドでディスクにダンプしています。

アプリケーションを停止して、もう一度テストを実行してみました。この場合、テストを実行するために選択した NUMA ノードに関係なく、node3(slow) で実行した場合と同様の結果が得られます。つまり、同じ numa でテストを実行すると、実行中のアプリケーションがテストを高速化しています。アプリケーションが実行されるノード。私にとって非常に直感的ではありません。

次の perf ツール コマンドを使用してデータを取得する

コマンドを使用して分析する

私はいくつかの違いを含むものを抽出しました。 sched-、LLC-、branch-、TLB を疑うべきかどうかはわかりません。相対的な違いが私が見ている動作を説明するかどうかの手がかりがないからです。

これを調査するためのより良い方法の提案はありますか?

0 投票する
0 に答える
1314 参照

c - mbind を使用して NUMA システムでページを移動する

numa(3)Linuxのライブラリについて頭を悩ませようとしています。

大きな配列が割り当てられています (何 GB ものメモリ)。ランダム NUMA ノードで実行されているスレッドは、ランダム NUMA メモリ ノード (デフォルトの NUMA ポリシー) でそのようなページに障害が発生するため、それに書き込みます。

スレッド計算の最後に、結果を合計するシングルスレッド ジョブがあります。そのために、最初に配列を圧縮して多くの要素を削除し、残りをマスター スレッドの NUMA ノードに移動します。

システムコールは、move_pagesページごとに配列エントリを必要とするため、ジョブに適していません-オーバーヘッドが多すぎます。

numa_tonode_memoryドキュメントは、障害のあるメモリを強制的に移動できるかどうか不明です。

したがって、私が見る唯一の方法はmbindwithを使用することですがMPOL_MF_MOVE、適切な引数を作成することに頭を悩ませることはできませnodemaskん (または他の何かが失敗しています)。これが私が得た限りです:

から/usr/include/numa.h:

を取得することもあればmbind: Bad address、呼び出しが成功することもありますが、その後のメモリ アクセスではSIGSEGV.

addrによって返される常に有効なポインターです。

およびlenページ揃えです。

できるだけ少ないシステムコールで、大きなオーバーヘッドなしでこれを機能させるにはどうすればよいmove_pagesですか?

nodemaskそして、引数を設定する適切な方法は何mbindですか?

0 投票する
2 に答える
1982 参照

c++ - NUMA アーキテクチャでの大容量 (8MB) メモリ領域のスケーラブルな割り当て

現在、TBB フロー グラフを使用しています。このグラフでは、a) 並列フィルターが配列を (オフセットと並行して) 処理し、処理された結果を中間ベクトル (ヒープに割り当てられます。ほとんどの場合、ベクトルは 8MB まで増加します) に入れます。次に、これらのベクトルはノードに渡され、ノードはその特性 (a) で決定) に基づいてこれらの結果を後処理します。リソースが同期されているため、各特性に対してこのようなノードは 1 つしか存在できません。私たちが作成したプロトタイプは、UMA アーキテクチャ (単一 CPU の Ivy Bridge および Sandy Bridge アーキテクチャでテスト済み) でうまく動作します。ただし、アプリケーションは NUMA アーキテクチャ (4 CPU Nehalem-EX) ではスケーリングしません。問題をメモリ割り当てに突き止め、ヒープからメモリを割り当てるだけの並列パイプラインを持つ最小限の例を作成しました (8MB チャンクの malloc を介して、次に、8MB 領域を memset します。最初のプロトタイプが行うことと同様) メモリの特定の量まで。私たちの調査結果は次のとおりです。

  • UMA アーキテクチャでは、アプリケーションは、パイプラインで使用されるスレッドの数 (task_scheduler_init で設定) に比例してスケールアップします。

  • NUMA アーキテクチャでは、(numactl を使用して) アプリケーションを 1 つのソケットに固定すると、同じ線形スケールアップが見られます。

  • 複数のソケットを使用する NUMA アーキテクチャーでは、アプリケーションの実行時間はソケットの数に応じて増加します (負の線形スケール - 「アップ」)。

私たちにとって、これはヒープの競合のようなにおいがします。これまでに試したことは、glibc アロケーターを Intel の TBB スケーラブル アロケーターに置き換えることです。ただし、単一ソケットでの初期パフォーマンスは glibc を使用するよりも悪く、複数ソケットでのパフォーマンスは悪化していませんが、改善もされていません。 tcmalloc、買いだめアロケータ、および TBB のキャッシュ アライメント アロケータを使用して同じ効果を得ました。

問題は、誰かが同様の問題を経験したかどうかです。パイプラインが実行された後でもヒープに割り当てられたベクトルを保持したいので、スタック割り当てはオプションではありません。複数のスレッドから NUMA アーキテクチャで、1 つのヒープに MB 単位のサイズのメモリ領域を効率的に割り当てるにはどうすればよいですか? メモリを事前に割り当ててアプリケーション内で管理するのではなく、動的割り当てアプローチを維持したいと考えています。

numactl を使用したさまざまな実行のパフォーマンス統計を添付しました。Interleaving/localalloc はまったく効果がありません (QPI バスはボトルネックではありません。PCM を使用した場合、QPI リンクの負荷が 1% であることを確認しました)。また、glibc、tbbmalloc、および tcmalloc の結果を示すグラフも追加しました。

perf stat bin/prototype 598.867

「bin/prototype」のパフォーマンス カウンター統計:

perf stat numactl --cpunodebind=0 ビン/プロトタイプ 272.614

「numactl --cpunodebind=0 bin/prototype」のパフォーマンス カウンター統計:

perf stat numactl --cpunodebind=0-1 ビン/プロトタイプ 356.726

「numactl --cpunodebind=0-1 bin/prototype」のパフォーマンス カウンター統計:

perf stat numactl --cpunodebind=0-2 ビン/プロトタイプ 472.794

「numactl --cpunodebind=0-2 bin/prototype」のパフォーマンス カウンター統計:

最小限の例: g++-4.7 std=c++11 -O3 -march=native; でコンパイル。numactl --cpunodebind=0 ... numactl --cpunodebind=0-3 で実行 - CPU バインドでは、次の結果が得られます: 1 CPU (速度 x)、2 CPU (速度 ~ x/2)、3 CPU (速度~ x/3) [速度=高いほど良い]. したがって、CPU の数が増えるとパフォーマンスが低下することがわかります。メモリ バインディング、インターリーブ (--interleave=all)、および --localalloc は、ここでは効果がありません (すべての QPI リンクを監視し、リンク負荷は各リンクで 1% 未満でした)。

Intel TBB フォーラムでのディスカッション: http://software.intel.com/en-us/forums/topic/346334

0 投票する
1 に答える
3038 参照

linux - qemu-kvm numa トポロジの公開の問題

次のシナリオを達成しようとしています。

それぞれに 6 つの CPU を持つ 4 つの numa ノードを備えた Linux ボックスがあります。kvm ゲストのパフォーマンスを向上させるために、各 vcpu を一連の CPU に、できれば同じ Numa セルに固定します。

たとえば、12 コアのゲストを開始する場合、最初の 6 個の vcpus を NUMA ノード 1 の cpuset に固定し、2 番目の 6 個を NUMA ノード 2 の cpuset に固定します。

これまでのところ、そのトポロジをゲストに公開しようとすると、問題が発生し始めます。つまり、2 つの NUMA ノードに 2 つの cpuset があることをゲストに認識させます。

qemu-kvmのオプションを使用する-smp 12,sockets=2,cores=6,threads=1と、最初の 6 つを 1 つのソケットに、2 つ目の 6 つを別のソケットにグループ化し、-numaオプションを使用して適切な vcpus に 2 つの numa ノードを設定することで、それらを半分に分割する可能性が高いと思います。だから私の質問は次のとおりです:

  1. -numaオプションはその役目を果たしますか?ドキュメントでは、numa シミュレーション用であると言われています。そのシミュレーションなら、それはパフォーマンスを損なうことを意味しませんか? 私が必要としているのは、ゲストに「これらの CPU は同じ NUMA ノード上にあります」と言う方法です (そうでない場合でも)。これはそれを達成する方法ですか?

  2. qemu (1.2.0) にバグがあり、トポロジーがひどく公開されているようです。CPU トポロジを (たとえば) に設定すると-smp 9,sockets=3,cores=3,threads=1、何らかの奇妙な理由で、ゲスト内で ( lstopo を使用して) 3 つのソケットに配置されていることがわかりますが、最初のソケットに 4 コア、2 番目のコアに 4 コア、3 番目のコアに 1 コアが配置されています。 ( 4|4|1 )。私は、それらを均等ではなく、2のべき乗に分割すると考えました。sockets=2,cores=10;でも同じ動作を観察しました。sockets=2,cores=18、名前を付けると、常に半分ではなく、2 のべき乗 (つまり 8|2 と 16|2 ) で分割されます。sockets=2,cores=8ただし、正常に動作します(これは一種の予想です)。誰かがそのようなことを経験したことがありますか?

0 投票する
0 に答える
718 参照

c - libnuma - データ型の問題

強化された NUMA 対応アロケータに libnuma を使用しています。「numa man-page」または libnuma API で説明されているように機能しない関数がいくつかあります。正確には、次の関数に問題があります:numa_get_run_node_mask()numa_node_to_cpus().
前者に関しては、API とマニュアルを読むとstruct bitmask *、コンパイラが を要求する一方で、 を返すと書かれていますnodemask_t
後者は API 定義から 2 つのパラメーターを必要とするはずですが、コンパイラーは 3 つを要求します。3 つの引数を渡すと (ソース コード定義で見つけた次の宣言に従います)、使用numa_node_to_cpus_v1(int node, unsigned long *buffer, int bufferlen)するbufferlenに関係なく、毎回segfaultが発生します。

言及するだけで、後者の関数は、コマンドを入力するときnuma_node_to_cpus()と同じ用途です。ノード内のすべての cpu を取得するために使用されます。ソースコードを読んだところ、2 つの引数で正しく動作しました。numactlnumactl --hardwareint node, struct bitmask *mask

おそらく、修正が必要なバグや、libnuma のバージョンによって変更された API とソースの間に不一致がある可能性があります。(ところで、どの libnuma/numactl がマシンで実行されているかを確認するにはどうすればよいですか? サーバー上でリモートで作業していて、オプションnumactlがないようです!)--version

0 投票する
1 に答える
1391 参照

c - numa、mbind、segfault

vallocを使用してメモリを割り当てました。たとえば、[15 * sizeof(double)]の配列Aとします。ここで、これを3つの部分に分割し、各部分(長さ5)を3つのNUMAノード(たとえば、0、1、および2)にバインドします。現在、私は次のことを行っています。

最初の質問は、私はそれを正しくやっているかということです。たとえば、ページサイズに適切に配置することに問題はありますか?現在、配列Aのサイズは15ですが、正常に実行されますが、配列サイズを6156000およびpiece = 2052000のようなものにリセットすると、その後、mbindへの3回の呼び出しは、&A [0]、&A [2052000]、および&A[4104000]で始まります。 ]その後、セグメンテーション違反が発生します(そして時々それがただそこにぶら下がっています)。なぜ小さいサイズでも問題なく動作するのに、大きいサイズではセグメンテーション違反が発生するのですか?ありがとう。

0 投票する
1 に答える
618 参照

c - mbind は EINVAL を返します

次の質問numa+mbind+segfaultに提供されているコードを使用しています。mbind を呼び出すたびに EINVAL が返されます。正確に何が間違っているのかをどうやって知ることができますか? EINVAL は多くの理由で返される可能性があるため、私はこれを求めています。

プログラムを実行した後 (各 mbind 呼び出しの前に nodemask をそれぞれ 1、2、および 4 に変更することにより) 以下に示します (Mats Petersson からの回答として)。セグメンテーション違反になることもあれば、正常に実行されることもあります。セグメンテーション違反時の dmesg は次のとおりです。

0 投票する
1 に答える
3343 参照

c - numactl --membind

--membind オプションを指定して Linux で numactl を使用する場合、次のようにします。

./prog のメモリは、NUMA ノード 0、1、および 2 のすべてに割り当てられますか? それとも、NUMA ノード 0 のメモリが十分でない場合、メモリは NUMA ノード 1 と 2 にのみ割り当てられますか? ありがとう。