Degradación de rendimiento Twemproxy (Cascanacker) con .NET servicestack.redis Client

Question

Configuración de Redis y Cascanueces en CentOS 6.4.y tratando de conectarse utilizando el cliente servicestack.redis.Se encuentra un problema de rendimiento importante.

para probar solo la instancia de 1 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

En la siguiente prueba de la unidad, estoy tratando de enviar cuerdas de 100k a Redis a través de Cascanacker.

[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);
            });
        }

    }
}

En las primeras carreras después de que Cascanacker reinicie AddRanGetolist funciona con 1-2 seg.Pero con las ejecuciones posteriores, el rendimiento AddRanGetolist cae significativamente de unos pocos minutos, incluso más de 20 minutos (si no hay tiempo de espera configurado).No puedo reproducir lo mismo cuando se usa Redis directamente.Todavía no probé ningún otro cliente.¿Alguna idea de por qué?

Esto lo que veo en la consola después de la prueba de la unidad:

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

Answer 1

Si el cascanueces está proxing varias decenas de miles de conexiones o enviando una solicitud multi-get con varios miles de teclas, debe usar el tamaño MBUF de 512

¡Los siguientes enlace habla sobre cómo interpretar el tamaño de MBUF? - https://github.com/twitter/twempoxy/issues/141

Cada conexión del cliente consume al menos un MBUF. Para atender una solicitud, necesitamos dos conexiones (una de cliente a proxy y otra de proxy a servidor). Así que necesitaríamos dos MBUFs.

Una solicitud fragmentable como 'Obtenga FOO BAR \ R \ N', que por cierto se fragmenta a 'obtener foo \ r \ n' y 'obtener bar \ r \ n' consumiría dos MBUF para solicitar y dos MBUF para la respuesta . Por lo que una solicitud fragmentable con N Fragments necesita N * 2 MBUFS

Lo bueno de MBUF es que la memoria proviene de un grupo de reutilización. Una vez que se asigna un MBUF, nunca se libera, pero solo vuelve a colocarla en la piscina de reutilización. Lo malo es que una vez que se asigna MBUF, nunca se libera, ya que un MBUF liberado siempre se remonta a la piscina de reutilización: https://github.com/twitter/twempoxy/blob/master/src/nc_mbuf.c#l23-l24 (esto puede ser arreglado al poner un Parámetro de umbral en la piscina de reutilización)

Por lo tanto, si el nutcracker es manejamiento, dice 1K Conexiones de clientes y 100 conexiones de servidor, consumiría (máx. (1000, 100) * 2 * TAMAÑO MBUF) para MBUF. Si asumimos que los clientes están enviando una solicitud no canalizada, luego con el tamaño predeterminado de MBUF de 16K, esto lo haría en total, consumir 32m.

Además, si en promedio, todas las solicitudes tienen 10 fragmentos, entonces el consumo de memoria sería de 320 m. En lugar de manejar las conexiones de cliente 1k, digamos que se estaba manejando 10k, entonces el consumo de memoria sería de 3.2 g. Ahora, en lugar de usar un tamaño de MBUF predeterminado de 16k, usó 512 bytes, luego el consumo de memoria para el mismo escenario se reduciría a 1000 * 2 * 512 * 10= 10M

Esta es la razón por la cual para el 'número grande' de conexión desea elegir un pequeño valor para el tamaño MBUF como 512

Answer 2

Parece que el problema está relacionado con el uso de alta memoria al transferir esa cantidad de datos.

Por defecto, cascanueces asigna el tamaño de búfer 16k para cada tecla.En mi caso, va a ser 16k * 100000= 1.5GB .Vi alrededor de 2 GB de pico al ver el proceso de cascanueces.My Cent OS VM fue sobrecargado y no había suficiente memoria para manejar esa espiga.