J'ai reçu un rapport d'un utilisateur de Redis, et je ne sais pas quoi répondre car je ne suis pas un expert dans le domaine de Linux et de son ordonnanceur, mais nous (en tant que projet Redis) devons comprendre ce type de problèmes en particulier à l'avenir, comme avec Redis Cluster, de nombreuses instances Redis s'exécuteront en même temps dans une seule boîte. Je demande donc de l'aide ici.
Problème:
- Noyau: "Linux redis1 2.6.32-305-ec2 # 9-Ubuntu SMP Thu 15 Apr 08:05:38 UTC 2010 x86_64 GNU / Linux"
- beaucoup de RAM libre, aucun autre processus n'effectuant d'importantes E / S.
- Important , fonctionnant sur une grande instance EC2, pas sur un vrai serveur. Je n'ai jamais vu quelque chose comme ça dans un environnement non virtualisé. L'instance EC2 était: "Mémoire à très grande instance extra-large de 17,1 Go, 6,5 ECU (2 cœurs virtuels avec 3,25 unités de calcul EC2 chacune), 420 Go de stockage d'instance locale, plate-forme 64 bits" .
Fondamentalement, une fois que vous redémarrez une grande instance Redis, le système devient si lent que vous ne pouvez plus taper sur le shell. Lorsque Redis charge une instance, il utilise 100% du processeur (il charge les données aussi rapidement que possible) et lit le fichier dump.rdb de manière séquentielle. Les E / S ne sont pas particulièrement élevées car le chargement est lié au processeur, pas aux E / S.
Pourquoi diable une boîte avec deux processeurs et beaucoup de RAM, pas de choses échangées sur le disque, devrait-elle essentiellement cesser de fonctionner avec cette charge de travail?
J'ai l'impression que cela a beaucoup à voir avec le fait qu'il s'agit d'une instance EC2, donc liée à la technologie de virtualisation utilisée, car je charge tout le temps les jeux de données Redis 24 Go dans ma boîte sans aucun problème (même avec d'autres instances de Redis fonctionnant avec une charge élevée).
Merci pour tout indice!
Salvatore
Modifier : ajouter quelques commentaires que j'ai reçus de Twitter:
de @ezmobius: @antirez première chose à faire est de l'essayer à partir de / mnt ou des lecteurs éphémères locaux pour voir si sa fragilité EBS, 2e est de s'assurer que ce n'est pas la "première pénalité en écriture" (google it) et si c'est le cas alors vous devez d'abord dd 0 sur le disque.
de @dvirsky: @antirez J'exécute de nombreuses instances de redis sur de tels nœuds ec2. J'ai remarqué un ralentissement sur bgsave mais pas ce phénomène.
la source
J'ai eu le même problème sur une instance EC2. Ce n'est probablement pas lié à Redis - cela se produit quand il y a un haut E / S en cours (par exemple lorsque redis charge un fichier de vidage).
Jetez un œil à ce fil sur les forums d'Amazon: https://forums.aws.amazon.com/thread.jspa?messageID=215406
J'ai expérimenté différents noyaux / images et maintenant ça fonctionne bien (sur un vieux noyau 2.6.21).
la source
Vous devez vérifier le vol du processeur (
xx.x%stsur le côté droit de la ligne de processeur) quitops'affiche lorsque vous rencontrez la charge à 100% et le shell gelé. Steal représente la quantité de vos cycles CPU réels qui sont volés à votre machine par un hyperviseur et donnés à une autre machine. Le vol de CPU n'est pertinent que dans les environnements virtualisés. J'ai eu ce problème exact avec les micro-instances et qui a essentiellement rendu mon instance inutilisable pendant environ 1 heure (jusqu'à ce que ma tâche soit terminée) si je fais des tâches gourmandes en CPU.Vous pouvez trouver plus sur ce sujet en lisant cet article sur les Ramblings de Greg . Cependant, si vous prenez la parole de Greg, cela ne devrait se produire que sur les micro-instances.
la source