HN🔥 321
💬 130

Metaが「jemalloc」への再コミットを表明!メモリ管理の最適化に再び注力

hahahacorn
約21時間前

ディスカッション (11件)

0
hahahacornOP🔥 321
約21時間前

Meta(旧Facebook)が、高性能な汎用メモリアロケータである「jemalloc」の開発に、改めて注力することを発表しました。大規模インフラのメモリ効率を支えるこの重要プロジェクトの今後に注目が集まっています。GitHubリポジトリ:https://github.com/jemalloc/jemalloc

1
bmenrigh
約20時間前

最近、Microsoftのmimallocを(LD_PRELOAD経由で)使い始めて、メモリ消費の激しいプログラムで1GBのヒュージページをうまく活用できるようにしたんだけど、パフォーマンスがかなり上がった(20%くらい)。Linuxシステムでパフォーマンスを出すためにMSのオープンソースライブラリを使ってるのは、なんだか妙な気分だけどね。malloc界隈はもっと競争が必要だよ。色々なサイズのヒュージページやTransparent Huge Pagesがある中で、デフォルトのGNU libcから得られるもの以上に、もっと大きなメリットが得られるはずなんだ。

3
bfgeek
約20時間前

これって世界的なメモリ不足のせいなのかなって勘ぐっちゃうよね。「お、メモリアロケータを効率的なやつに変えれば、来年までに数千万ドルの節約になるぞ」みたいな感じで。

4
RegnisGnaw
約20時間前

これに関する簡潔なタイムラインか経緯ってどこかにある?jemallocは100%オープンソースだと思ってたんだけど、なんでMetaが管理してるの?

5
jjuliano
約19時間前

昔、世界銀行が資金提供してたスタートアップでシニアリードエンジニアをやってた時、本番環境のRubyにjemallocを導入したのを覚えてるよ。速度もメモリ効率も目に見えて良くなったんだ。普通のRubyを使うのと比べて、AWSのコストを大幅に削減できた。8年も前の話なのに、なんで他のプロジェクトでもデファクトとして採用されてないんだろうね。

6
adsharma
約19時間前

「パージ機構の改善を予定している」か...。Facebookにいた頃、jemallocのパージ機構を改善するためにカーネルパッチをいくつかメンテナンスしてたよ。カーネル界隈やセキュリティコミュニティには不評だったけど、ベンチマーク上は確実に効率が上がってた。多くのプログラムはマルチスレッドで動いてて、あるスレッドで確保して別のスレッドで解放したりする。Jemallocの主な仕組みは、madviseでページをカーネルに戻して、それを別のスレッドのプールで再割り当てさせることだったんだ。問題が一つあって、これにはメモリのゼロクリアが伴うから、キャッシュの局所性やアプリ全体のパフォーマンスに影響が出るんだよね。同じセキュリティドメイン内でページを再利用するなら、ゼロクリアは全く不要なんだけど。問題は、たとえオプトイン方式だったとしても、その『セキュリティドメイン』が何かってことに全員の合意を取り付けるのが難しかったことかな。 https://marc.info/?l=linux-kernel&m=132691299630179&w=2 (https://marc.info/?l=linux-kernel&m=132691299630179&w=2)

8
jshorty
約18時間前

世界的なメモリ供給ショックについての言及がないのが意外だな。自分の(まだ比較的若い)キャリアの中で、経済状況がソフトウェアの優先順位をメモリアロケーションの方へと向かわせたのは初めてだから、そのあたりの変化をもっと詳しく知りたいな。

9
apatheticonion
約17時間前

こういう低レイヤのプログラミングを含む仕事をしてて、最近リストラされたオーストラリア人としては...こういう類の挑戦に取り組むのは大好きなんだけどさ。悲しいことに、オーストラリアの求人市場はほとんどがReactのCRUDアプリばっかりで、自分のニッチなスキル(かつ趣味でもあるんだけど)を活かせる仕事は見つかりそうにないんだよね。