Para LevelDB, ¿cómo puedo obtener el rendimiento de escrituras aleatorias igual al informe de rendimiento "oficial" declarado?

Question

Uno del sitio oficial de leveldb (http://code.google.com/p/leveldb/), hay un informe de rendimiento. Pegué como se muestra a continuación.

A continuación se muestra el punto de referencia oficial leveldb

Aquí hay un informe de rendimiento (con explicaciones) de la ejecución del programa db_bench incluido. Los resultados son algo ruidosos, pero deberían ser suficientes para obtener una estimación del rendimiento aproximado.

<×Configuración

Usamos una base de datos con un millón de entradas. Cada entrada tiene una clave de 16 bytes y un valor de 100 bytes. Los valores utilizados por el banco de pruebas se comprimen aproximadamente a la mitad de su tamaño original. LevelDB: versión 1.1

CPU: 4 x Intel (R) Core (TM) 2 CPU cuádruples Q6600 a 2,40 GHz

CPUCache: 4096 KB

Claves: 16 bytes cada una

Valores: 100 bytes cada uno (50 bytes después de la compresión)

Entradas: 1000000

Tamaño sin procesar: 110,6 MB (estimado)

Tamaño del archivo: 62,9 MB (estimado)

Rendimiento de escritura

Los puntos de referencia de "relleno" crean una nueva base de datos, en orden secuencial o aleatorio.

El punto de referencia "fillsync" descarga datos del sistema operativo al disco después de cada operación; las otras operaciones de escritura dejan los datos en el caché del búfer del sistema operativo durante un tiempo. El punto de referencia "sobrescribir" realiza escrituras aleatorias que actualizan las claves existentes en la base de datos.

secuencia de llenado: 1.765 micros / op; 62,7 MB / s

fillsync: 268.409 micros / op; 0,4 MB / s (10000 operaciones)

relleno aleatorio: 2.460 micros / op; 45,0 MB / s

sobrescribir: 2.380 micros / op; 46,5 MB / s

Cada "operación" anterior corresponde a una escritura de un solo par clave / valor. Es decir, una prueba comparativa de escritura aleatoria tiene aproximadamente 400.000 escrituras por segundo .

A continuación, corresponde a mi punto de referencia leveldb

Hice algunos puntos de referencia para leveldb pero obtuve una velocidad de escritura 100 veces menor que la del informe.

Aquí está la configuración de mi experimento:

1. CPU: Intel Core2 Duo T6670 2.20GHz
2. 3,0 GB de memoria
3. Windows 7 de 32 bits
4. sin compresión
5. options.write_buffer_size= 100 MB
6. options.block_cache= 640 MB

Lo que hice es muy simple: solo puse 2 millones de {clave, valor} y ninguna lectura. La clave es una matriz de bytes que tiene 20 bytes aleatorios y el valor es una matriz de bytes también con 100 bytes aleatorios. Pongo constantemente {clave, valor} aleatorio 2 millones de veces, sin ninguna otra operación.

En mi experimento, puedo ver que la velocidad de escritura disminuye desde el principio. La velocidad instantánea (que mide la velocidad de cada 1024 escrituras) oscila entre 50 / sa 10, 000 / s. Y mi velocidad media general de escritura para 2 millones de pares es de alrededor de 3000 / s. La velocidad máxima de escritura es de 10.000 / s.

Como el informe afirmó que la velocidad de escritura puede ser de 400, 000 / s, la velocidad de escritura de mi punto de referencia es de 40 a 130 veces más lenta y me pregunto qué está mal con mi punto de referencia.

No necesito pegar mis códigos de prueba aquí porque es muy fácil, solo tengo un ciclo while por 2 millones de veces, y dentro del ciclo, para cada iteración, genero 20 bytes de clave y 100 bytes de valor y luego ponerlos en la base de datos leveldb. También medí el tiempo dedicado a la generación de {clave, valor}, cuesta 0 ms.

¿Alguien puede ayudarme con esto? ¿Cómo puedo lograr una velocidad de escritura de 400, 000 / s con leveldb? ¿Qué ajustes debo mejorar?

Gracias

Además

Acabo de ejecutar el archivo db_bench.cc oficial en mi máquina. Es 28 veces más lento que el informe.

Creo que, como utilicé su propio programa de referencia, la única diferencia entre mi referencia y el de ellos es la máquina.

Answer 1

Tiene 2 millones de pares clave-valor y cada par clave-valor tiene un total de 120 bytes, por lo que 2 millones * 120 bytes= 228 MB de datos. Su caché es de 640 MB, por lo que es muy posible que todos sus datos todavía estén en la RAM y nunca hayan llegado al disco. Como señaló Kitsune: su hardware no es ni de lejos tan rápido como el que probó Google y si Google tuviera el mismo tamaño de caché, entonces fácilmente produciría una diferencia de 30 veces.

Otros problemas potenciales:

• Es difícil saber exactamente qué tan "aleatorias" eran las claves: LevelDB funciona de manera diferente según la distribución de claves (incluso si es "aleatoria").
• Las claves de 20 bytes serían menos eficientes que las claves de 16 bytes, porque no se alinean tan bien.
• Dependiendo de su disco duro, la velocidad de escritura de su disco puede ser más lenta ( marque el suyo ).

Podemos seguir y seguir y seguir, pero hay demasiadas variables para considerar. Si publica algún código que demuestre cómo se ejecuta su prueba, podemos recomendar algunas optimizaciones para que pueda obtener un mejor rendimiento.

Answer 2

Cuando ejecuta el mismo punto de referencia en hardware completamente diferente, seguramente verá algunas diferencias.

• Su CPU es ~ 9 veces más débil 2xCores@2.2GHz que 16xCores@2.4GHz
• Su disco duro y el disco del punto de referencia oficial no se mencionaron (NAS de fibra frente a un SSD de unidad de estado sólido frente a un disco duro HDD)

No se pueden comparar manzanas con naranjas o manzanas con [fruta desconocida].