Certains systèmes Linux deviennent très lents lorsque Redis charge un grand ensemble de données


14

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.

Réponses:


4

La sortie de 'top' pourrait donner quelques indices. Il y a un champ en haut à gauche intitulé ``% volé '' qui reflète la quantité de CPU matériel détournée vers d'autres invités sur la même boîte physique. J'ai vu ce genre de ralentissements lorsque l'hyperviseur décide d'allouer plus de CPU à un autre invité, en particulier lorsque j'effectue une tâche gourmande en CPU de longue durée.

Je ne sais pas si c'est votre problème ou non, mais cela vaut la peine de vérifier.


Merci Kevin, c'est très intéressant et je l'ignorais complètement.
antirez

2

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).


Merci mhdk, je suppose également que cela est lié à la virtualisation + au planificateur Linux. Même avec des E / S de disque lentes, je ne vois aucune raison pour laquelle d'autres processus se bloqueraient s'ils n'utilisaient pas le disque et n'avaient pas de pages échangées. Essayer différentes configurations de noyaux / planificateurs vaut probablement la peine d'essayer.
antirez

2

Vous devez vérifier le vol du processeur ( xx.x%stsur le côté droit de la ligne de processeur) qui tops'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.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.