Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Load and update fail issue #1271

Closed
phemoski opened this issue Jan 3, 2019 · 21 comments
Closed

Load and update fail issue #1271

phemoski opened this issue Jan 3, 2019 · 21 comments

Comments

@phemoski
Copy link

phemoski commented Jan 3, 2019

I use the following command to load data in mongodb , but the following raed and update fail keep popping up. pls how do i avoid this problem

bin/ycsb load mongodb-async -s -P workloads/workloada > outputLoad.txt

mongo client connection created with mongodb://localhost:27017/ycsb?w=1

[OVERALL] | RunTime(ms) | 3632
[OVERALL] | Throughput(ops/sec) | 275.3303965
[TOTAL_GCS_PS_Scavenge] | Count | 3
[TOTAL_GC_TIME_PS_Scavenge] | Time(ms) | 23
[TOTAL_GC_TIME_%PS_Scavenge] | Time(%) | 0.633259912
[TOTAL_GCS_PS_MarkSweep] | Count | 0
[TOTAL_GC_TIME_PS_MarkSweep] | Time(ms) | 0
[TOTAL_GC_TIME
%PS_MarkSweep] | Time(%) | 0
[TOTAL_GCs] | Count | 3
[TOTAL_GC_TIME] | Time(ms) | 23
[TOTAL_GC_TIME
%] | Time(%) | 0.633259912
[READ] | Operations | 102
[READ] | AverageLatency(us) | 3149.284314
[READ] | MinLatency(us) | 861
[READ] | MaxLatency(us) | 105855
[READ] | 95thPercentileLatency(us) | 8383
[READ] | 99thPercentileLatency(us) | 26991
[READ] | Return=OK | 102
[READ] | Return=NOT_FOUND | 840
[UPDATE-FAILED] | Operations | 55
[UPDATE-FAILED] | AverageLatency(us) | 3327.836364
[UPDATE-FAILED] | MinLatency(us) | 1126
[UPDATE-FAILED] | MaxLatency(us) | 25327
[UPDATE-FAILED] | 95thPercentileLatency(us) | 6971
[UPDATE-FAILED] | 99thPercentileLatency(us) | 24703
[CLEANUP] | Operations | 1
[CLEANUP] | AverageLatency(us) | 3355
[CLEANUP] | MinLatency(us) | 3354
[CLEANUP] | MaxLatency(us) | 3355
[CLEANUP] | 95thPercentileLatency(us) | 3355
[CLEANUP] | 99thPercentileLatency(us) | 3355
[READ-FAILED] | Operations | 840
[READ-FAILED] | AverageLatency(us) | 1995.982143
[READ-FAILED] | MinLatency(us) | 540
[READ-FAILED] | MaxLatency(us) | 202239
[READ-FAILED] | 95thPercentileLatency(us) | 4691
[READ-FAILED] | 99thPercentileLatency(us) | 18239
[UPDATE] | Operations | 3
[UPDATE] | AverageLatency(us) | 1630
[UPDATE] | MinLatency(us) | 1185
[UPDATE] | MaxLatency(us) | 2311
[UPDATE] | 95thPercentileLatency(us) | 2311
[UPDATE] | 99thPercentileLatency(us) | 2311
[UPDATE] | Return=OK | 3
[UPDATE] | Return=NOT_FOUND | 55

@allanbank
Copy link
Collaborator

Did you start with an empty MongoDB instance before the load?

Can you provide the workload file you used and the exact command lines for both the load and run(s)? The output does not seem to match the workloada file from git.

@phemoski
Copy link
Author

phemoski commented Jan 3, 2019

The workload config file i used is;

recordcount=1000
operationcount=1000
workload=com.yahoo.ycsb.workloads.CoreWorkload
readallfields=true
readproportion=0.5
updateproportion=0.5
scanproportion=0
insertproportion=0
requestdistribution=zipfian

and the exact command path I used is;

C:/ycsb 0.14.0>python27/python.exe

bin/ycsb load mongodb-async -s -P workloads/workloada > outputLoad.txt

@allanbank
Copy link
Collaborator

@phemoski -

That is the command for the 'load'. What command did you use for the 'run'?

The output you posted appears to be from a different workload because the percent of read (942) to update (58) operations is not 50/50 (or 0.5/0.5). It looks more like a 'workloadb' (0.95/0.5)

A 'run' has to be done after a compatible 'load'. The easiest way to ensure the load is compatible is to use the same workload file.

workloada and workloadb should be compatible as long as the record count is the same in both.

Can you post the output from the 'load'?

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

this is the command for the run bin/ycsb run mongodb-async -s -P workloads/workloada > outputLoad.txt

@allanbank
Copy link
Collaborator

The logs are not matching the information you posted.

Can you run the workloads again and this time name the logs something different e.g., outputWorkloadALoad.txt and outputWorkloadARun.txt) and post all of the following:

  • workloads/workloada
  • outputWorkloadALoad.txt
  • outputWorkloadARun.txt

I am starting to think that maybe something happened during the load phase.

Rob.

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

I load the workload, I name the log as outputWorkloadfAload.txt and this the output

mongo connection created with mongodb://localhost:27017/ycsb?w=1
[OVERALL], RunTime(ms), 231
[OVERALL], Throughput(ops/sec), 0.0
[TOTAL_GCS_PS_Scavenge], Count, 1
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 7
[TOTAL_GC_TIME_%PS_Scavenge], Time(%), 3.0303030303030303
[TOTAL_GCS_PS_MarkSweep], Count, 0
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 0
[TOTAL_GC_TIME
%PS_MarkSweep], Time(%), 0.0
[TOTAL_GCs], Count, 1
[TOTAL_GC_TIME], Time(ms), 7
[TOTAL_GC_TIME
%], Time(%), 3.0303030303030303
[CLEANUP], Operations, 1
[CLEANUP], AverageLatency(us), 2321.0
[CLEANUP], MinLatency(us), 2320
[CLEANUP], MaxLatency(us), 2321
[CLEANUP], 95thPercentileLatency(us), 2321
[CLEANUP], 99thPercentileLatency(us), 2321
[INSERT], Operations, 0
[INSERT], AverageLatency(us), NaN
[INSERT], MinLatency(us), 9223372036854775807
[INSERT], MaxLatency(us), 0
[INSERT], 95thPercentileLatency(us), 0
[INSERT], 99thPercentileLatency(us), 0
[INSERT], Return=ERROR, 1
[INSERT-FAILED], Operations, 1
[INSERT-FAILED], AverageLatency(us), 113184.0
[INSERT-FAILED], MinLatency(us), 113152
[INSERT-FAILED], MaxLatency(us), 113215
[INSERT-FAILED], 95thPercentileLatency(us), 113215
[INSERT-FAILED], 99thPercentileLatency(us), 113215

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

I also ran the workload, and name the log as outputWorkloadfARun.txt and this the output

mongo connection created with mongodb://localhost:27017/ycsb?w=1
[OVERALL], RunTime(ms), 985
[OVERALL], Throughput(ops/sec), 1015.2284263959391
[TOTAL_GCS_PS_Scavenge], Count, 1
[TOTAL_GC_TIME_PS_Scavenge], Time(ms), 7
[TOTAL_GC_TIME_%PS_Scavenge], Time(%), 0.7106598984771574
[TOTAL_GCS_PS_MarkSweep], Count, 0
[TOTAL_GC_TIME_PS_MarkSweep], Time(ms), 0
[TOTAL_GC_TIME
%PS_MarkSweep], Time(%), 0.0
[TOTAL_GCs], Count, 1
[TOTAL_GC_TIME], Time(ms), 7
[TOTAL_GC_TIME
%], Time(%), 0.7106598984771574
[READ], Operations, 99
[READ], AverageLatency(us), 1218.7373737373737
[READ], MinLatency(us), 268
[READ], MaxLatency(us), 36511
[READ], 95thPercentileLatency(us), 2645
[READ], 99thPercentileLatency(us), 8343
[READ], Return=OK, 99
[READ], Return=NOT_FOUND, 833
[UPDATE-FAILED], Operations, 64
[UPDATE-FAILED], AverageLatency(us), 1708.453125
[UPDATE-FAILED], MinLatency(us), 534
[UPDATE-FAILED], MaxLatency(us), 10871
[UPDATE-FAILED], 95thPercentileLatency(us), 8295
[UPDATE-FAILED], 99thPercentileLatency(us), 10351
[CLEANUP], Operations, 1
[CLEANUP], AverageLatency(us), 2401.0
[CLEANUP], MinLatency(us), 2400
[CLEANUP], MaxLatency(us), 2401
[CLEANUP], 95thPercentileLatency(us), 2401
[CLEANUP], 99thPercentileLatency(us), 2401
[READ-FAILED], Operations, 833
[READ-FAILED], AverageLatency(us), 609.4117647058823
[READ-FAILED], MinLatency(us), 192
[READ-FAILED], MaxLatency(us), 78015
[READ-FAILED], 95thPercentileLatency(us), 958
[READ-FAILED], 99thPercentileLatency(us), 3813
[UPDATE], Operations, 4
[UPDATE], AverageLatency(us), 959.0
[UPDATE], MinLatency(us), 826
[UPDATE], MaxLatency(us), 1101
[UPDATE], 95thPercentileLatency(us), 1101
[UPDATE], 99thPercentileLatency(us), 1101
[UPDATE], Return=OK, 4
[UPDATE], Return=NOT_FOUND, 64

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

But as you can see, for the load I have zero insert and one insert fail operation then lantency insert fail also. I also have both update and read fail during the run stage.

@allanbank
Copy link
Collaborator

Is MongoDB running on the same machine that you are running the ycsb on? Can you connect via the mongo shell to localhost:27017?

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

yes mongodb server is started and the mongob shell is connected, this is the output i also got

mongo client connection created with mongodb://localhost:27017/ycsb?w=
[OVERALL] RunTime(ms) 9460
[OVERALL] Throughput(ops/sec) 0
[TOTAL_GCS_PS_Scavenge] Count 1
[TOTAL_GC_TIME_PS_Scavenge] Time(ms) 7
[TOTAL_GC_TIME_%PS_Scavenge] Time(%) 0.073995772
[TOTAL_GCS_PS_MarkSweep] Count 0
[TOTAL_GC_TIME_PS_MarkSweep] Time(ms) 0
[TOTAL_GC_TIME
%PS_MarkSweep] Time(%) 0
[TOTAL_GCs] Count 1
[TOTAL_GC_TIME] Time(ms) 7
[TOTAL_GC_TIME
%] Time(%) 0.073995772
[CLEANUP] Operations 1
[CLEANUP] AverageLatency(us) 9532
[CLEANUP] MinLatency(us) 9528
[CLEANUP] MaxLatency(us) 9535
[CLEANUP] 95thPercentileLatency(us) 9535
[CLEANUP] 99thPercentileLatency(us) 9535
[INSERT] Operations 0
[INSERT] AverageLatency(us) NaN
[INSERT] MinLatency(us) 9.22337E+18
[INSERT] MaxLatency(us) 0
[INSERT] 95thPercentileLatency(us) 0
[INSERT] 99thPercentileLatency(us) 0
[INSERT] Return=ERROR 1
[INSERT-FAILED] Operations 1
[INSERT-FAILED] AverageLatency(us) 121952
[INSERT-FAILED] MinLatency(us) 121920
[INSERT-FAILED] MaxLatency(us) 121983
[INSERT-FAILED] 95thPercentileLatency(us) 121983
[INSERT-FAILED] 99thPercentileLatency(us) 121983

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

This is the path I use

C:\YCSB-14\ycsb-0.14.0>c:\Python27\python.exe bin\ycsb load mongodb -s -P workloads\workloada -p mongodb.url=mongodb://localhost:27017/ycsb?=0>outputworkloadALoad.txt

@allanbank
Copy link
Collaborator

The fact that there is only a single insert operation and it failed means the client is probably not connecting. Is there any logging to the screen with an error message.

There should have been something written to stderr.

https://github.com/brianfrankcooper/YCSB/blob/master/mongodb/src/main/java/com/yahoo/ycsb/db/AsyncMongoDbClient.java#L299

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

Here is the path i use to connect to the server
C:>cd C:\Program Files\MongoDB\Server\4.0\bin

This is the output

C:\Program Files\MongoDB\Server\4.0\bin>mongod
2019-01-07T02:47:52.740-0800 I CONTROL [main] Automatically disabling TLS 1.0, to force-enable TLS 1.0 specify --sslDisabledProtocols 'none'
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] MongoDB starting : pid=3588 port=27017 dbpath=C:\data\db\ 64-bit host=hp
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] targetMinOS: Windows 7/Windows Server 2008 R2
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] db version v4.0.5
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] git version: 3739429dd92b92d1b0ab120911a23d50bf03c412
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] allocator: tcmalloc
2019-01-07T02:47:52.745-0800 I CONTROL [initandlisten] modules: none
2019-01-07T02:47:52.746-0800 I CONTROL [initandlisten] build environment:
2019-01-07T02:47:52.746-0800 I CONTROL [initandlisten] distmod: 2008plus-ssl
2019-01-07T02:47:52.746-0800 I CONTROL [initandlisten] distarch: x86_64
2019-01-07T02:47:52.746-0800 I CONTROL [initandlisten] target_arch: x86_64
2019-01-07T02:47:52.746-0800 I CONTROL [initandlisten] options: {}
2019-01-07T02:47:52.747-0800 W STORAGE [initandlisten] Detected unclean shutdown - C:\data\db\mongod.lock is not empty.
2019-01-07T02:47:52.747-0800 I STORAGE [initandlisten] Detected data files in C:\data\db\ created by the 'wiredTiger' storage engine, so setting the active storage engine to 'wire
dTiger'.
2019-01-07T02:47:52.749-0800 W STORAGE [initandlisten] Recovering data from the last clean checkpoint.
2019-01-07T02:47:52.750-0800 I STORAGE [initandlisten] wiredtiger_open config: create,cache_size=1509M,session_max=20000,eviction=(threads_min=4,threads_max=4),config_base=false,s
tatistics=(fast),log=(enabled=true,archive=true,path=journal,compressor=snappy),file_manager=(close_idle_time=100000),statistics_log=(wait=0),verbose=(recovery_progress),
2019-01-07T02:47:53.341-0800 I STORAGE [initandlisten] WiredTiger message [1546858073:341055][3588:140704702468224], txn-recover: Main recovery loop: starting at 12/17536 to 13/25
6
2019-01-07T02:47:53.343-0800 I STORAGE [initandlisten] WiredTiger message [1546858073:343047][3588:140704702468224], txn-recover: Recovering log 12 through 13
2019-01-07T02:47:53.532-0800 I STORAGE [initandlisten] WiredTiger message [1546858073:532167][3588:140704702468224], txn-recover: Recovering log 13 through 13
2019-01-07T02:47:53.682-0800 I STORAGE [initandlisten] WiredTiger message [1546858073:682267][3588:140704702468224], txn-recover: Set global recovery timestamp: 0
2019-01-07T02:47:54.068-0800 I RECOVERY [initandlisten] WiredTiger recoveryTimestamp. Ts: Timestamp(0, 0)
2019-01-07T02:47:54.388-0800 I CONTROL [initandlisten]
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten]
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** WARNING: This server is bound to localhost.
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** Remote systems will be unable to connect to this server.
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** Start the server with --bind_ip

to specify which IP
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** addresses it should serve responses from, or with --bind_ip_all to
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten] ** bind to all interfaces. If this behavior is desired, start the
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten] ** server with --bind_ip 127.0.0.1 to disable this warning.
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten]
2019-01-07T02:47:54.752-0800 I FTDC [initandlisten] Initializing full-time diagnostic data capture with directory 'C:/data/db/diagnostic.data'
2019-01-07T02:47:54.755-0800 I NETWORK [initandlisten] waiting for connections on port 27017
2019-01-07T02:48:17.940-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49340 #1 (1 connection now open)
2019-01-07T02:48:17.941-0800 I NETWORK [conn1] received client metadata from 127.0.0.1:49340 conn1: { application: { name: "MongoDB Shell" }, driver: { name: "MongoDB Internal Cli
ent", version: "4.0.5" }, os: { type: "Windows", name: "Microsoft Windows 8.1", architecture: "x86_64", version: "6.3 (build 9600)" } }
2019-01-07T02:49:56.796-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49351 #2 (2 connections now open)
2019-01-07T02:49:56.933-0800 I NETWORK [conn2] end connection 127.0.0.1:49351 (1 connection now open)
2019-01-07T02:49:56.962-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49352 #3 (2 connections now open)
2019-01-07T02:49:57.206-0800 I NETWORK [conn3] end connection 127.0.0.1:49352 (1 connection now open)
2019-01-07T02:50:30.061-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49353 #4 (2 connections now open)
2019-01-07T02:50:30.090-0800 I NETWORK [conn4] end connection 127.0.0.1:49353 (1 connection now open)
2019-01-07T02:50:30.093-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49354 #5 (2 connections now open)
2019-01-07T02:50:30.781-0800 I NETWORK [conn5] end connection 127.0.0.1:49354 (1 connection now open)
2019-01-07T02:51:14.047-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49363 #6 (2 connections now open)
2019-01-07T02:51:14.075-0800 I NETWORK [conn6] end connection 127.0.0.1:49363 (1 connection now open)
2019-01-07T02:51:14.078-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49364 #7 (2 connections now open)
2019-01-07T02:51:14.631-0800 I NETWORK [conn7] end connection 127.0.0.1:49364 (1 connection now open)
2019-01-07T02:51:45.018-0800 W FTDC [ftdc] Uncaught exception in 'FileRenameFailed: The process cannot access the file because it is being used by another process' in full-time
diagnostic data capture subsystem. Shutting down the full-time diagnostic data capture subsystem.
2019-01-07T02:56:56.594-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49425 #8 (2 connections now open)
2019-01-07T02:56:56.625-0800 I NETWORK [conn8] end connection 127.0.0.1:49425 (1 connection now open)
2019-01-07T02:56:56.637-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49426 #9 (2 connections now open)
2019-01-07T02:56:56.681-0800 I NETWORK [conn9] end connection 127.0.0.1:49426 (1 connection now open)
2019-01-07T02:57:30.598-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49432 #10 (2 connections now open)
2019-01-07T02:57:30.626-0800 I NETWORK [conn10] end connection 127.0.0.1:49432 (1 connection now open)
2019-01-07T02:57:30.628-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49433 #11 (2 connections now open)
2019-01-07T02:57:31.459-0800 I NETWORK [conn11] end connection 127.0.0.1:49433 (1 connection now open)
2019-01-07T03:18:38.941-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49562 #12 (2 connections now open)
2019-01-07T03:18:38.976-0800 I NETWORK [conn12] received client metadata from 127.0.0.1:49562 conn12: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:18:39.032-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49563 #13 (3 connections now open)
2019-01-07T03:18:39.033-0800 I NETWORK [conn13] received client metadata from 127.0.0.1:49563 conn13: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:18:40.117-0800 I NETWORK [conn13] end connection 127.0.0.1:49563 (2 connections now open)
2019-01-07T03:18:40.118-0800 I NETWORK [conn12] end connection 127.0.0.1:49562 (1 connection now open)
2019-01-07T03:19:27.082-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49568 #14 (2 connections now open)
2019-01-07T03:19:27.120-0800 I NETWORK [conn14] received client metadata from 127.0.0.1:49568 conn14: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:19:27.196-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49569 #15 (3 connections now open)
2019-01-07T03:19:27.206-0800 I NETWORK [conn15] received client metadata from 127.0.0.1:49569 conn15: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:19:28.714-0800 I NETWORK [conn15] end connection 127.0.0.1:49569 (2 connections now open)
2019-01-07T03:19:28.715-0800 I NETWORK [conn14] end connection 127.0.0.1:49568 (1 connection now open)
2019-01-07T03:20:39.865-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49573 #16 (2 connections now open)
2019-01-07T03:20:39.881-0800 I NETWORK [conn16] received client metadata from 127.0.0.1:49573 conn16: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:20:39.930-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49574 #17 (3 connections now open)
2019-01-07T03:20:39.930-0800 I NETWORK [conn17] received client metadata from 127.0.0.1:49574 conn17: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:20:41.511-0800 I NETWORK [conn17] end connection 127.0.0.1:49574 (2 connections now open)
2019-01-07T03:20:41.512-0800 I NETWORK [conn16] end connection 127.0.0.1:49573 (1 connection now open)
2019-01-07T03:21:33.355-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49575 #18 (2 connections now open)
2019-01-07T03:21:33.368-0800 I NETWORK [conn18] received client metadata from 127.0.0.1:49575 conn18: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:21:33.416-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49576 #19 (3 connections now open)
2019-01-07T03:21:33.417-0800 I NETWORK [conn19] received client metadata from 127.0.0.1:49576 conn19: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:21:33.553-0800 I NETWORK [conn19] end connection 127.0.0.1:49576 (2 connections now open)
2019-01-07T03:21:33.554-0800 I NETWORK [conn18] end connection 127.0.0.1:49575 (1 connection now open)
2019-01-07T03:25:04.625-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49598 #20 (2 connections now open)
2019-01-07T03:25:04.639-0800 I NETWORK [conn20] received client metadata from 127.0.0.1:49598 conn20: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:25:04.689-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49599 #21 (3 connections now open)
2019-01-07T03:25:04.690-0800 I NETWORK [conn21] received client metadata from 127.0.0.1:49599 conn21: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:25:04.765-0800 I NETWORK [conn21] end connection 127.0.0.1:49599 (2 connections now open)
2019-01-07T03:25:04.766-0800 I NETWORK [conn20] end connection 127.0.0.1:49598 (1 connection now open)
2019-01-07T03:32:45.697-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49702 #22 (2 connections now open)
2019-01-07T03:32:45.711-0800 I NETWORK [conn22] received client metadata from 127.0.0.1:49702 conn22: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:32:45.761-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49703 #23 (3 connections now open)
2019-01-07T03:32:45.762-0800 I NETWORK [conn23] received client metadata from 127.0.0.1:49703 conn23: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:32:45.827-0800 I NETWORK [conn23] end connection 127.0.0.1:49703 (2 connections now open)
2019-01-07T03:32:45.829-0800 I NETWORK [conn22] end connection 127.0.0.1:49702 (1 connection now open)
2019-01-07T03:33:30.294-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49705 #24 (2 connections now open)
2019-01-07T03:33:30.309-0800 I NETWORK [conn24] received client metadata from 127.0.0.1:49705 conn24: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:33:30.401-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49706 #25 (3 connections now open)
2019-01-07T03:33:30.411-0800 I NETWORK [conn25] received client metadata from 127.0.0.1:49706 conn25: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:33:30.487-0800 I NETWORK [conn25] end connection 127.0.0.1:49706 (2 connections now open)
2019-01-07T03:33:30.505-0800 I NETWORK [conn24] end connection 127.0.0.1:49705 (1 connection now open)
2019-01-07T03:34:10.249-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49708 #26 (2 connections now open)
2019-01-07T03:34:10.290-0800 I NETWORK [conn26] received client metadata from 127.0.0.1:49708 conn26: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:34:10.348-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49709 #27 (3 connections now open)
2019-01-07T03:34:10.350-0800 I NETWORK [conn27] received client metadata from 127.0.0.1:49709 conn27: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:34:10.468-0800 I NETWORK [conn27] end connection 127.0.0.1:49709 (2 connections now open)
2019-01-07T03:34:10.470-0800 I NETWORK [conn26] end connection 127.0.0.1:49708 (1 connection now open)
2019-01-07T03:34:40.345-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49711 #28 (2 connections now open)
2019-01-07T03:34:40.378-0800 I NETWORK [conn28] received client metadata from 127.0.0.1:49711 conn28: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:34:40.433-0800 I NETWORK [listener] connection accepted from 127.0.0.1:49712 #29 (3 connections now open)
2019-01-07T03:34:40.436-0800 I NETWORK [conn29] received client metadata from 127.0.0.1:49712 conn29: { driver: { name: "mongo-java-driver", version: "3.6.3" }, os: { type: "Windo
ws", name: "Windows 8.1", architecture: "amd64", version: "6.3" }, platform: "Java/Oracle Corporation/1.8.0_192-b12" }
2019-01-07T03:34:42.807-0800 I NETWORK [conn28] end connection 127.0.0.1:49711 (2 connections now open)
2019-01-07T03:34:42.847-0800 I NETWORK [conn29] end connection 127.0.0.1:49712 (1 connection now open)

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

Here is the mongodb shell path and output i got

C:>cd C:\Program Files\MongoDB\Server\4.0\bin

C:\Program Files\MongoDB\Server\4.0\bin>mongo
MongoDB shell version v4.0.5
connecting to: mongodb://127.0.0.1:27017/?gssapiServiceName=mongodb
Implicit session: session { "id" : UUID("8df4e3b7-c9cb-404a-8505-6f26328e1924") }
MongoDB server version: 4.0.5
Server has startup warnings:
2019-01-07T02:47:54.388-0800 I CONTROL [initandlisten]
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten] ** WARNING: Access control is not enabled for the database.
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten] ** Read and write access to data and configuration is unrestricted.
2019-01-07T02:47:54.389-0800 I CONTROL [initandlisten]
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** WARNING: This server is bound to localhost.
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** Remote systems will be unable to connect to this server.
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** Start the server with --bind_ip to specify which IP
2019-01-07T02:47:54.390-0800 I CONTROL [initandlisten] ** addresses it should serve responses from, or with --bind_ip_all to
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten] ** bind to all interfaces. If this behavior is desired, start the
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten] ** server with --bind_ip 127.0.0.1 to disable this warning.
2019-01-07T02:47:54.391-0800 I CONTROL [initandlisten]

Enable MongoDB's free cloud-based monitoring service, which will then receive and display
metrics about your deployment (disk utilization, CPU, operation statistics, etc).

The monitoring data will be available on a MongoDB website with a unique URL accessible to you
and anyone you share the URL with. MongoDB may use this information to make product
improvements and to suggest MongoDB products and deployment options to you.

To enable free monitoring, run the following command: db.enableFreeMonitoring()
To permanently disable this reminder, run the following command: db.disableFreeMonitoring()

use ycsb
switched to db ycsb

@allanbank
Copy link
Collaborator

What about from the ycsb load?

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

you mean starting the server from ycsb or the path use
from the ycsb

@allanbank
Copy link
Collaborator

When you ran the 'ycsb load ...' there should have need some error output to the terminal. The code prints a message and/or stack trace when there is an insert failure.

@phemoski
Copy link
Author

phemoski commented Jan 7, 2019

yes there is, and this is the information that is printed

C:\YCSB-14\ycsb-0.14.0>C:\Python27\python.exe bin/ycsb load mongodb-async -s -P workloads/workloada > outputworkLoadALoad.txt
C:\Program Files\Java\jdk1.8.0_192\bin\java -cp C:\YCSB-14\ycsb-0.14.0\mongodb-binding\conf;C:\YCSB-14\ycsb-0.14.0\conf;C:\YCSB-14\ycsb-0.14.0\lib\core-0.14.0.jar;C:\YCSB-14\ycsb-0
.14.0\lib\HdrHistogram-2.1.4.jar;C:\YCSB-14\ycsb-0.14.0\lib\htrace-core4-4.1.0-incubating.jar;C:\YCSB-14\ycsb-0.14.0\lib\jackson-core-asl-1.9.4.jar;C:\YCSB-14\ycsb-0.14.0\lib\jacks
on-mapper-asl-1.9.4.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\logback-classic-1.1.2.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\logback-core-1.1.2.jar;C:\YCSB-14\ycsb-0.14.
0\mongodb-binding\lib\mongo-java-driver-3.6.3.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\mongodb-async-driver-2.0.1.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\mongodb-bindi
ng-0.14.0.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\slf4j-api-1.7.25.jar;C:\YCSB-14\ycsb-0.14.0\mongodb-binding\lib\snappy-java-1.1.7.1.jar com.yahoo.ycsb.Client -db com.yahoo
.ycsb.db.AsyncMongoDbClient -s -P workloads/workloada -load
Command line: -db com.yahoo.ycsb.db.AsyncMongoDbClient -s -P workloads/workloada -load
YCSB Client 0.14.0

Loading workload...
(might take a few minutes for large data sets)
Starting test.
2019-01-07 09:25:16:838 0 sec: 0 operations; est completion in 0 second
DBWrapper: report latency for each error is false and specific error codes to track for latency are: []
com.allanbank.mongodb.error.DuplicateKeyException: E11000 duplicate key error collection: ycsb.usertable index: id dup key: { : "user6284781860667377211" }
at com.allanbank.mongodb.util.FutureUtils.unwrap(FutureUtils.java:57)
at com.allanbank.mongodb.client.SynchronousMongoCollectionImpl.insert(SynchronousMongoCollectionImpl.java:687)
at com.allanbank.mongodb.client.SynchronousMongoCollectionImpl.insert(SynchronousMongoCollectionImpl.java:722)
at com.yahoo.ycsb.db.AsyncMongoDbClient.insert(AsyncMongoDbClient.java:272)
at com.yahoo.ycsb.DBWrapper.insert(DBWrapper.java:221)
at com.yahoo.ycsb.workloads.CoreWorkload.doInsert(CoreWorkload.java:562)
at com.yahoo.ycsb.ClientThread.run(Client.java:468)
at java.lang.Thread.run(Thread.java:748)
Error inserting, not retrying any more. number of attempts: 1Insertion Retry Limit: 0
2019-01-07 09:25:17:074 0 sec: 0 operations; est completion in 106751991167300 days 15 hours [CLEANUP: Count=1, Max=1899, Min=1899, Avg=1899, 90=1899, 99=1899, 99.9=1899, 99.99=189
9] [INSERT: Count=0, Max=0, Min=9223372036854775807, Avg=?, 90=0, 99=0, 99.9=0, 99.99=0] [INSERT-FAILED: Count=1, Max=96767, Min=96704, Avg=96736, 90=96767, 99=96767, 99.9=96767, 9
9.99=96767]

C:\YCSB-14\ycsb-0.14.0>

@allanbank
Copy link
Collaborator

You are getting a duplicate key exception. That means that the collection has some other data in it. You should be able to clean it up by connection via the MongoDB shell and then running the following commands (in the MongoDB Shell):

use ycsb
db.usertable.remove({})

Try running the load again once the remove completes.

@phemoski
Copy link
Author

phemoski commented Jan 8, 2019

Thanks it work, you are a saving grace, I appreciate so much.

@allanbank
Copy link
Collaborator

No problem. I'm glad we finally figure it out.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants