Résumé de l'expérience d'optimisation Redis

Concernant l'optimisation de la gestion de la mémoire, cet article partage principalement avec vous un résumé de l'expérience d'optimisation de Redis, en espérant aider tout le monde.

Redis Hash est un HashMap à l'intérieur de la valeur. Si le nombre de membres de la Map est relativement petit, un format compact similaire au linéaire unidimensionnel sera utilisé pour stocker la Map, ce qui élimine la surcharge de mémoire de. un grand nombre de pointeurs. Ce contrôle de paramètre correspond aux deux éléments suivants dans le fichier de configuration redis.conf :

hash-max-zipmap-entries 64 hash-max-zipmap-value 512

Lorsque la valeur ne dépasse pas la valeur interne de cette carte, lorsqu'il y a 64 membres dans la valeur, elle sera stockée au format compact linéaire. La valeur par défaut est 64, c'est-à-dire s'il y a moins de 64 membres dans la valeur. , un stockage compact linéaire sera utilisé si la valeur dépasse cette valeur, il sera automatiquement converti en un véritable HashMap.

hash-max-zipmap-value signifie que lorsque la longueur de chaque valeur membre dans la valeur Map ne dépasse pas un certain nombre d'octets, un stockage compact linéaire sera utilisé pour économiser de l'espace.

Si l'une des deux conditions ci-dessus dépasse la valeur définie, elle sera convertie en un véritable HashMap, qui n'économisera plus de mémoire. Alors, est-ce que plus la valeur est grande, mieux c'est ? non. L'avantage de HashMap est que la complexité temporelle de la recherche et de l'opération est O(1). Si vous abandonnez Hash et utilisez le stockage unidimensionnel, la complexité temporelle est O(n) si le nombre de

<.> les membres sont petits, alors L'impact n'est pas grand, sinon cela affectera sérieusement les performances, donc le réglage de cette valeur doit être pesé. De manière générale, il s'agit du compromis le plus fondamental entre le coût du temps et le coût de l'espace.

list-max-ziplist-value 64 list-max-ziplist-entries 512 

La taille de la valeur du nœud du type de données de liste est inférieure au nombre d'octets, le format de stockage compact sera utilisé, liste le type de données est inférieur au nombre de nœuds. Un format de stockage compact sans pointeurs sera utilisé.

Pré-allocation de mémoire :

L'implémentation interne de Redis n'a pas beaucoup optimisé l'allocation de mémoire (par rapport à Memcache), et il y aura une fragmentation de la mémoire dans une certaine mesure, mais dans la plupart Dans les cas où cela ne se produit pas, cela deviendra le goulot d'étranglement des performances de Redis. Cependant, si la plupart des données stockées dans Redis sont numériques, Redis utilise un entier partagé en interne pour économiser la surcharge liée à l'allocation de mémoire, c'est-à-dire que lorsque le système démarre, il le fait. attribue d'abord une valeur de 1 à n. Ensuite, plusieurs objets numériques sont placés dans un pool. Si les données stockées se trouvent dans cette plage numérique, l'objet est directement extrait du pool et partagé via un comptage de références. les valeurs numériques sont stockées dans le système. Cela peut également économiser de la mémoire et améliorer les performances dans une certaine mesure. Le réglage de la valeur de ce paramètre n nécessite de modifier une ligne de définition de macro REDIS_SHARED_INTEGERS dans le code source. Vous pouvez le modifier selon vos propres besoins. Il suffit de le recompiler après modification.

Mécanisme de persistance :

Méthode d'instantané temporisé (instantané) :

Cette méthode de persistance est en fait un événement de minuterie dans Redis, qui vérifie l'état actuel à intervalles fixes. et l'heure des modifications des données répondent aux conditions de déclenchement de persistance configurées. Si tel est le cas, un processus enfant sera créé via l'appel fork du système d'exploitation. Ce processus enfant partagera le même espace d'adressage avec le processus parent par défaut. La totalité de la mémoire est parcourue par le processus enfant pour effectuer des opérations de stockage, tandis que le processus principal peut toujours fournir des services. Lorsqu'il y a une écriture, le système d'exploitation effectue une copie sur écriture en unités de pages mémoire pour garantir qu'il n'y a pas de connexion. entre les processus parent et enfant s’influenceront mutuellement.

Le principal inconvénient de cette persistance est que l'instantané planifié ne représente que l'image mémoire sur une période donnée, donc un redémarrage du système perdra toutes les données entre le dernier instantané et le redémarrage.

Méthode d'ajout basée sur une instruction (aof) :

La méthode aof est en fait similaire à la méthode binlog basée sur une instruction de MySQL, c'est-à-dire que chaque commande qui modifie les données de la mémoire Redis sera ajoutée à un log file , ce qui signifie que ce fichier journal est les données persistantes de Redis.

Le principal inconvénient de la méthode aof est que l'ajout du fichier journal peut rendre la taille trop grande. Lorsque le système est redémarré pour restaurer les données, la méthode aof peut être très lente à charger les données. Il faut plusieurs heures pour charger des dizaines de gigaoctets de données. Après le chargement, ce temps n'est bien sûr pas dû au fait que la vitesse de lecture des fichiers disque est lente, mais au fait que toutes les commandes lues doivent être exécutées dans la mémoire. De plus, étant donné que chaque commande doit écrire un journal, les performances de lecture et d'écriture de Redis seront également réduites lors de l'utilisation d'aof.

Vous pouvez envisager de sauvegarder les données sur différentes instances Redis. La taille de la mémoire de chaque instance est d'environ 2 Go. Cela évite de mettre les œufs dans le même panier, ce qui peut non seulement réduire l'impact d'une défaillance du cache sur le système, mais également. Cela peut accélérer la récupération des données, mais cela apporte également une certaine complexité à la conception du système.

Problème de crash de persistance de Redis :

Les personnes ayant une expérience d'exploitation et de maintenance en ligne de Redis constateront que Redis se produira lorsque l'utilisation de la mémoire physique est relativement importante, mais n'a pas dépassé la capacité totale réelle de la mémoire physique. Certaines personnes pensent que le problème d'instabilité ou même de crash est dû au doublement de l'utilisation de la mémoire en raison de l'appel système fork basé sur la persistance des instantanés. Cette vue est inexacte car le mécanisme de copie sur écriture de l'appel fork est basé sur le. page du système d'exploitation. Dans cette unité, c'est-à-dire que seules les pages sales qui ont été écrites seront copiées, mais généralement votre système n'aura pas toutes les pages écrites dans un court laps de temps, ce qui entraînera une copie. Alors, qu'est-ce qui fait planter Redis ?

La réponse est que la persistance de Redis utilise Buffer IO. Le soi-disant Buffer IO signifie que Redis utilise la mémoire physique Page Cache pour les opérations d'écriture et de lecture sur les fichiers persistants, tandis que la plupart des systèmes de bases de données utilisent Direct IO pour contourner cette couche de. Page Cache et maintient un cache de données par lui-même, lorsque le fichier de persistance Redis est trop volumineux (en particulier le fichier d'instantané), et lors de sa lecture et de son écriture, les données du fichier disque seront chargées dans la mémoire physique en tant que couche de. cache pour le fichier dans le système d'exploitation, les données de cette couche de cache et les données gérées dans la mémoire Redis sont en fait stockées de manière répétée. Bien que le noyau fasse le travail d'élimination du cache de page lorsque la mémoire physique est limitée, le noyau. est susceptible de le faire. Si vous pensez qu'un certain cache de page est plus important et laissez votre processus démarrer Swap, votre système commencera à devenir instable ou à planter. Notre expérience est que lorsque l'utilisation de votre mémoire physique Redis dépasse les 3/5 de la capacité totale de la mémoire, elle devient plus dangereuse.

Résumé :

1. Choisissez le type de données approprié en fonction des besoins de l'entreprise et définissez les paramètres de stockage compact correspondants pour différents scénarios d'application.

2. Lorsque le scénario commercial ne nécessite pas la persistance des données, la désactivation de toutes les méthodes de persistance peut obtenir les meilleures performances et une utilisation maximale de la mémoire.

3. Si vous devez utiliser la persistance, choisissez entre la méthode d'instantané et la méthode d'ajout d'instruction selon que vous pouvez tolérer la perte de certaines données après le redémarrage. N'utilisez pas les méthodes de mémoire virtuelle et de stockage de disque.

4. Ne laissez pas l'utilisation de la mémoire physique de votre machine Redis dépasser les 3/5 de la mémoire totale réelle.

L'option maxmemory dans redis.conf, cette option indique à Redis de commencer à rejeter les demandes d'écriture ultérieures après la quantité de mémoire physique utilisée. Ce paramètre peut bien protéger votre Redis contre l'utilisation d'une mémoire physique excessive qui provoquera un échange, ce qui entraînera un échange. finit par affecter sérieusement les performances, voire même un crash.

VM-enabled dans le fichier redis.conf n'est pas

Recommandations associées :

Résumé de l'utilisation de la fonction Redis en php

Enregistrement complet de la construction du cluster Redis

Résumé des méthodes courantes d'exploitation de Redis en PHP

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!