lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Uwe Reh <...@hebis.uni-frankfurt.de>
Subject Re: indexing cpu utilization
Date Thu, 03 Jan 2013 10:40:33 GMT
Hi,
thank you for the hints.

>> On 3 January 2013 05:55, Mark Miller <markrmiller@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

Mime
View raw message