Dégradation de performances TwemProxy (NutCracker) avec .NET Servicestack.redis Client

Question

Configuration Redis et NutCracker sur Centos 6.4.et essayer de se connecter à l'aide du client Servicestack.redis.Trouvé un problème de performance majeur.

Pour tester la gauche seulement 1 instance Redis

beta:
  listen: 0.0.0.0:22122
  hash: fnv1a_64
  distribution: ketama
  auto_eject_hosts: true
  #timeout: 5000
  #server_retry_timeout: 2000
  #server_failure_limit: 3
  redis: true
  servers:
  #- 127.0.0.1:6379:1
   - 127.0.0.1:6380:1

Dans le test de l'unité suivante, j'essaie d'envoyer 100k chaînes à Redis via Noisecracker.

[TestClass]
public class RedisProxyTest
{
    public string host = "192.168.56.112";
    //public int port = 6379;
    public int port = 22122;

    [TestMethod]
    public void TestMethod1()
    {
        var key = "l2";
        var count = 100000;
        using (var redisClient = new RedisClient(host, port))
        {
            var list = new List<string>();
            for (int i = 0; i < count; i++)
            {
                list.Add(Guid.NewGuid().ToString());
            }

            Utils.TimeLog("Remove", () => redisClient.Remove(key));

            Utils.TimeLog("AddRangeToList", () => redisClient.AddRangeToList(key, list));
        }

        using (var redisClient = new RedisClient(host, port))
        {
            redisClient.GetListCount(key);

            Utils.TimeLog("GetRangeFromList", () =>
            {
                var ret = redisClient.GetRangeFromList(key, count / 2, count - 1);
                Console.WriteLine(ret.Count);
            });
        }

    }
}

sur les premières exécutions après que NoiseCracker a redémarré, Addrangetolist travaille avec 1-2 seconde.Mais avec les exécutions suivantes, les performances addrangetolistes tombent considérablement de quelques minutes, encore plus de 20 minutes (si aucun délai de configuration est configuré).Je ne peux pas reproduire de même lorsque vous utilisez Redis directement.Je n'ai pas encore essayé d'autre client.Des idées pourquoi?

Ceci ce que je vois dans la console après le test de l'unité:

Test Name:  TestMethod1
Test Outcome:   Passed  
Remove: 0.0331171
AddRangeToList: 806.8219166
50000
GetRangeFromList: 1.741737

Answer 1

Si CashCracker est en train de former plusieurs dizaines de milliers de connexions ou d'envoi de plusieurs milliers de touches, vous devez utiliser la taille de MBUF de 512

Le lien suivant explique comment interpréter la taille de MBUF? - https://github.com/twitter/twemproxy/issues/141

Chaque connexion client consomme au moins un MBUF. Pour servir une demande, nous avons besoin de deux connexions (une du client à proxy et une autre du proxy au serveur). Nous aurions donc besoin de deux MBUFS.

Une demande fragmentable comme "Get Foo Bar \ r \n', que BTW est fragmentée pour" obtenir foo \ r \n"et" get Bar \ r \ n' consumerait deux MBUF pour la demande et deux MBUF pour la réponse . Donc, une demande fragmentable avec n fragments a besoin N * 2 MBUFS

La bonne chose à propos de MBUF est que la mémoire provient d'une piscine de réutilisation. Une fois qu'un MBUF est alloué, il n'est jamais libéré, mais il suffit de remettre dans la piscine de réutilisation. La mauvaise chose est qu'une fois que MBuf est alloué, il n'est jamais libéré, car un MBUF libéré remonte toujours à la réutilisation piscine - https://github.com/twitter/twemproxy/blob/master/src/nc_mbuf.c#l23-l24 (cela peut être corrigé en mettant un Paramètre de seuil sur la piscine de réutilisation)

Donc, si Caskracker gère des connexions client 1K et 100 connexions de serveur, elle consommerait (max (1000, 100) * 2 * Taille MBUF) pour MBUF. Si nous supposons que les clients envoient une demande non pipeline, alors avec défaut MBUF-Taille de 16k, cela consomme au total 32m.

En outre, si en moyenne toutes les demandes disposent de 10 fragments, la consommation de mémoire serait de 320 m. Au lieu de manipuler des connexions client 1K, indiquez que vous manipuliez 10 km, puis la consommation de mémoire serait de 3,2 g. Maintenant au lieu d'utiliser une taille MBUF par défaut de 16k, vous avez utilisé 512 octets, puis la consommation de mémoire pour le même scénario chuterait à 1000 * 2 * 512 * 10= 10m

C'est la raison pour laquelle "grand nombre" de connexion vous souhaitez choisir une petite valeur pour la taille MBUF comme 512

Answer 2

On dirait que le problème est lié à une utilisation élevée de la mémoire lors du transfert de cette quantité de données.

Par défaut, NuTcracker alloue la taille de la mémoire tampon 16k pour chaque touche.Dans mon cas, il va être 16k * 100000= 1,5 Go .J'ai vu environ 2 Go de pic lors de la surveillance du processus de NoiseCracker.My Cent OS VM a été surchargé et il n'y avait pas assez de mémoire pour gérer cette pointe.