Les processus de démarrage en même temps sont plus lents que l'échelonnement; Pourquoi?

Question

J'évalue les performances d'une configuration de système expérimentale sur une machine 8-core avec 16 Go de RAM. J'ai deux RDBMS Java de mémoire principale (hsqldb) en cours d'exécution, et par rapport à chacun d'entre eux, je lance un client TPCC (dérivé de jTPCC/BenchmarkSQL).

J'ai des scripts pour lancer des choses, par exemple. les instances de hsqldb sont démarrés avec:

./hsqld.bash 0 & 
./hsqld.bash 1 & 

Si je commence les clients à peu près en même temps:

./hsql-tpcc.bash 0 & 
./hsql-tpcc.bash 1 & 

alors chacun de ces clients a un taux initial dopés à environ 500-1000 tpmC (ce est essentiellement des transactions par minute), puis rapidement (en moins d'une seconde) s'installe à un taux d'environ 200-250 tpmC. OTOH, si j'attends une seconde ou deux avant de commencer le deuxième client:

./hsql-tpcc.bash 0 & 
sleep 1 
./hsql-tpcc.bash 1 & 

alors chacun des clients fonctionne à 2500+ tpmC. Attendre plus d'une seconde ne fait plus de différence.

Ceci est étrange parce que le client 0 parle juste au serveur 0 et le client 1 parle juste au serveur 1. On ne sait pas pourquoi il y a une telle interférence de performance dramatique. Je pensais que cela pouvait être dû à l'affinité du planificateur CPU des clients, mais ils ne prennent qu'environ 1-3% d'un seul noyau lorsqu'ils tournent lentement (20-25% lorsqu'ils sont exécutés rapidement). Une autre suspicion était dans les liaisons NUMA des clients (conflit de mémoire sur le même nœud mémoire), mais la machine ne possède apparemment qu'un seul nœud mémoire (il n'y a que/sys/devices/system/node/node0) et chaque client ne prend que 0.8% de la mémoire. Cela ne semble pas non plus dû aux liaisons CPU pour les instances hsqldb, car les comportements rapides et lents peuvent être vus simplement en redémarrant les clients (et en attente/pas en attente d'une seconde), laissant les mêmes instances hsqldb en cours d'exécution dans les deux cas (il n'est pas nécessaire de redémarrer hsqldb). hsqldb prend 4-8% CPU quand il est lent, 80% CPU quand il est rapide, et 4.3% mem.

D'autres idées pour lesquelles cela pourrait se produire? Il n'y a pas d'E/S disques et je ne suis pas près d'épuiser la mémoire du système. Merci d'avance. Autres informations pertinentes suivantes:

$ uname -a 
Linux hammer.csail.mit.edu 2.6.27.35-170.2.94.fc10.x86_64 #1 SMP Thu Oct 1 14:41:38 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux 

Answer 1

Depuis combien de temps votre « deux principaux mémoire Java SGBDR (hsqldb) » 's été en cours d'exécution avant le test? Si vous les lancez juste avant le test, essayez d'abord de les réchauffer un peu. Laisser le hotspot faire son truc, et passer tout le code if (first_time) { do_initialization(); } dans le db pour que le garbage collector puisse s'installer. De plus, démarrer deux choses (peu importe ce qu'elles sont) en même temps signifie que minimalement, les deux essaient de faire tout leur travail init en même temps (allouer de la mémoire, allouer des pages en swap, trouver et charger bibliothèques, etc.). Ainsi, les deux programmes passent les premières millisecondes de leur vie en conflit d'E/S.