Make some stores go on threads other than just 0 through 3.

[srh]

Right now all stores use four hash shards that are put on threads 0 through 3. Doing better than that is very low-hanging fruit.

[srh]

Oh, and this is really the problem behind #1043. There might be some "clustering overhead" and we certainly don't just make there be 16 hash shards on a 32-thread machine, but mostly we have most work on cores 0 through 3 because that's where all the stores are.

The serializers are possibly all on the same thread too.

[srh]

Oh and you can see the code for this at file_based_svs_by_namespace.cc.

[mlucy]

Assigning to myself.

[mlucy]

In review 943 by @srh.

Also, get_svs doesn't seem to be called when you reshard a table. We have 4 hash shards per range shard even when there are multiple range shards on the same machine, right? I think I'm missing something here.

With the changes in review 943, the insert benchmark I mentioned in #1369 still doesn't perform any better with 4 shards than with 1.

[srh]

Regarding the get_svs question, shards share the same btrees. This is because when you want to reshard, at least the way things work right now, you need to be able to have multiple shards on the same btree before combining them.

[mlucy]

If I understand correctly, this means that oversharding doesn't actually help with CPU utilization, right?

[srh]

That's right.

[jdoliner]

It's not supposed to help with CPU utilization either.

On Tue, Sep 17, 2013 at 3:23 AM, srh notifications@github.com wrote:

That's right.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/1446#issuecomment-24577624
.

[mlucy]

This is in next.