Closed jr314159 closed 9 years ago
Hi,
It does always try to evenly balance the keyspace, so this is not what we'd expect to see. Can you please run the following command to generate the ScalingClient report for this stream, and paste it back into this issue?
java -cp target/KinesisScalingUtils.jar-complete.jar -Dstream-name=<stream name> -Dregion=<region name> -Dscaling-action=report ScalingClient
Thanks,
Ian
Shard shardId-000000000881 - Start: 0, End: 24305883360235455442838331915739612791, Keyspace Width: 24305883360235455442838331915739612791 (7%) Shard shardId-000000000884 - Start: 24305883360235455442838331915739612792, End: 48611766697147529041415588084174029605, Keyspace Width: 24305883336912073598577256168434416813 (7%) Shard shardId-000000000887 - Start: 48611766697147529041415588084174029606, End: 72917650050263527726213560516824835796, Keyspace Width: 24305883353115998684797972432650806190 (7%) Shard shardId-000000000890 - Start: 72917650050263527726213560516824835797, End: 97223533390416380489178248897960958917, Keyspace Width: 24305883340152852762964688381136123120 (7%) Shard shardId-000000000894 - Start: 97223533390416380489178248897960958918, End: 121529416757035643727222635693274104944, Keyspace Width: 24305883366619263238044386795313146026 (7%) Shard shardId-000000000897 - Start: 121529416757035643727222635693274104945, End: 145835300102049674424392379258801301030, Keyspace Width: 24305883345014030697169743565527196085 (7%) Shard shardId-000000000900 - Start: 145835300102049674424392379258801301031, End: 170141183450304490751314526534861009228, Keyspace Width: 24305883348254816326922147276059708197 (7%) Shard shardId-000000000903 - Start: 170141183450304490751314526534861009229, End: 194447066811106967209212391235731229719, Keyspace Width: 24305883360802476457897864700870220490 (7%) Shard shardId-000000000906 - Start: 194447066811106967209212391235731229720, End: 218752950167879235613208499400926401491, Keyspace Width: 24305883356772268403996108165195171771 (7%) Shard shardId-000000000910 - Start: 218752950167879235613208499400926401492, End: 243058833536118888773728969223528864132, Keyspace Width: 24305883368239653160520469822602462640 (7%) Shard shardId-000000000909 - Start: 243058833536118888773728969223528864133, End: 260215927711226584039780879896832127821, Keyspace Width: 17157094175107695266051910673303263688 (5%) Shard shardId-000000000911 - Start: 260215927711226584039780879896832127822, End: 267364716887074354948759097083674869129, Keyspace Width: 7148789175847770908978217186842741307 (2%) Shard shardId-000000000912 - Start: 267364716887074354948759097083674869130, End: 280232537532583562635223583154768590785, Keyspace Width: 12867820645509207686464486071093721655 (4%) Shard shardId-000000000874 - Start: 280232537532583562635223583154768590786, End: 300249147351239883522035629954940250949, Keyspace Width: 20016609818656320886812046800171660163 (6%) Shard shardId-000000000877 - Start: 300249147351239883522035629954940250950, End: 320265757169356079890549598711728836438, Keyspace Width: 20016609818116196368513968756788585488 (6%) Shard shardId-000000000878 - Start: 320265757169356079890549598711728836439, End: 340282366920938463463374607431768211455, Keyspace Width: 20016609751582383572825008720039375016 (6%)
Thanks for that. Interesting, and I can't reproduce why this keyspace would be unevenly divided for only a small portion.
I would advise one of two options:
java -cp target/KinesisScalingUtils.jar-complete.jar -Dstream-name=<your stream name> -Dregion=<your stream region> -Dscaling-action=resize -Dcount=16 ScalingClient
Please note that this will retire a large number of shards and create new ones, which is something that will affect the runtime of all your Kinesis applications, and something that you should extensively test in a safe environment before running.
I would really recommend that you select option 1, as it will cause much less impact on your applications and is much less invasive, and the level of inbalance in the stream is not likely to cause an issue.
Furthermore, unless you are seeing issues, you absolutely can leave the stream as it is - the only impact you have today is that shardId-000000000911 has 3x more capacity than your smaller shards.
Hmm, it looks like our application must have crashed a while ago. We have it running under Elastic Beanstalk and I suppose haven't set up proper application monitoring. I rebooted the app, and it promptly scaled down to 13 evenly distributed shards. I suppose if the application crashed in the middle of a scaling action, that could account for why our shards were left in this unbalanced state. Thanks for the help!
We've been using this application to manage our stream, and I discovered that the hash key distributions for each shard are uneven:
I did a little math and found that some shards have a range of 24305883360235455442838331915739612791 values, while the smallest shard only takes a range of 7148789175847770908978217186842741307 values.
This is causing data to be distributed unevenly across the shards, and our consumer application takes much longer to keep up to real time on the larger shards.
Here is our config:
I'm not sure how the scaling operation works. Does it try to size shards evenly? I'm concerned this may be causing us production issues.