Cloudflare、1.1.1.1のDNSキャッシュ最適化で100テラバイトのメモリを節約
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
CloudflareのDNSプラットフォーム「Big Pineapple」は、常時2500億件以上のDNSキャッシュエントリを保持しており、1エントリあたり1バイトの無駄が全体で250ギガバイト以上のメモリ消費につながります。キャッシュエントリのメモリ内表現を5回にわたって改良し、1エントリあたりのフットプリントを50%以上削減。その結果、フリート全体で約100テラバイトのメモリを解放し、さらに挿入スループットが43%向上、ルックアップレイテンシが19%低下しました。具体的な最適化として、VecからBox<[T]>への変更、セクションオフセットの導入、レコード所有者の省略、大きなenumバリアントのボックス化、そしてレコードデータのワイヤフォーマット保存などが挙げられます。
キャッシュエントリごとに1バイトの無駄が、フリート全体で250ギガバイト以上のメモリを消費します。
HNでの議論
273- lpapez
これはソフトウェアを届ける正しい方法だ。
まず動作する製品を作り、アイデアを検証し、ビジネスを安定させ、利益を出し始めてから、コストの最適化を始められる。
実際、最適化はプロセスの中で最も簡単な部分だ。なぜなら、このHNスレッドには、これらの最適化を些細なものとみなすシステムプログラミングの専門家がたくさんいるからだ。
- irdc
これこそ、システムプログラミングが今も重要である理由だ。
彼らは、レコードデータをCacheEntryメンバーの直後に置き、メモリを別途割り当てるのをやめるという明白な最適化を見逃しているように見える。しかし、それは私がCプログラマーとして言っているだけで、Rustではそれほど簡単ではないかもしれない。
- BikiniPrince
Cloudflareについて面白いことがある。私は彼らのトップ1000または10000のアドレスを使うDNSウォーミングスクリプトを持っている。そして、マスターが起動するとキャッシュ全体をウォームアップする。他のすべてはmemcacheを使うので、クラスタは暖かくて居心地が良い。私の知る限り、彼らのようにドメイン統計を公開している人は他にいない。
- strenholme
私のMaraDNSでは、ブラックリストエントリのメモリ使用量を積極的に最適化した。エントリ用のメモリを割り当てるために単一の巨大なmalloc()を使い、そのメモリブロックを走査して潜在的にブラックリストに載っているエントリを探すようにした。
エントリごとに1つのmalloc()を使っていたときは、大きなブラックリストで237メガバイトのメモリを消費していた。同じブラックリストも、単一のmalloc()呼び出しでロードするように最適化すると、わずか9.5メガバイトしか消費しなかった。
https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...
- vinkelhake
これらはメモリ使用量を減らすためのかなり標準的なアプローチのように思える。複数の異なるリストを1つに結合するアプローチは、Rustの安全性保証をある意味で損なうと感じずにはいられない。
以前は3つの別々のVecオブジェクトがあったなら、Rustは範囲外インデックスを防ぐことを保証していた。しかし、それらすべてを1つのVecに入れ、オフセットに依存するようになると、これらのサブスライスの範囲外インデックスがパニックなしで発生する可能性が生じる。
これは些細な点であり、最適化を無効にするものではないが、記事がそれに触れなかったのは驚きだ。
- ManBeardPc
Record構造体にはrtypeとdataが含まれており、RecordDataはタグ付きユニオンです。これら2つは常に同期しているのではないですか？DNSの専門家ではないので、これが冗長なのか、それとも両方がある理由があるのか疑問に思っています。すでにシリアライズして保存するなら関係ありませんが、なぜこのようになっていたのか興味があります。
- superze
これはユーロでいくらですか、それとも今はRAMでお金を測るのですか？
- bhouston
MacBookのDNSサーバーを1.1.1.1や8.8.8.8に上書きすると、公共のWi-Fiで問題が発生したことがある。これは、キャプティブポータルがcaptive.apple.comという名前のカスタム解決を必要とするためだと思う。外部DNSサーバーは、その名前をローカルゲートウェイの認証ページに正しく解決しないだろう。