私の状況はほぼ同じです。これサーバー障害に公開されました。結論として：
ハッシュマップを使用して大量の大容量ファイルを計算してマージする非常に単純なC ++アプリケーションがあります。std::unordered_map::reserve()メモリを埋めて繰り返しを開始する前に、メモリを予約するためにwithを使用します。約60 Gbのメモリが使用されると（システムには378 Gbがあります）、プロセスは交換を開始し、ハッシュ挿入速度はゼロに低下します。
プログラムの基本的なポイントはここ。
いくつかの注意：
swapoff -a問題を完全に解決してください。- 交換性は1に設定されています
- より良いハッシュマップの実装（例：マティヌス/ロビンフードハッシュ) 問題は解決しません。
- すべてが64ビットにコンパイルされます。 gccの唯一のオプションは次のとおりです。
-std=c++11 -fopenmp -O3 - プログラムはこの段階で1つのスレッドを使用します。
- サーバーの高い I/O 負荷が問題を悪化させるようです。
追加情報
file実行ファイルの出力：
../script/jelly_union: ELF 64-bit LSB shared object, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/l, for GNU/Linux 3.2.0, BuildID[sha1]=65917c99ec9480c1dfb859f10920fce15a8fefc1, not stripped
uname -a:
Linux picea 4.15.0-66-generic #75-Ubuntu SMP Tue Oct 1 05:24:09 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
CPU情報（最後のコア）：
processor : 63
vendor_id : AuthenticAMD
cpu family : 21
model : 1
model name : AMD Opteron(tm) Processor 6282 SE
stepping : 2
microcode : 0x600063e
cpu MHz : 1156.138
cache size : 2048 KB
physical id : 3
siblings : 16
core id : 7
cpu cores : 8
apicid : 143
initial apicid : 111
fpu : yes
fpu_exception : yes
cpuid level : 13
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt pdpe1gb rdtscp lm constant_tsc rep_good nopl nonstop_tsc cpuid extd_apicid amd_dcm aperfmperf pni pclmulqdq monitor ssse3 cx16 sse4_1 sse4_2 popcnt aes xsave avx lahf_lm cmp_legacy svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs xop skinit wdt lwp fma4 nodeid_msr topoext perfctr_core perfctr_nb cpb hw_pstate ssbd ibpb vmmcall arat npt lbrv svm_lock nrip_save tsc_scale vmcb_clean flushbyasid decodeassists pausefilter pfthreshold
bugs : fxsave_leak sysret_ss_attrs null_seg spectre_v1 spectre_v2 spec_store_bypass
bogomips : 5187.19
TLB size : 1536 4K pages
clflush size : 64
cache_alignment : 64
address sizes : 48 bits physical, 48 bits virtual
power management: ts ttp tm 100mhzsteps hwpstate cpb
ベストアンサー1
最新のC ++アプローチが何であるかはわかりませんが、mlock(2)メモリページ交換を無効にする方法を検討することをお勧めします。
すぐにやり直すとどうなるか少し気になります。私はあなたが使用している予約呼び出しが実際にすべてのメモリページに触れないことを願っています（したがって、実際に割り当てられるように強制することはありません）。もしそうなら、しばらくすると、次のようになります。システムは、メモリを交換するのではなく、最初にメモリを要求したことを実際に提供するために苦労しています（常駐サイズを確認してこれを反論できる必要があります）。