Cloudflare spart 100 Terabyte Arbeitsspeicher durch Optimierung des 1.1.1.1-DNS-Caches
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
Cloudflares DNS-Plattform Big Pineapple verwaltet über 250 Milliarden Cache-Einträge. Durch fünf aufeinanderfolgende Optimierungen der Speicherstruktur konnte der Speicherbedarf pro Eintrag um über 50 % gesenkt werden – insgesamt wurden rund 100 Terabyte RAM freigesetzt. Gleichzeitig stieg die Einfüge-Durchsatzrate um 43 % und die Lookup-Latenz sank um 19 %. Die Änderungen umfassen den Ersatz von Vec durch Box<[T]>, das Entfernen redundanter Owner-Namen, das Boxing großer Enum-Varianten und die Speicherung von Records im Wire-Format.
Bei dieser Größenordnung kostet jedes verschwendete Byte pro Eintrag mehr als 250 Gigabyte Speicher in unserer gesamten Flotte.
- lpapez
Das ist der richtige Weg, Software auszuliefern.
Erst ein funktionierendes Produkt erstellen, die Idee validieren, das Geschäft stabilisieren, anfangen, Gewinn zu erzielen, und dann kann man anfangen, die Kosten zu optimieren.
Tatsächlich ist die Optimierung mit Abstand der einfachste Teil des Prozesses, weil es in diesem HN-Thread viele Systemprogrammier-Experten gibt, die diese Optimierungen für trivial halten.
- irdc
Genau deshalb ist Systemprogrammierung immer noch wichtig.
Es scheint, als würden sie die offensichtliche Optimierung übersehen, die Record-Daten direkt nach den CacheEntry-Membern zu platzieren, anstatt den Speicher separat zu allokieren. Aber das könnte nur ich als C-Programmierer sagen und in Rust nicht so einfach sein.
- BikiniPrince
Lustige Sache mit Cloudflare. Ich habe ein DNS-Warming-Skript, das ihre Top-1k- oder Top-10k-Adressen verwendet. Wenn dann mein Master startet, wärmt es den gesamten Cache auf. Alles andere verwendet Memcache, sodass der Cluster schön warm ist. Soweit ich weiß, veröffentlicht sonst niemand Domain-Statistiken wie sie.
- strenholme
Mit meinem eigenen MaraDNS habe ich den Speicherverbrauch von Blacklist-Einträgen aggressiv optimiert, indem ich einen einzigen wirklich großen malloc() verwendet habe, um den Speicher für die Einträge zu allokieren, und dann diesen Speicherblock nach potenziell blockierten Einträgen durchsuche.
Als ich einen malloc() pro Eintrag verwendet habe, belegte eine große Blacklist 237 Megabyte Speicher. Dieselbe Blacklist, optimiert, um mit einem einzigen malloc()-Aufruf geladen zu werden, belegte nur noch 9,5 Megabyte Speicher.
https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...
- vinkelhake
Das scheinen ziemlich Standardansätze zur Reduzierung des Speicherverbrauchs zu sein. Ich kann nicht anders, als zu denken, dass der Ansatz, mehrere verschiedene Listen zu einer zusammenzufassen, in gewisser Weise die Sicherheitsgarantien von Rust untergräbt.
Wenn man vorher drei verschiedene Vec-Objekte hatte, würde Rust garantieren, dass man nicht außerhalb der Grenzen indizieren kann. Wenn man nun alle diese Objekte in einem einzigen Vec ablegt und sich auf Offsets verlässt, öffnet man die Tür für Indizierungen außerhalb des Bereichs dieser Teil-Slices ohne Panics.
Es ist ein nebensächlicher Punkt, und es entwertet die Optimierung nicht wirklich, aber ich bin überrascht, dass der Artikel es nicht erwähnt hat.
- ManBeardPc
Die Record-Struktur enthält rtype und data, wobei RecordData eine getaggte Union ist. Sind diese beiden nicht immer synchron? Ich bin kein DNS-Experte, frage mich nur, ob das redundant ist oder ob es einen Grund gibt, warum beide da sind. Spielt keine Rolle mehr, wenn sie es bereits serialisiert speichern, aber ich wäre interessiert, warum es so war.
- superze
Wie viel ist das in Euro, oder messen wir Geld jetzt in RAM?
- bhouston
Ich habe Probleme mit öffentlichem WLAN, wenn ich den DNS-Server meines MacBooks auf 1.1.1.1 oder 8.8.8.8 überschreibe. Ich glaube, das liegt daran, dass Captive Portals eine benutzerdefinierte Auflösung des Namens captive.apple.com erfordern. Und externe DNS-Server werden diesen Namen nicht korrekt auf die Autorisierungsseite des lokalen Gateways auflösen.