distributed basho bench

Kinson Chan 陳傑信 kinsonchan at clustertech.com
Sun Jan 17 23:03:11 EST 2016


Sorry for pumping the thread, but it looks much less trivial than anticipated.  Without a single line of error, the benchmark program (bhead) simply started everything by itself.  I have watched login records of the remote nodes, and there has not been a single login attempt.  Could anyone give me some hints?  Thanks...

[root at iZ94zaby5xkZ basho_bench]# basho_bench -N bhead at 10.44.90.29 -C mycookies -d /root/basho_bench/results /root/basho_bench/basho_cluster.config                                                                                                                                                      
11:58:02.157 [debug] Lager installed handler {lager_file_backend,
                            "/root/basho_bench/results/20160118_115802/console.log"} into lager_event
11:58:02.157 [debug] Lager installed handler {lager_file_backend,
                            "/root/basho_bench/results/20160118_115802/error.log"} into lager_event
11:58:02.157 [debug] Lager installed handler error_logger_lager_h into error_logger
11:58:02.173 [debug] Supervisor gr_param_sup started gr_param:start_link(gr_lager_default_tracer_params) at pid <0.67.0>
11:58:02.173 [debug] Supervisor gr_counter_sup started gr_counter:start_link(gr_lager_default_tracer_counters) at pid <0.68.0>
11:58:02.173 [debug] Supervisor gr_manager_sup started gr_manager:start_link(gr_lager_default_tracer_params_mgr, gr_lager_default_tracer_params, []) at pid <0.69.0>
11:58:02.173 [debug] Supervisor gr_manager_sup started gr_manager:start_link(gr_lager_default_tracer_counters_mgr, gr_lager_default_tracer_counters, [{input,0},{filter,0},{output,0}]) at pid <0.70.0>
11:58:02.309 [info] Application lager started on node 'bhead at 10.44.90.29'
11:58:02.312 [notice] Changed loglevel of /root/basho_bench/results/20160118_115802/console.log to debug
11:58:02.320 [debug] Supervisor inet_gethost_native_sup started undefined at pid <0.80.0>
11:58:02.320 [debug] Supervisor kernel_safe_sup started inet_gethost_native:start_link() at pid <0.79.0>
11:58:02.642 [debug] Lager installed handler lager_backend_throttle into lager_event
11:58:02.712 [info] No dimension available for key generator: {int_to_bin_bigendian,{uniform_int,200000}}
11:58:02.727 [debug] Supervisor sasl_safe_sup started alarm_handler:start_link() at pid <0.93.0>
11:58:02.728 [debug] Supervisor sasl_safe_sup started overload:start_link() at pid <0.94.0>
11:58:02.732 [debug] Supervisor sasl_sup started supervisor:start_link({local,sasl_safe_sup}, sasl, safe) at pid <0.92.0>
11:58:02.738 [debug] Supervisor sasl_sup started release_handler:start_link() at pid <0.95.0>
11:58:02.738 [info] Application sasl started on node 'bhead at 10.44.90.29'
11:58:02.745 [debug] Supervisor crypto_sup started crypto_server:start_link() at pid <0.101.0>
11:58:02.746 [info] Application crypto started on node 'bhead at 10.44.90.29'
11:58:02.746 [debug] Supervisor folsom_sup started folsom_sample_slide_sup:start_link() at pid <0.111.0>
11:58:02.746 [debug] Supervisor folsom_sup started folsom_meter_timer_server:start_link() at pid <0.112.0>
11:58:02.747 [debug] Supervisor folsom_sup started folsom_metrics_histogram_ets:start_link() at pid <0.113.0>
11:58:02.747 [info] Application folsom started on node 'bhead at 10.44.90.29'
11:58:02.748 [info] Random source: calling crypto:rand_bytes(100663296) (override with the 'value_generator_source_size' config option
11:58:02.748 [debug] Supervisor basho_bench_sup started basho_bench_stats:start_link() at pid <0.106.0>
11:58:05.655 [info] Random source: finished crypto:rand_bytes(100663296)
11:58:05.658 [info] Using target {10,44,90,29}:8087 for worker 1
11:58:05.659 [debug] Supervisor basho_bench_sup started basho_bench_worker:start_link(basho_bench_worker_1, 1) at pid <0.116.0>
11:58:05.660 [info] Using target {10,116,145,71}:8087 for worker 2
11:58:05.660 [info] Using target {10,44,90,29}:8087 for worker 3
11:58:05.661 [info] Using target {10,116,145,71}:8087 for worker 4
11:58:05.661 [debug] Supervisor basho_bench_sup started basho_bench_worker:start_link(basho_bench_worker_2, 2) at pid <0.120.0>
11:58:05.661 [debug] Supervisor basho_bench_sup started basho_bench_worker:start_link(basho_bench_worker_3, 3) at pid <0.123.0>
11:58:05.662 [info] Starting max worker: <0.127.0> on 'bhead at 10.44.90.29'
11:58:05.662 [info] Starting max worker: <0.124.0> on 'bhead at 10.44.90.29'
11:58:05.662 [debug] Supervisor basho_bench_sup started basho_bench_worker:start_link(basho_bench_worker_4, 4) at pid <0.126.0>
11:58:05.662 [info] Starting max worker: <0.121.0> on 'bhead at 10.44.90.29'
11:58:05.663 [info] Starting max worker: <0.118.0> on 'bhead at 10.44.90.29'
11:58:05.663 [debug] Supervisor kernel_safe_sup started timer:start_link() at pid <0.129.0>
11:58:05.663 [info] Application basho_bench started on node 'bhead at 10.44.90.29'

In the basho_cluster.config:
{mode, max}.
{duration, 5}.
{report_interval,1}.
{concurrent, 4}.
{driver, basho_bench_driver_riakc_pb}.
{key_generator, {int_to_bin_bigendian, {uniform_int, 200000}}}.
{value_generator, {fixed_bin, 1000}}.
{riakc_pb_ips, [{10,44,90,29},{10,116,145,71}]}.
{riakc_pb_replies, 1}.
{operations, [{get, 1}, {update, 1}]}.
%% Use {auto_reconnect, false} to get "old" behavior (prior to April 2013).
%% See deps/riakc/src/riakc_pb_socket.erl for all valid socket options.
{pb_connect_options, [{auto_reconnect, true}]}.
%% Overrides for the PB client's default 60 second timeout, on a
%% per-type-of-operation basis.  All timeout units are specified in
%% milliseconds.  The pb_timeout_general config item provides a
%% default timeout if the read/write/listkeys/mapreduce timeout is not
%% specified.
{pb_timeout_general, 30000}.
{pb_timeout_read, 5000}.
{pb_timeout_write, 5000}.
{pb_timeout_listkeys, 50000}.
%% The general timeout will be used because this specific item is commented:
%% {pb_timeout_mapreduce, 50000}.
%% Remote_nodes must be in the format of [{fqdn, nodename}]
%% basho_bench / distributed Erlang use longnames
{remote_nodes, [{'head.local', 'bb'}, {'head2.local', 'bb'}]}.
{distribute_work, true}.

Regards,
Kinson

On 14 Sep, 2015, at 11:23 am, Sargun Dhillon <sargun at sargun.me> wrote:

> So, the way it should work is pretty simple:
> Run the command a la: ./basho_bench -N nodeA at 10.0.1.123 -C basho_bench_cookie <config> 
> (It's key that the IP address be the external IP, and not the internal IP of the box, a la loopback)
> 
> In addition, nodeB must have the same version of Erlang installed as Node A. So, typically, you should install ESL Erlang (my recommendation is R16, https://www.erlang-solutions.com/downloads/download-erlang-otp) on both boxes, and compile your own Basho bench.
> 
> -Thanks,
> Sargun!
> 
> On Thu, Sep 10, 2015 at 9:15 AM, Jens V. Fischer <jensvfischer at gmail.com> wrote:
> Hi,
> 
> I'm trying to use basho bench in distributed mode, that is to say to use more than one machine for load generation. The documentation and the "--join" param of the basho_bench seem to indicate that this should be possible. But so far I failed to set it up. Let's say I want to start basho bench on two nodes, lets call them Node A and B. What parameters to basho_bench are needed on A and B respectively? 
> 
> I also saw the previous mail exchange on the topic (How to run bash bench distributed, 18.5.2015). From there I gathered that I need to use something like the following (for Node A):
> 
> Start command:
> ./basho_bench -N nodeA at 127.0.0.1 -C basho_bench_cookie <config>
> 
> Also I need in my config (on Node A):
> {remote_nodes, [{<domain_name_remote_node>, 'nodeB'}]}.
> {distribute_work, true}.
> 
> Do I need to do anything on Node B? Like starting basho_bench with "--join"? What would the command look like? What do I need to put into my config on Node B? In what order do I have to execute the commands on A and B? 
> 
> Additionally, as I am trying to use the distributed setup with a custom driver: Does distributed mode only works with certain drivers, i.e. does the driver need to support it? For what exactly is the passwordless SSH needed? Because I don't have SSH access on the particular cluster, I do however have access over TCP and are, for example, able to setup distributed Erlang between the nodes. Any chance to get basho_bench working in this setup?
> 
> Any help is greatly appreciated. I'm glad to provide more information if needed. 
> 
> Best regards
> Jens
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com

--
Kinson Chan, PhD
Senior System Engineer
Direct Line: +852 2655 6113        Tel: +852 2655 6100        Email:
kinsonchan at clustertech.com

ClusterTech Limited
Modernize Your Business with Advanced Computing Technologies
Cloud + High Performance Computing + Big Data + FPGA
Business Intelligence ∙ Financial Engineering ∙ Environmental Science ∙ Smart City

Website: www.clustertech.com/         Fax: +852 2994 2101
Hong Kong Address: Units 211 - 213, Lakeside 1, No. 8 Science Park West
Ave., Science Park, N.T. Hong Kong
Hong Kong ∙ Beijing ∙ Shanghai ∙ Guangzhou ∙ Shenzhen ∙ Wuhan ∙ Xi'an ∙ Sydney
**********************************************************************************************************************
The information contained in this e-mail and its attachments is
confidential and intended solely for the specified addressees. If you
have received this email in error, please do not read, copy, distribute,
disclose or use any information of this email in any way and please
immediately notify the sender and delete this email. Thank you for your
cooperation.
**********************************************************************************************************************




More information about the riak-users mailing list