El primer render real murio OOMKilled con el limite de 1Gi que salia de medir en
la maquina de desarrollo. El host lleva ffmpeg 4.4.2 y la imagen 7.1.5, y 7.0
reescribio la transcodificacion sobre un planificador con colas de fotogramas
decodificados entre componentes: pasarle el WAV como segunda entrada dejaba al
decodificador de video correr por delante y llenar una cola con fotogramas de
6,2 MB. Arreglado partiendo el encode en dos pasos (repo shortsmith), y aqui van
las cifras nuevas, medidas dentro del pod.
requests 768Mi (pico anon 640 MB), limits 1536Mi. El limite no es 1Gi por el
caso techo de 180 s: ahi el pico era 940 MB de 1024 y sobrevivia solo porque
quedaba cache reclamable que soltar. A 1.5Gi memory.events da max 0.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Renderizador determinista JSON->MP4 para Shorts. API interna sin Ingress, en
shortsmith-svc:8080; la cola es por proceso y la SQLite va en RWO, de ahí la
replica unica con estrategia Recreate.
Los recursos van medidos, no estimados, y la tabla con las cifras queda en el
propio manifiesto: el pico son 522 MB de anon y lo pone entero el encode, no el
render. Ojo al comentario sobre por que los workers salen del limite de CPU y no
del request.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Gitea CI
chemavxandClaude Opus 5