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@iZ94zaby5xkZ basho_bench]# basho_bench -N [email protected] -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 '[email protected]' 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 '[email protected]' 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 '[email protected]' 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 '[email protected]' 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 '[email protected]' 11:58:05.662 [info] Starting max worker: <0.124.0> on '[email protected]' 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 '[email protected]' 11:58:05.663 [info] Starting max worker: <0.118.0> on '[email protected]' 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 '[email protected]' 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 <[email protected]> wrote: > So, the way it should work is pretty simple: > Run the command a la: ./basho_bench -N [email protected] -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 <[email protected]> > 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 [email protected] -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 > [email protected] > http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com > > > _______________________________________________ > riak-users mailing list > [email protected] > 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: [email protected] 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. ********************************************************************************************************************** _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
