YCSB and MongoDB

[roger_d...@lavache.com]

Hello all,


this is a long-shot, bit abstract, however, I will do my best.

We are running MongoDB (V3.4.1) on an IBM z13 mainframe (zLinux - SuSE SLES 12 SP1, 16 VCPU).
The YCSB (0.10) workload works quite well using the above setup.

I am running two Intel Blades firing the workload (workloadc - R/O, each with 64 threads) against MongoDB as outlined above.
On the MongoDB side, I have the YCSB DB defined on Mongo with 300GB, RAM size on the Mainframe is 600GB, so the DB
more or less fits into cache.My TPS/IOPS figures from the two Blades are also quite respectable (250K IOPS inclusive).

We have a special case here, we want to provoke CPU cache misses to increase the "RNI" using YCSB's R/O (workloadc) workload.
For an explanation of RNI, please see here - https://www-304.ibm.com/servers/resourcelink/lib03060.nsf/pages/lsprwork?OpenDocument and here http://www.longpelaexpertise.com.au/ezine/WhyRNI.php

As I am not a Java person but a crusty old Mainframer more comfortable with assembler
rather than this new technology, I would appreciate any tips/pointers as to how I could provoke the above, it at all.


TIA


Roger

[Blaine Gaither]

Roger,

I am working with YCSB Workload C on Mongo.  To increase cache misses you could turn off zipfian and use uniform for this workload.  If that does not work, increase the record count till the workload no longer fits in memory.  

Sorry if the following is stuff you already know:

1. Workloads D and E should be reloaded before each run as those workloads materially change the DB.
2. Also note that if you have too many threads, you increase latency and reduce throughput.  I recommend that you run experiments to find the number of threads needed to get the most throughput and then add 10% more.  Thereafter you can use target to find the ideal load.
   

Blaine