glibcの最新バージョン（2.12ベース）では、MALLOC_ARENA_MAXとMALLOC_PER_THREADを調整できます。
質問：
MALLOC_PER_THREAD = 0とMALLOC_ARENA_MAX = 1の間に違いはありますか？最新のglibcはまだMALLOC_PER_THREADをサポートしていますか？
Arenasは仮想メモリ使用量を増やします。 32ビットカーネルに適していますか？
シングルコアCPU（仮想ゲスト）でも動作しますか？
メモリチェックを有効にすると
MALLOC_CHECK_=3
glibcはデフォルトのデバッグアロケータまたはデフォルトのアロケータを使用しますか？
昔、私はglibcについて読んで、一種のデバッグを使用して通常のアロケータの代わりにデフォルトのアロケータを使用しましたが、...ドキュメントが見つかりませんでした。
答え1
私が理解しているように、
MALLOC_PER_THREADこれはRHELに新しいスレッド固有のアロケータを有効にするために提供される一時的な構成ノブです（参照：対応するCentOSリリースノート詳細はこちら）。現在のバージョンでは使用できなくなり、glibc新しいアロケータは2.15でデフォルトのアロケータになりました（私の意見では）。設定はMALLOC_ARENA_MAX=1同様の効果がありますが、この場合、「新しい」アロケータの他の部分がまだアクティブであるため、厳密に同じではない可能性がある1つのスタジアムしか存在できないことを意味します。はい、32ビットカーネルで動作しますが、デフォルトの調整は異なります（
M_ARENA_TEST32ビットシステムでは2、他のシステムでは8）。シングルコアシステムで複数のアリーナを使用することはあまり意味がないかもしれませんが、基本的なチューニングではこれを考慮する必要があります（アリーナのハード制限は通常使用可能なCPUの数の倍数です）。
M_CHECK_ACTION=3これが既定値なので、メモリチェックを有効にすると、デフォルトのアロケータが使用されます。
これに関するユーザーレベルの文書は、次の場所にあります。男の言葉。
glibc 2.26新しいスレッド固有のキャッシュが必要です。、隠れ家しかし、展開を可能にするには明らかに時間がかかります。 （発売予定日は今年8月1日です。）