Pour LevelDB, comment puis-je obtenir les performances des écritures aléatoires de même que le rapport de performance «officiel» revendiqué?

Question

L'un du site officiel de niveaudb (http://code.google.com/p/leveldb/), il existe un rapport de performance. J'ai collé comme ci-dessous.

Vous trouverez ci-dessous à partir de référence officielle de niveau de niveau

Voici un rapport de performance (avec des explications) de l'exécution du programme DB_Bench inclus. Les résultats sont quelque peu bruyants, mais devraient suffire pour obtenir une estimation de performance de base.

Installer

Nous utilisons une base de données avec un million d'entrées. Chaque entrée a une clé de 16 octets et une valeur de 100 octets. Valeurs utilisées par la compression de référence à environ la moitié de leur taille d'origine. NIVEALDB: Version 1.1

CPU: 4 x Intel (R) Core (TM) 2 Quad CPU Q6600 @ 2,40 GHz

Cpucache: 4096 kb

Clés: 16 octets chacun

Valeurs: 100 octets chacun (50 octets après compression)

Entrées: 1000000

Taille brute: 110,6 Mb (estimé)

Taille du fichier: 62,9 Mo (estimé)

Écrire des performances

Les repères "Fill" créent une toute nouvelle base de données, dans un ordre séquentiel ou aléatoire.

Le benchmark "FILLSYNC" rince du système d'exploitation vers le disque après chaque opération; Les autres opérations d'écriture laissent les données assises dans le cache de tampon du système d'exploitation pendant un certain temps. Le benchmark "écraser" fait des écritures aléatoires qui mettent à jour les clés existantes dans la base de données.

FILLSEQ: 1.765 Micros / OP; 62,7 Mb / s

FILLSYNC: 268.409 Micros / OP; 0,4 Mb / s (10000 OPS)

Fillrandom: 2,460 micros / op; 45,0 Mb / s

Écraser: 2,380 micros / op; 46,5 Mb / s

Chaque "op" ci-dessus correspond à une écriture d'une seule paire de touches / valeur. C'est-à-dire, une référence d'écriture aléatoire va à Environ 400 000 écritures par seconde.

Vous trouverez ci-dessous de mon niveau de référence LevelDB

J'ai fait un peu de référence pour LevelDB, mais j'ai obtenu une vitesse d'écriture 100 fois moins que le rapport.

Voici mes paramètres d'expérience:

1. CPU: Intel Core2 Duo T6670 2,20 GHz
2. Mémoire de 3,0 Go
3. Windows 7 32 bits
4. sans compression
5. options.write_buffer_size = 100Mb
6. options.block_cache = 640Mb

Ce que j'ai fait est très simple: je mets juste 2 millions {key, valeur} et aucune lecture du tout. La clé est un tableau d'octets qui a 20 octets aléatoires et la valeur est également un tableau d'octets avec 100 octets aléatoires. Je mets constamment un nouvel aléatoire {clé, valeur} pour 2 millions de fois, sans aucune opération ailleurs.

Dans mon expérience, je peux voir que la vitesse d'écriture diminue depuis le tout début. La vitesse instantanée (mesurant la vitesse de chaque 1024 écrit) balance entre 50 / s à 10 000 / s. Et Ma vitesse moyenne globale d'écrits pour 2 millions de paires est d'environ 3 000 / s. La vitesse de pointe des écritures est de 10 000 / s.

Comme le rapport affirmait que la vitesse des écritures peut être de 400 000 / s, La vitesse d'écriture de ma référence est de 40 à 130 fois plus lente Et je me demande simplement ce qui ne va pas avec ma référence.

Je n'ai pas besoin de coller mes codes de test ici car c'est super facile, j'ai juste une boucle de temps pour 2 millions de fois, et à l'intérieur de la boucle, pour chaque itération, je génère 20 octets de clé et 100 octets de valeur , puis les mettre dans la base de données de niveaudb. J'ai également mesuré le temps consacré à la génération {clé, valeur}, cela coûte 0 ms.

Est-ce que quelqu'un peut m'aider avec ça? Comment puis-je atteindre 400 000 / s sur les écritures de vitesse avec le niveaudb? Quels paramètres devrais-je améliorer?

Merci

En outre

Je viens de diriger le DB_Bench.cc officiel sur mon machie. Il est 28 fois plus lent que le rapport.

Je pense que comme j'ai utilisé leur propre programme de référence, la seule différence entre ma référence et la leur est la machine.

Answer 1

Vous avez 2 millions de paires de valeurs clés et chaque paire de valeurs de clé est un total de 120 octets, donc 2 millions * 120 octets = 228 Mo de données! Votre cache est de 640 Mo, il est donc tout à fait possible que toutes vos données soient toujours en RAM et qu'elle n'ait jamais vraiment atteint le disque. Comme l'a souligné Kitsune: votre matériel est loin d'être aussi rapide que celui avec lequel Google a testé et si Google avait la même taille de cache, alors pourrait facilement produire 30 fois la différence.

Autres problèmes potentiels:

• Il est difficile de savoir exactement à quel point les clés étaient "aléatoires": le niveaudb fonctionne différemment en fonction de la distribution des clés (même si elle est "aléatoire").
• Les clés de 20 octets seraient moins efficaces que 16 clés d'octets, car elles ne s'alignent pas aussi bien.
• Selon votre disque dur, votre vitesse d'écriture de disque peut être plus lente (Vous vérifiez le vôtre).

Nous pouvons continuer encore et encore, mais il y a tout simplement trop de variables à considérer. Si vous publiez un code qui montre comment votre test s'exécute, nous pouvons recommander des optimisations afin que vous puissiez obtenir de meilleures performances.

Answer 2

Lorsque vous exécutez le même benchmark sur du matériel complètement différent, vous verrez obligé quelques différences.

• Votre processeur est ~ 9x plus faible 2xcores@2.2ghz vs 16xcores@2.4ghz
• Votre disque dur et le lecteur de l'indice de référence officiel n'ont pas été mentionnés (Fibre Nas vs un Drive SSD SSD vs un disque dur disque dur)

Impossible de comparer les pommes aux oranges ou aux pommes aux [fruits inconnus].