Hi,
thank you for the hints.
On 3 January 2013 05:55, Mark Miller <markrmil...@gmail.com> wrote:
32 cores eh? You probably have to raise some limits to take advantage of
that.
32 cores isn't that much anymore. You can buy amd servers from
Supermicro with two sockets and 32G of ram for less than 2500$. Systems
with four sockets (64Cores) aren't unaffordable too.
Having some more money, one can think about the four socket Oracle T4-4
System (4 * 8cores * 8vcores = 256)
You might always want to experiment with using more merge threads? I
think the default may be 3.
I will try this. But i think otis is right. It's rather SOLR-3929 than
SOLR-4078.
Mark wanted to point this other issue:
https://issues.apache.org/jira/browse/SOLR-3929 though, so try that...
Am 03.01.2013 05:20, schrieb Otis Gospodnetic:>
I, too, was going to point out to the number of threads, but was going to
suggest using fewer of them because the server has 32 cores and there was a
mention of 100 threads being used from the client. Thus, my guess was that
the machine is busy juggling threads and context switching (how's vmstat 2
output, Uwe?) instead of doing the real work.
"use more threads" vs. "use less threads"
It is a bit confusing. I made some test with 50 to 200 threads. within
this range I noticed no real difference. 50 threads on the client seems
to trigger enough threads on the server to saturate the bottleneck. 200
client threads seems not to be destructive.
"vmstat 5" on the Server with 100 threads on the client
kthr memory page disk faults cpu
r b w swap free re mf pi po fr de sr cd cd s0 s4 in sy cs us sy id
0 0 0 13605380 17791928 0 7 0 0 0 0 0 0 0 0 0 3791 1638 1666 26 0 73
1 0 0 13641072 17826368 0 8 0 0 0 0 0 0 0 0 0 3540 1305 1527 25 0 74
0 0 0 13691908 17876364 0 8 0 0 0 0 0 0 0 0 48 3935 1453 1919 26 0 73
0 0 0 13720208 17904652 0 4 0 0 0 0 0 0 0 0 0 3964 1342 1645 25 0 74
0 0 0 13792440 17976868 0 9 0 0 0 0 0 0 0 0 0 3891 1551 1757 26 0 74
1 0 0 13867128 18051532 0 4 0 0 0 0 0 0 0 0 0 3871 1430 1584 26 0 74
1 0 0 13948796 18133184 0 6 0 0 0 0 0 0 0 0 0 3079 1218 1435 25 0 74
To see whats going on I prefer "mpstat 10" (100 client threads)
CPU minf mjf xcal intr ithr csw icsw migr smtx srw syscl usr sys wt idl
0 0 0 2 1389 1149 55 6 15 8 0 173 62 4 0 34
1 0 0 5 230 2 341 5 34 15 0 24 16 1 0 83
2 0 0 0 653 612 48 6 5 18 0 222 68 5 0 27
3 0 0 1 31 1 38 1 7 7 0 21 13 1 0 87
4 0 0 8 39 2 45 2 6 6 0 38 17 1 0 82
5 0 0 6 76 3 84 4 18 14 0 51 35 2 0 64
6 0 0 4 30 0 40 4 6 7 0 59 32 1 0 67
7 0 0 1 36 0 53 3 6 12 0 65 34 1 0 65
8 0 0 4 107 4 91 3 31 4 0 25 19 0 0 80
9 0 0 4 70 4 66 3 17 10 0 38 27 1 0 72
10 0 0 1 58 2 56 4 13 8 0 47 34 1 0 65
11 0 0 1 36 3 46 2 5 13 0 20 14 0 0 86
12 0 0 0 32 2 37 3 5 8 0 30 20 0 0 80
13 0 0 1 40 2 48 3 7 9 0 37 25 1 0 74
14 0 0 2 77 3 85 4 18 16 0 42 35 1 0 64
15 0 0 2 29 4 27 2 6 3 0 23 15 0 0 85
16 0 0 3 110 2 100 2 33 8 0 24 14 1 0 85
17 0 0 3 66 2 69 3 17 9 0 40 27 1 0 72
18 0 0 1 42 1 54 4 9 11 0 58 32 1 0 67
19 0 0 1 54 1 60 1 13 11 0 16 7 0 0 93
20 0 0 0 26 0 39 1 3 11 0 22 9 0 0 91
21 0 0 0 33 0 46 3 6 11 0 50 30 1 0 69
22 0 0 3 38 1 44 4 8 12 0 50 33 1 0 66
23 0 0 3 60 1 61 2 15 8 0 29 18 0 0 82
24 0 0 4 102 2 92 3 31 10 0 95 31 1 0 68
25 0 0 2 75 1 76 4 21 10 0 47 36 1 0 63
26 0 0 1 68 1 81 5 19 18 0 69 47 1 0 52
27 0 0 1 40 1 52 3 10 14 0 25 22 1 0 77
28 0 0 0 35 0 38 3 9 6 0 34 24 0 0 76
29 0 0 1 31 0 46 4 7 13 0 44 31 1 0 68
30 0 0 0 32 0 48 4 8 13 0 47 37 1 0 62
31 0 0 0 26 0 36 3 7 10 0 50 32 1 0 67
No minor fails, no major fails, low crosscalls, reasonable interrupts,
only some migrations... This seems for me quite good. Do you see a pitfall?
The advice "divide and conquer" from Gora, is probably the most
sensible. But it isn't cool, or? ;-)
Uwe
