ファイルの圧縮操作を頻繁に行うサーバーがいくつかあります。つまり、すべてのファイルを圧縮してリモートでアップロードするか、リモートでクライアントにストリーミングする前に、まずリモートでダウンロードする必要があります。
古いサーバーをアップグレードするか、新しいサーバーを入手するかを選択できます。
古いサーバーの仕様は約 で3.1 GHz、帯域幅の平均化はです100 Mbps。新しいサーバーの仕様は約 で2.4 GHz、帯域幅は になることが保証されています1000 Mbps up to 2000 Mbps。新しいイテレーションでは、メモリ使用量は同じままか、削減されるはずです。
この時点で、RAM とディスクの使用量はわかりました。これは問題ではありません。問題は、CPU 速度と帯域幅がストリーミング ダウンロードにどのように影響するかということです。
これらが私の選択肢です。
私のユースケースにはどのオプションが適していますか?
答え1
現在のサーバーが「圧縮操作」を実行しているときは、そのサーバーの CPU と帯域幅の使用状況を追跡する必要があります。
CPU を 100% 使用している場合は、より高速な CPU を選択し、帯域幅を 100% 使用している場合は、より高い帯域幅を選択します。
また、公称 GHz 値に関係なく、新しい CPU は古い CPU よりもはるかに高速になる可能性があることに注意してください。CPU コアの数も関係します (「圧縮操作」がマルチスレッド化され、並列で実行されると仮定)。
答え2
「最適な」ソリューションを見つけようとする場合、データ バスを通過できるデータの量を調べる必要があります。最適なのは、データが何らかのネットカードに到着し、CPU から読み取られて、ネットカードのメモリに直接圧縮されることです。
あなたが
- これをサポートするマザーボードを入手できると仮定すると、2 枚の 10 GB イーサネット カード (送信と受信で混乱しないようにするため)、それぞれに PCI Express 4 の 8 レーン (それぞれ 15 GB/秒) が搭載されます。
- これを実際にサポートできるCPU+MBに投資するなら、RyZen 5950X+x570
次にメモリスループットです
- のその上システムは約54GB/秒の読み取り/書き込みまたは48GB/秒のコピーを提供します
- イーサネットドライブは受信したデータをRAMにコピーする可能性がある（キャッシュ経由または非経由）
- おそらくあなたはまだその恩恵を受けていないゼロコピー送信しかしより可能性が高い送信すると 3 ～ 6 個のコピーが作成されます。
- 受信の場合も同じである可能性が高いですが、CPU はそれを少なくとも 1 回は読み取って圧縮する必要があります。運が良ければキャッシュに直接格納され、そうでない場合はメモリから格納されます。また、キャッシュに圧縮される場合も同様に、NIC はそれを内部の送信バッファに直接コピーできます。
最良のケースでは、最高のNIC、ユーザーレベルのドライバー、常にキャッシュをヒットします
- RAMへの書き戻しなしでNICからキャッシュにコピーする
- キャッシュからキャッシュへ圧縮
- キャッシュからNICにコピー
- 32スレッドで処理できると仮定すると、10GB/秒のスループットが得られる。
この幸運なシナリオにアクセスできない場合は、メモリ帯域幅が制限される可能性が高くなります。
- アプリケーションにデータを移動するために3つのコピーを想定した
- 2 つのコピーを zip にロードして結果を保存します
- 3部送付
- そして、多くのキャッシュライトバックがすべてを暗闇に閉じ込める
読み取り 7 回、書き込み 7 回と仮定すると、最良の場合の制限は 54 GB/秒 / 14 = 3.85 GB/秒程度になります。読み取り/書き込みが少ないと、すぐに NIC の最大速度に達します。
したがって、ここから予算やニーズが満たされるまで仕様を削減することができます。
メモリ内のマルチスレッド zip 圧縮に関するデータを見つけることができませんでした。