Récemment, un projet a été déployé sur Tencent Cloud et redis a été utilisé pour la mise en cache des données dans le projet. Il a fonctionné pendant trois jours sans aucun problème, mais le quatrième jour, lorsque je suis entré sur une certaine page du site Web, un bogue est apparu. La capture d'écran est la suivante :
org.springframework.data.redis.RedisConnectionFailureException: Cannot get Jedis connection; nested exception is redis.clients.jedis.exceptions.JedisConnectionException: Could not get a resource from the pool
L'exception montre que je ne peux pas me connecter à jedis.Je suis allé vérifier le fonctionnement de redis sur le serveur et j'ai constaté que redis était toujours en cours d'exécution.Ensuite, lorsque j'ai voulu envoyer un ping à redis pour tester, l'erreur suivante s'est produite.
MISCONF Redis is configured to save RDB snapshots, but is currently not able to persist on disk
Signification : Redis est configuré pour enregistrer des instantanés de base de données, mais il ne peut pas actuellement persister sur le disque. Les commandes utilisées pour modifier les données de collection ne peuvent pas être utilisées. Veuillez consulter le journal Redis pour les messages d'erreur détaillés.
Je suis allé sur Internet pour rechercher ce problème, et Internet m'a dit que la raison en était que l'instantané Redis ne pouvait pas être conservé de force. La solution proposée consiste à fermer l'élément de configuration stop-writes-on-bgsave-error après avoir exécuté la commande config set stop-writes-on-bgsave-error no pour résoudre le problème.
root@ubuntu:/usr/local/redis/bin# ./redis-cli
127.0.0.1:6379> config set stop-writes-on-bgsave-error no
Après avoir terminé les opérations ci-dessus, actualisez à nouveau la page Web ~ Cela fonctionne vraiment, génial ! ! Puis je suis allé dormir.
Cependant, après deux jours, le site Web a de nouveau planté ~ Le problème est le même que ci-dessus, alors je suis allé sur Internet pour trouver une solution et j'ai trouvé la solution dans cet article ( https://www.cnblogs.com/qq78292959/ p/3994349 .html )
L'article indique que la définition de config set stop-writes-on-bgsave-error sur no fait que redis ignore cette exception, afin que le programme puisse continuer à s'exécuter, mais en fait, les données ne seront toujours pas stockées sur le disque dur.
En regardant le journal redis, vous trouverez une ligne d'avertissement :
"ATTENTION overcommit_memory est défini sur 0 ! La sauvegarde en arrière-plan peut échouer dans des conditions de mémoire insuffisante. Pour résoudre ce problème, ajoutez 'vm.overcommit_memory = 1' à /etc/sysctl.conf, puis redémarrez ou exécutez la commande 'sysctl vm.overcommit_memory=1 ' pour que cela prenne effet." (Avertissement : la mémoire en surcapacité est définie sur 0 ! Les sauvegardes en arrière-plan peuvent échouer dans les environnements à faible mémoire. Pour résoudre ce problème, ajoutez une entrée 'vm.overcommit_memory= 1' , puis redémarrez (ou exécutez la commande ' sysctl vm.overcommit_memory=1' ) pour qu'il prenne effet.)
Cela signifie que ma mémoire système est insuffisante. J'ai coché la mémoire système libre -m, et il y a évidemment beaucoup de mémoire :
Dans un état second, j'ai suivi la modification de vm.overcommit_memory=1 et le problème a été résolu. Il y a un problème, il est évident que la mémoire système est suffisante, pourquoi redis pense que la mémoire de redis est insuffisante. L'article dans le lien ci-dessus donne également une analyse de la cause du problème
Redis pense que la raison de l'insuffisance de mémoire : [Participez à l'article : À partir de la perte de données de Redis ], en termes simples : Redis doit créer une copie du processus principal afin d'éviter l'animation suspendue du processus principal lors de l'enregistrement des données dans le disque dur, puis complétez les données dans le processus Fork Pour l'opération d'enregistrement sur le disque dur, si le processus principal utilise 4 Go de mémoire, 4 Go supplémentaires sont nécessaires lors du forkage du processus enfant. À ce stade, la mémoire est pas assez, le fork échoue et l'enregistrement des données sur le disque dur échoue également.
Et quel est l'effet de changer vm.overcommit_memory en 1? J'ai vu un blog sur Internet avec l'explication suivante, et je suis personnellement d'accord avec cela
0 — Paramètre par défaut. Compréhension personnelle : Lorsque le processus d'application essaie de demander de la mémoire, le noyau effectue un test. Le noyau vérifiera s'il y a suffisamment de mémoire libre pour que le processus d'application puisse l'utiliser ; s'il y a suffisamment de mémoire libre, l'application de mémoire est autorisée ; sinon, l'application de mémoire échoue et une erreur est renvoyée au processus d'application. Par exemple, pour une machine 1G, le processus A a utilisé 500 Mo. Lorsqu'un autre processus essaie de mallocer 500 Mo de mémoire, le noyau vérifiera et trouvera que la mémoire disponible restante est dépassée, et il provoquera un échec.
1 - Pour les demandes d'application de mémoire, le noyau n'effectuera aucune vérification tant que la mémoire physique n'est pas épuisée, déclenchant OOM pour tuer le processus en mode utilisateur. Il en va de même pour l'exemple ci-dessus, machine 1G, processus A 500M, processus B tente de malloc 500M, il réussira, mais une fois que le noyau trouve que l'utilisation de la mémoire est proche de 1 G (le noyau a une politique), il se déclenchera OOM et tuer un mode utilisateur Process (tuer tactiquement).
2 — Lorsque la mémoire demandée est >= taille de la mémoire SWAP + mémoire physique * N, la demande de mémoire sera rejetée. Expliquez ceci N : N est un pourcentage, déterminé en fonction de overcommit_ratio/100, tel que overcommit_ratio=50, alors N est 50 %.