Reboot régulier du worker (depuis mises à jour techniques)

[thbar]

Je vais ajouter des éléments ici.

[thbar]

AppSignal n'est pas activé sur le worker pour des questions de quotas (coût etc).

J'hésite à l'activer là car je vais passer offline pendant quelques temps ; peut-être temporiser cela à lundi.

Manipulation pour faire ça:

• éditer les variables d'environnement sur prod-worker
• renommer _CUSTOM_APPSIGNAL_PUSH_API_KEY en CUSTOM_APPSIGNAL_PUSH_API_KEY
• redémarrer

(mais il faudra remettre en place après, et suivre le quota).

Idéalement ça prouve que ça serait bien d'arriver à avoir un suivi "correct au niveau quotas" là dedans.

[thbar]

L'usage mémoire semble avoir baissé sur la moyenne, mais on voit des pics:

[thbar]

Curieux, on voit rapporté une "baisse" de la mémoire avant les crashs. Mais c'est peut-être une fausse info (host non réactif ou autre), je ne sais pas.

[thbar]

On va laisser comme ça pour l'instant, je revisiterai lundi sauf gros souci dans le week-end.

On a noté avec @AntoineAugusti les idées suivantes:

• Noter le temps de checkout et/ou la taille du pool Ecto (mais je crois que c'est plus difficile) et tracer ça quelque part (AppSignal en custom métrique si possible, mais AppSignal est pour l'instant désactivé sur le worker pour des questions de quota. Il faudra peut-être filtrer les events pour arriver à avoir au moins les basiques (host monitoring) et les custom métriques, ça serait cool. On peut aussi exporter ça via une url toute bête
• J'aimerais bien arriver à monitorer depuis Elixir les exécutions de processus externes via Rambo (pendant leur exécution), ça pourrait être très bien.
• Améliorer l'usage de notre pool Ecto : actuellement on est à 15 connection, par machine (x 2), et au déploiement ça fait x 2 soit un total de 60 au maximum (modulo quelques autres connections externes, monitorings outils dévs etc). C'est dommage qu'on n'exploite pas la totalité de ce qui est possible, peut-être qu'on pourrait au shutdown arriver à drainer graduellement les connections

Voilà des idées un peu en vrac pour le moment, à suivre.

[thbar]

Il est à noter également que ces reboots pourraient être totalement une coincidence et sans lien avec la mise à jour Elixir + dépendances (#3429), on va voir si ça se reproduit plus longtemps aujourd'hui ou pas.

Mais sans certitude, on considère que ce n'est pas une coincidence par défaut.

[thbar]

Liens utiles:

• https://jumpwire.io/blog/dbconnection-pooling-deep-dive
• https://github.com/elixir-ecto/db_connection/issues/209
• https://elixirforum.com/t/what-causes-long-idle-time-in-ecto/31916/5

Et en particulier:

idle time is recorded to show how busy or not busy the connection pool is. During connection pool IO overload the idle time will be as close to 0 as it can be, not counting message passing overhead, because then the connections are always in use by processes running transactions/queries

[thbar]

Documentation qui va nous servir:

• https://docs.appsignal.com/metrics/custom.html

Je vais demander à AppSignal comment faire pour filtrer ce qui nous arrange sans exploser notre quota.

[thbar]

On pourrait brancher temporairement (ou définitivement) l'instrumentation Ecto:

• https://docs.appsignal.com/elixir/integrations/ecto.html

Cela dit il faut voir combien de métriques différents cela envoie, pour mesurer l'impact sur la facture.

[thbar]

J'ai contacté AppSignal pour récupérer des infos sur comment affiner la configuration.

[thbar]

Je vais étudier ce point en priorité cette semaine.

[thbar]

@AntoineAugusti a creusé et voit que le job suivant consomme de la RAM et génère un OOM:

Transport.Jobs.ResourceHistoryJob.new(%{
  "resource_id" => 65185, 
  "id" => Ecto.UUID.generate()
}) |> Oban.insert()

C'est très cool car ça va m'aider à vérifier que je détecte le souci avec l'outillage.

[thbar]

https://github.com/etalab/transport-site/blob/11d3a90535f2b386685e74432fd4fb910d00e55f/apps/transport/lib/jobs/resource_history_job.ex#L44

[thbar]

Dans le sens d'activer AppSignal sur tous les hosts, je fais:

• 3441

Et parallèlement j'ai décommenté la variable _CUSTOM_APPSIGNAL_PUSH_API_KEY en CUSTOM_APPSIGNAL_PUSH_API_KEY et redémarré, pour voir si on observe + de choses.

[thbar]

En suivant la RAM et en lançant le job décrit plus haut (https://github.com/etalab/transport-site/issues/3435#issuecomment-1704834969), j'ai vu la RAM monter, mais pas assez haut !

Toutefois ça s'observe à présent très bien.

[thbar]

J'en ai lancé 3 d'un coup 😉 et là ça génère bien un OOM, qu'on retrouve via le drain, c'est top:

Dommage, ça ne s'observe pas visuellement pour le coup, car sûrement trop rapide:

[thbar]

Déjà gros avantage -> on pourra retrouver les OOM dans les logs facilement, et du coup mettre au point de l'outillage et des vérifications plus facilement aussi.

[thbar]

Effectivement, voir:

• https://github.com/etalab/transport-site/issues/3440#issuecomment-1706252388

Je vais remplacer ce ticket par un autre que je linkerai ici.

[thbar]

Remplacé par:

• 3446