For larger indices, I'm seeing a pattern where my primary shards are significantly larger than replicas. For example, using the _cat/shards API, I'm getting:
524183765326406aba73345d470e727c-2018-07-30 0 p STARTED 9917382 19.9gb 10.4.0.252 prod-es-data-hot-03e9547ee64f9d19c
524183765326406aba73345d470e727c-2018-07-30 0 r STARTED 9917269 6.6gb 10.4.2.167 prod-es-data-hot-022b8be4866a004c4
524183765326406aba73345d470e727c-2018-07-30 1 p STARTED 9906022 20.5gb 10.4.1.197 prod-es-data-hot-07491395f0bb84af5
524183765326406aba73345d470e727c-2018-07-30 1 r STARTED 9905929 6.5gb 10.4.2.207 prod-es-data-hot-08454b4b222c130ef
524183765326406aba73345d470e727c-2018-07-30 2 p STARTED 9911138 18.5gb 10.4.1.217 prod-es-data-hot-0226703b13afd4fe1
524183765326406aba73345d470e727c-2018-07-30 2 r STARTED 9910932 6.5gb 10.4.0.14 prod-es-data-hot-0c78098bc764541e3
524183765326406aba73345d470e727c-2018-07-30 3 p STARTED 9908133 20.2gb 10.4.0.34 prod-es-data-hot-07f6b364df3787667
524183765326406aba73345d470e727c-2018-07-30 3 r STARTED 9907897 6.6gb 10.4.2.251 prod-es-data-hot-0e9476b7710e99538
524183765326406aba73345d470e727c-2018-07-30 4 p STARTED 9907219 19.5gb 10.4.2.220 prod-es-data-hot-08fb8c2ded8c64e3c
524183765326406aba73345d470e727c-2018-07-30 4 r STARTED 9907181 6.6gb 10.4.1.253 prod-es-data-hot-0d8aff97c8ff29904
524183765326406aba73345d470e727c-2018-07-30 5 p STARTED 9905674 20.1gb 10.4.0.80 prod-es-data-hot-0812c487071e9446f
524183765326406aba73345d470e727c-2018-07-30 5 r STARTED 9905482 6.6gb 10.4.1.218 prod-es-data-hot-055876f71221351ec
Given prior usage, I expect each shard to be roughly 6-8 GB, which my replicas are. However, my primaries are three times this size! Is this expected? Is there anything I can do, short of setting the index to RO and doing a force-merge? Having wildly differently sized shards is complicating my efforts to balance disk and CPU usage across my cluster.
I'm currently using ES 6.2.4.