Bonjour,
Je viens de remarquer que mon instance Gladys plante régulièrement (au moins 2 fois par jour).
En regardant de plus près, il semble que ce soit lié à une consommation excessive de RAM. Gladys tourne sur un mini PC qui dispose de 8Go de RAM.
J’ai 5 caméras configurées ; est-ce que ça peut être la même chose qu’identifiée par @spenceur en 2023 ? Gladys utilisation de la ram
Ce qui est bizzare c’est que les plantages sont réguliers depuis quelques jours seulement alors que ma config (pc et configuration de Gladys) n’a pas bougé depuis des mois !
Suis-je le seul dans cette situation ?
Voici le message d’erreur quand ça plante :
<--- JS stacktrace --->
FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
1: 0xb9c1f0 node::Abort() [node]
2: 0xaa27ee [node]
3: 0xd73950 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xd73cf7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xf51075 [node]
6: 0xf6354d v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
7: 0xfd2574 v8::internal::ScavengeJob::Task::RunInternal() [node]
8: 0xe4304b non-virtual thunk to v8::internal::CancelableTask::Run() [node]
9: 0xc07144 [node]
10: 0xc0a5ae node::PerIsolatePlatformData::FlushForegroundTasksInternal() [node]
11: 0x16754b6 [node]
12: 0x1687a24 [node]
13: 0x1675e1e uv_run [node]
14: 0xad9a4a node::SpinEventLoop(node::Environment*) [node]
15: 0xbe1844 node::NodeMainInstance::Run() [node]
16: 0xb54dc8 node::LoadSnapshotDataAndRun(node::SnapshotData const**, node::InitializationResult const*) [node]
17: 0xb58a2f node::Start(int, char**) [node]
18: 0x7faf5e36724a [/lib/x86_64-linux-gnu/libc.so.6]
19: 0x7faf5e367305 __libc_start_main [/lib/x86_64-linux-gnu/libc.so.6]
20: 0xad789e _start [node]
Psoy
Octobre 11, 2024, 6:36
2
j’ai le meme probleme: plantage regulier
<--- Last few GCs --->
[1:0x58618b0] 2738690 ms: Mark-sweep (reduce) 2039.6 (2083.8) -> 2038.6 (2084.0) MB, 1065.5 / 0.0 ms (average mu = 0.098, current mu = 0.005) allocation failure; scavenge might not succeed
[1:0x58618b0] 2739787 ms: Mark-sweep (reduce) 2039.7 (2084.0) -> 2038.6 (2084.3) MB, 1092.4 / 0.0 ms (average mu = 0.052, current mu = 0.004) allocation failure; scavenge might not succeed
<--- JS stacktrace --->
FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
1: 0xb9c1f0 node::Abort() [node]
2: 0xaa27ee [node]
3: 0xd73950 v8::Utils::ReportOOMFailure(v8::internal::Isolate*, char const*, bool) [node]
4: 0xd73cf7 v8::internal::V8::FatalProcessOutOfMemory(v8::internal::Isolate*, char const*, bool) [node]
5: 0xf51075 [node]
6: 0xf51f78 v8::internal::Heap::RecomputeLimits(v8::internal::GarbageCollector) [node]
7: 0xf62473 [node]
8: 0xf632e8 v8::internal::Heap::CollectGarbage(v8::internal::AllocationSpace, v8::internal::GarbageCollectionReason, v8::GCCallbackFlags) [node]
9: 0xf3dc3e v8::internal::HeapAllocator::AllocateRawWithLightRetrySlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
10: 0xf3f007 v8::internal::HeapAllocator::AllocateRawWithRetryOrFailSlowPath(int, v8::internal::AllocationType, v8::internal::AllocationOrigin, v8::internal::AllocationAlignment) [node]
11: 0xf2020a v8::internal::Factory::NewFillerObject(int, v8::internal::AllocationAlignment, v8::internal::AllocationType, v8::internal::AllocationOrigin) [node]
12: 0x12e543f v8::internal::Runtime_AllocateInYoungGeneration(int, unsigned long*, v8::internal::Isolate*) [node]
13: 0x17120b9 [node]
2024-10-11T20:31:33+0200 <info> index.js:96 (Object.duckDbCreateTableIfNotExist) DuckDB - Creating database table if not exist
2024-10-11T20:31:46+0200 <info> job.purge.js:17 (Job.purge) Deleting all background jobs created before = Fri Oct 04 2024 20:31:46 GMT+0200 (Central European Summer Time)
plantage à 18h51,19h46, et a 20h31
Cest pas nouveau ce probleme de ram malheureusement mais ca n’avait aboutit a rien donc de temps en temps je kill le container pour le relancer
Merci pour ces retours !
Ici on parle de la “Heap Size”, ce n’est pas la même chose que la taille de la RAM disponible sur votre machine.
La Heap Size de Node.js est de 2 Go par défaut il me semble, et elle est atteinte chez vous.
Je vois deux options:
Soit vous étiez déjà limite en terme de heap size et la release de lundi n’a fait que porter le coup de grâce et vous atteignez assez facilement les 2 Go ce qui fait que Gladys crash.
soit il y a un memory leak dans la version de gladys sortie lundi, peu-être due à la mise à jour de la librairie socket-io, et ainsi votre usage RAM augmenterait de façon constante jusqu’au crash
Est-ce que vous avez moyen de suivre votre utilisation RAM dans le temps ? L’idée serait de voir si on est dans le cas 1 ou 2.
L’idée serait de voir si l’utilisation RAM du container Gladys ne fait que croître de manière régulière ou pas !
L’autre option serait juste que la release de lundi n’ait fait qu’augmenter un memory leak déjà existant…
@spenceur Pour ton souci, désolé c’est totalement passé aux oubliettes, je viens de relire le sujet et c’était le problème de fuite mémoire de ffmepg-fluent. Est-ce que tu peux créer une issue Github pour que je regarde lundi ? Je pense qu’on va sortir de cette librairie pour corriger ce souci. Encore désolé
1 « J'aime »
Bonjour,
Je ne sais pas si ça peut aider ; voici l’évolution de la consommation de la RAM de mon mini PC depuis 1 semaine :
Et sur 3 mois :
Bonjour,
Merci @pierre-gilles pour la mise à jour et l’astuce pour l’appliquer immédiatement. Je l’ai fait à 22h50 hier et le résultat est sans appel :
C’est revenu à la normale
2 « J'aime »
Excellent, top @PhilippeMA si ça corrige, c’était bien un souci avec la dernière version socket-io de votre côté alors
