Hi, I noticed another thing in your Basho Bench configuration file. As you have defined the key generator as a `partitioned_sequential_int`, each key will be processed at most once during the run. As you have `get` requests defined in the operations mix, these will, unless you have preloaded the system, always return a `not_found`.
The `partitioned_sequential_int` key generator is often used together with only `insert` operations to pre-load a cluster with data. You could adjust the key interval to match how many keys you want in the system and use this to load an initial set of all objects in the cluster. The `uniform_int` key generator can then be used with the same key interval to run benchmarks where `get` requests will return data, which may make your benchmark more realistic. Best regards, Christian On Sat, Mar 8, 2014 at 4:57 AM, Evan Vigil-McClanahan <emcclana...@basho.com > wrote: > Other tweaks: > > - If you're running on machines with multiple numa zones, +sbt db can help. > - the 2.0 pre-releases have some changes to the networking code that > can help increase, if you're willing to try out an early release. > > On Fri, Mar 7, 2014 at 3:06 PM, Christian Dahlqvist <christ...@basho.com> > wrote: > > As the Protocol Buffer interface generally is faster and more efficient > than > > the HTTP interface, I would also recommend using the > > basho_bench_driver_riakc_pb driver instead of basho_bench_driver_http_raw > > for your benchmarks. > > > > Best regards, > > > > Christian > > > > > > On Fri, Mar 7, 2014 at 10:54 PM, Sean Cribbs <s...@basho.com> wrote: > >> > >> Note as well that the 'concurrent' setting will *not* typically increase > >> throughput beyond a certain point (instead you will simply have many > workers > >> waiting in the run queue). You are also only driving load from a single > >> machine with limits on its CPU and network throughput. Start by trying a > >> more reasonable concurrency level, like two (2) times the number of CPU > >> cores in the basho_bench machine. Also consider running basho_bench from > >> multiple machines at once. Consider the line rate of your network as > well; > >> in the past I have easily been able to saturate a gigabit network with > >> basho_bench. > >> > >> > >> On Fri, Mar 7, 2014 at 4:45 PM, Alexander Sicular <sicul...@gmail.com> > >> wrote: > >>> > >>> How many physical machines (disks/cores/nics) are in your cluster? > >>> > >>> -Alexander > >>> > >>> @siculars > >>> http://siculars.posthaven.com > >>> > >>> Sent from my iRotaryPhone > >>> > >>> On Mar 6, 2014, at 22:07, "yanqun....@mesheven.com" > >>> <yanqun....@mesheven.com> wrote: > >>> > >>> Greetings all... > >>> > >>> I am running tests with Riak Cluster. > >>> When this cluster has only one node, the max throughput is about 1500 > >>> ops/s(CPU becomes the bottleneck). > >>> But after I added 4 more nodes into the cluster, no matter how I > changed > >>> the configuration file of Basho benchmark tool, > >>> the number of throughput have never been more than ~3500 ops/s. > >>> CPU utilization on each node is about 60~65% (captured by iostat and > sar) > >>> > >>> And when I added 5 more nodes(10 nodes totally), it is the same result. > >>> And CPU utilization on each node is about 60%. > >>> I can't understand why. > >>> > >>> During the tests, I tried: > >>> 1)Change ring size from 64 to 128 > >>> 2)Change basho benchmark configuration file, like "mode","concurrent" > and > >>> "key_generator"... > >>> 3)Modify some system limits on both riak nodes and basho bench servers, > >>> such as file descriptor , tcp settings. > >>> 4)Monitoring system like cpu, memory and IO, and none of them become > the > >>> bottleneck. > >>> 5)Monitoring the basho bench server, low load. > >>> > >>> Any ideas? > >>> Or did I make any mistakes in my configuration file? > >>> > >>> Configuration file of Basho benchmark tool: > >>> =================================================================== > >>> {mode, max}. > >>> {duration, 15}. > >>> {concurrent, 500}. > >>> {driver, basho_bench_driver_http_raw}. > >>> {http_raw_ips, > >>> > ["10.11.20.46","10.11.20.47","10.11.20.48","10.11.20.49","10.11.20.50","10.11.20.51","10.11.20.52","10.11.20.53"]}. > >>> {http_raw_port, 8098}. > >>> {http_raw_path, "/riak/test"}. > >>> {key_generator, {partitioned_sequential_int, > >>> 1000000000000000,8000000000000000}}. %%we want 16 bytes long > key-length > >>> {value_generator, {fixed_bin, 1024}}. %%1KB > >>> {operations, [{insert,4}, {get,6}]}. > >>> > >>> > =============================================================================== > >>> > >>> Here are our server specifications(VMs based on Xenserver): > >>> 1)Riak nodes: 2cores + 4GB RAM + 20GB disk > >>> 2)Basho benchmark, 4 cores + 4GB RAM, 30GB disk. > >>> > >>> Thank you very much ! > >>> > >>> _______________________________________________ > >>> riak-users mailing list > >>> riak-users@lists.basho.com > >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >>> > >>> > >>> _______________________________________________ > >>> riak-users mailing list > >>> riak-users@lists.basho.com > >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >>> > >> > >> > >> > >> -- > >> Sean Cribbs <s...@basho.com> > >> Software Engineer > >> Basho Technologies, Inc. > >> http://basho.com/ > >> > >> _______________________________________________ > >> riak-users mailing list > >> riak-users@lists.basho.com > >> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > >> > > > > > > _______________________________________________ > > riak-users mailing list > > riak-users@lists.basho.com > > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > >
_______________________________________________ riak-users mailing list riak-users@lists.basho.com http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
