Cloudflare libera 100 terabytes de memoria optimizando la caché DNS de 1.1.1.1
Saving 100 terabytes of memory by optimizing 1.1.1.1's DNS cache
Cloudflare ha logrado reducir en más de un 50% el espacio que cada entrada de la caché DNS de su plataforma Big Pineapple ocupa en memoria, liberando unos 100 terabytes en total. Mediante cinco cambios en la representación de los datos, como usar Box en lugar de Vec, empaquetar secciones en una sola lista o almacenar los registros en formato de cable, la empresa no solo ahorra memoria, sino que también mejora el rendimiento: el rendimiento de inserción aumenta un 43% y la latencia de búsqueda disminuye un 19%. El artículo detalla cada optimización y sus implicaciones.
A esa escala, desperdiciar un solo byte por entrada cuesta más de 250 gigabytes de memoria en nuestra flota.
- lpapez
Esta es la forma correcta de entregar software.
Primero produce un producto funcional, valida la idea, estabiliza el negocio, empieza a generar ganancias, y luego puedes empezar a optimizar tus costos.
De hecho, la optimización es, con diferencia, la parte más fácil del proceso porque hay muchos expertos en programación de sistemas en este hilo de HN que consideran que estas optimizaciones son triviales.
- irdc
Por esto la programación de sistemas sigue importando.
Parece que se les escapa la optimización obvia de poner los datos del registro justo después de los miembros de CacheEntry en lugar de asignar memoria por separado. Pero quizás eso es solo el programador en C que hay en mí hablando y no sea tan fácil en Rust.
- BikiniPrince
Algo gracioso sobre Cloudflare. Tengo un script de calentamiento de DNS que usa sus direcciones top 1k o 10k. Luego, cuando mi maestro arranca, calienta toda la caché. Todo lo demás usa memcache, así que el clúster queda bien calentito. Hasta donde sé, nadie más publica estadísticas de dominios como ellos.
- strenholme
Con mi propio MaraDNS, optimicé agresivamente el uso de memoria de las entradas de la lista negra usando un único malloc() grande para asignar la memoria de las entradas, y luego recorriendo ese bloque de memoria para las entradas potencialmente en la lista negra.
Cuando usaba un malloc() por entrada, una lista negra grande ocupaba 237 megabytes de memoria. La misma lista negra, una vez optimizada para cargarse con una sola llamada a malloc(), solo ocupaba 9.5 megabytes de memoria.
https://samboy.github.io/blog/entries/MaraDNS.html#BlogEntry...
- vinkelhake
Estas parecen ser algunas de las estrategias bastante estándar para reducir el uso de memoria. No puedo evitar pensar que el enfoque de unir varias listas distintas en una sola de alguna manera socava las garantías de seguridad de Rust.
Si antes tenías tres objetos Vec distintos, Rust garantizaba que no pudieras indexar fuera de los límites. Si ahora pones todos esos objetos en un solo Vec y dependes de los offsets, entonces abres la puerta a indexar fuera del rango de estas sub-rebanadas sin ningún pánico.
Es un punto menor, y no invalida realmente la optimización, pero me sorprende que el artículo no lo mencionara.
- ManBeardPc
La estructura Record contiene rtype y data, donde RecordData es una unión etiquetada. ¿No están siempre sincronizados esos dos? No soy un experto en DNS, solo me pregunto si esto es redundante o hay una razón para que ambos estén ahí. Ya no importa si lo almacenan serializado, pero me interesaría saber por qué era así.
- superze
¿Cuánto es esto en euros o ahora medimos el dinero en RAM?
- bhouston
He tenido problemas al usar wifi público cuando sobrescribo el servidor DNS de mi MacBook a 1.1.1.1 o 8.8.8.8. Creo que esto se debe a que los portales cautivos requieren la resolución personalizada del nombre captive.apple.com. Y los servidores DNS externos no resolverán eso correctamente a la página de autorización del gateway local.