Bonjour,
On a actuellement ce message de warning en continue :
2019-11-27 17:06:07,928 WARN [com.simplicite.util.engine.CoreCache] SIMPLICITE|http://bee829ae2620:8080||WARN|system|com.simplicite.util.engine.CoreCache|getObject||Event: Cache memory is full, increase the pool size *_CACHE_SIZE.
Pourriez vous nous indiquer ce que vous suspecteriez en être la cause et comment y remédier?
En vous remerciant d’avance
Il faudrait activer le monitoring pour voir la montée en mémoire des objets.
Savez vous le faire ? il suffit d’aller dans monitoring et démarrer les sondes, puis suivre l’état de la mémoire périodiquement.
Vous devez avoir des sessions qui n’expirent jamais ou une boucle qui instancie des objets massivement, ou 10000 utilisateurs sur un même serveur…
Faites une recherche des paramètres systèmes *_CACHE_SIZE
Vous pouvez les augmenter mais ça repoussera le problème plus loin, il n’est pas normal d’avoir 10000 objets ou process en mémoire si on ne l’a pas bien anticipé.
S’il s’agit d’un contexte de benchs comme je le suppose, c’est un comportement qui peut arriver si les choses ne sont pas configurées correctements vis à vis de la manière dont sont fait ces test.
Déjà, de quelle version/révision parle t-ton ?
Bonjour David, François,
il semble que des pics de connexion aient été observés sur toutes nos instances Simplicité (y compris sur la BCSI en intranet mardi matin). Sur les environnements AWS, elles sont toutes tombées. Sur l’intranet, la BCSI a soutenu la “charge”.
Nos experts DevOps s’orientent sur des tests de pénétration qui auraient été menés par la sécurité IT… Nous vous tenons informés.
Quoi qu’il en soit, ce comportement contribue à protéger les instances (limitation du pool). Mais il semble que ça ne suffise pas (cf. plantage). Nous savons que les instances ont plantées à peu près au même moment et qu’aucune n’avait consommé la totalité de la mémoire qui était réservée. Ne savons pas encore si la plantage des instances est intervenu du fait d’un “kill” extérieur ou si ce sont les process tomcat internes qui ont planté en n’arrivant pas à allouer la mémoire qui leur était réservée… Il faut que nous capitalisions sur ce cas pour mettre en place des dispositifs d’alerte maîtrisés lorsque ça se produit et que nous définissions les procédures de reprise d’activité “normale”. Nous aurons probablement besoin de votre expertise (à nouveau).
Bruno
Ok s’il s’agit de DDoS il faut regarder qu’elles URL ont et appelées. Je soupçonne que les multiples sessions publiques que ça a généré doivent être la cause de la saturation (une session “public” instancié des objets métier).
Bref on a un sujet de robustesse à creuser ici. Je vous plusieurs manières d’y répondre.