Flujos y uso de memoria

Escribo este artículo breve porque me encontré con un problema grande que a veces pasamos por alto: usar demasiada memoria.

Para dar contexto, estaba investigando por qué una Azure Function reiniciaba constantemente el pod de k8s en producción, provocando retrasos en el procesamiento de datos financieros críticos para los usuarios. Al revisar los logs vi que el proceso era terminado por consumo de memoria, con salida 137 Out Of Memory, y múltiples picos de memoria antes de caer.

La ineficiencia estaba en la función que generaba archivos. Creaba un libro de Excel, lo escribía en un MemoryStream y, en lugar de usar ese stream directamente para subir el contenido, lo convertía en un arreglo de bytes. Ese arreglo se pasaba por varias capas y, en la superior, para cargarlo en el blob, se creaba otro MemoryStream con los mismos datos y recién entonces se subía el archivo. Esta elección consume memoria y CPU de forma innecesaria y presiona al recolector de basura.

Imagina que se procesan en paralelo 10 archivos de 10 MB. Esta implementación añade fácilmente un overhead de unos 200 MB de memoria del programa y estresa al GC, con mayor probabilidad de pausas y reinicios.

La solución fue simple y efectiva: manejar la transferencia de datos usando directamente un Stream de escritura del blob. En vez de materializar el contenido en un arreglo de bytes, abrí un stream de escritura sobre el almacenamiento y escribí el libro de Excel directamente en ese stream. Con ello eliminé la duplicación de buffers y la presión de memoria.

Qué es un Stream. Un Stream es una abstracción para procesar grandes volúmenes de datos en lotes, sin cargar todos los bytes en memoria a la vez. Piensa en un restaurante con una mesa de 20 personas y todas piden refresco. La persona que atiende podría intentar llevar todo de una vez, pero su bandeja solo admite 5 latas a la vez, que sería nuestro límite de memoria. Así que hace 4 viajes, lo que implica más idas y venidas, equivalente a vaciar y continuar con la siguiente porción en cada lectura o escritura del stream. El resultado es eficiente y estable, y por eso los streams son tan usados, desde casos simples como este hasta la base de sistemas orientados a eventos como Kafka.

Vinculando con el problema real. Yo tenía un Excel grande y, en vez de escribirlo a un MemoryStream y convertirlo después en arreglo de bytes para luego recrear otro stream, abrí un stream de escritura del blob y volqué los datos directamente. Con ese cambio desaparecieron los picos de memoria y la Azure Function dejó de reiniciarse.

Conclusión. En lenguajes con mayor nivel de abstracción solemos olvidar la memoria, pero en entornos controlados y en escenarios de escala es clave anticipar cómo crecen los buffers y dónde se materializan los datos. Optar por streams punto a punto minimiza copias, reduce GC y evita caídas. Si quieres comentar o compartir ideas sobre este tema, estaré encantado de leerte.

En Q2BSTUDIO, empresa de desarrollo de software, ayudamos a diseñar arquitecturas eficientes y escalables, optimizando costes y rendimiento en la nube. Somos especialistas en aplicaciones a medida, software a medida, inteligencia artificial, ciberseguridad, servicios cloud AWS y Azure, servicios inteligencia de negocio, power bi, ia para empresas y agentes IA. Si necesitas modernizar tus pipelines de datos, desplegar funciones serverless o endurecer tu seguridad, nuestro equipo puede apoyarte de extremo a extremo.

Descubre cómo optimizar tus cargas en la nube con nuestros servicios cloud AWS y Azure y cómo construimos soluciones robustas y eficientes con aplicaciones a medida y software a medida que aprovechan streaming, almacenamiento en blob y patrones event driven para rendir al máximo.