Historias
Slashboxes
Comentarios
Búsqueda

Un vistazo al interior de memcached

Entrada escrita por mig21 y editada por rvr el Lunes, 10 Noviembre de 2008, 16:36h   Printer-friendly   Email story
desde el dept. start-stop
Programación
Leo en El valle del Viento Helado un artículo acerca de la arquitectura interna de memcached. memcached es un sistema de cachés genéricas muy usado en aplicaciones web. En el artículo se repasa tanto la elección de libevent como sistema de gestión de eventos sobre descriptores de fichero, el uso de funciones de entrada/salida no bloqueantes y sobre todo una gestión de memoria basada en un slab allocator. Contiene además enlaces con más información sobre el tema aunque como siempre la información última está en el código fuente.

«  WPA (TKIP) parcialmente roto | Firefox cumple 4 años  »

Un vistazo al interior de memcached | Log in/Crear cuenta | Top | 5 comentarios | Buscar hilo
Mostrar opciones Umbral:
Y recuerda: Los comentarios que siguen pertenecen a las personas que los han enviado. No somos responsables de los mismos.

  • No lo entiendo

    (Puntos:2)
    por Draco (3721) el Lunes, 10 Noviembre de 2008, 18:42h (#1098484)
    ( http://barrapunto.com/index.pl?section=mbp-draco | Última bitácora: Viernes, 18 Julio de 2008, 19:56h )
    Básicamente está rehaciendo el trabajo de malloc(). Llamar a malloc() o free() no implica necesariamente un cambio de contexto así que no hay ningún beneficio intrínseco en evitar llamarlos. Y hay que decir que no hay un malloc, sino muchos. Cada sistema viene al menos con uno (Solaris con 3 si no recuerdo mal), cada uno con sus virtudes y defectos, y si hay una implementación que funciona bien se puede incluir en tu programa no tienes por qué usar el nativo del sistema.

    En fin, me parece raro que ninguna implementación fuese lo suficiente buena para memcached.
    --

    Programs should be written for people to read, and only incidentally for machines to execute

    [ Responder ]

    • Fragmentación y orden del algoritmo

      (Puntos:4, Interesante)
      por Drizzt (39) el Lunes, 10 Noviembre de 2008, 20:36h (#1098516)
      ( http://icewinddale.blogspot.com/ | Última bitácora: Jueves, 11 Diciembre de 2008, 09:05h )
      Al menos, en Linux, la implementación usa las llamadas al sistema brk para ajustar el tamaño del heap y mmap cuando lo que tiene que reservar es un bloque muy grande de memoria (este siempre en el tamaño de página de la máquina). El sistema basado en brk lo que hace es fragmentar la memoria y podría darse el caso de que, aún existiendo bloques libres, no se pueda reservar uno del tamaño que se pide (por lo que he leido, el malloc de glibc usa la implementación deWolfram Gloger [malloc.de], a su vez basado en la de Doug Lea [oswego.edu], basado en un algoritmo de "best-fit")

      La otra ventaja es que el algoritmo es O(1), no dependiendo del número de bloques libres para buscar el que mejor se adapta a la petición de memoria.

      Una cosa - aunque no lo usa la implementación de memcached -, es que la implementación original del slab, permitía tener funciones constructoras y destructoras. De esta manera, una vez que se libera un bloque de memoria, el objeto que contenía podía dejarse en un estado "conocido" y no era necesario volver a inicializarlo.

      --

      -- icewinddale.blogspot.com [blogspot.com]

    • Re:No lo entiendo de lasizoillo (Puntos:2) Lunes, 10 Noviembre de 2008, 20:56h
    • Uso del malloc del sistema (llegando tarde) de mig21 (Puntos:3) Martes, 11 Noviembre de 2008, 11:35h
    • 1 respuesta por debajo de tu umbral de lectura actual.