Image

Imagesagot_uk wrote in Imageru_java

Categories:

Solr/Lucene, synchronized, OSX

Добрый вечер.

Надеюсь, уважаемое сообщество поможет разгадать загадку.

Есть Solr, в котором сконфигуриван SearchHandler со стандартным QueryComponent'ом. Ничего необычного.
На это приложение подаётся нагрузка JMeter'ом. И вот тут начинаются странности.

Если приложение запущено на моём MBP c OSX 10.8.3, Java 1.6.0_35, то JMeter показывает 150 QPS.

Если приложение запущено на боксе с Debian, Java 1.6.0_32, JMeter показывает 750 QPS.

Если приложение запущено в VirtualBox'е (под OSX) с Debian, Java 1.6.0_20, JMeter показывает 300 QPS.

Профайлер говорит, что под OSX приложение утыкается в вызов этого метода:
class SegmentCoreReaders {
  synchronized TermInfosReader getTermsReader() {
    if (tis != null) {
      return tis;
    } else {
      return tisNoIndex;
    }
  }
}


Возникает предположение, что synchronized в OSX работает в несколько раз медленнее, чем в Linux'е.
К сожалению, Гугл не смог рассказать, в чём дело.
Надеюсь, уважаемое сообщество мне поможет :-)

Спасибо!


Характеристика MBP:
Intel Core i7-2860QM @ 2.50GHz
Model Name: MacBook Pro
Model Identifier: MacBookPro8,2
Processor Name: Intel Core i7
Processor Speed: 2.5 GHz
Number of Processors: 1
Total Number of Cores: 4
L2 Cache (per Core): 256 KB
L3 Cache: 8 MB
Memory: 16 GB
Boot ROM Version: MBP81.0047.B27
SMC Version (system): 1.69f4

Характеристика Debian бокса:
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
CPU(s): 4
Thread(s) per core: 1
Core(s) per socket: 4
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Stepping: 7
CPU MHz: 1600.000
Virtualization: VT-x
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 6144K
Memory: 16 GB

Характеристика Debian виртуалки:
Intel Core i5-2400 @ 3.10GHz
Architecture: x86_64
CPU op-mode(s): 64-bit
CPU(s): 4
Thread(s) per core: 1
Core(s) per socket: 4
CPU socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 42
Stepping: 7
CPU MHz: 2511.846
L1d cache: 32K
L1d cache: 32K
L2d cache: 6144K
Memory: 8 GB


Update: добавил модели CPU, а так же скриншоты потоков из JVisualVM для OSX, VM и Debian бокса.


OSX:
Image

Debian VM:
Image

Debian box:
Image


Update 2: провёл "чистое" тестирование - когда на MBP не запущено ничего, кроме тестируемого приложения. JMeter был запущен на другом компьютере, сеть - 1Гб Ethernet. Одновременно смотрел top'ом нагрузку на процессор.
Результаты:
1. 706 QPS, CPU usage: 86.68% user, 9.76% sys, 3.55% idle;
2. 508 QPS, CPU usage: 87.42% user, 11.53% sys, 1.3% idle;
3. 426 QPS, CPU usage: 86.85% user, 11.23% sys, 1.91% idle;

Приложение не перезапускалось. До этого так же провёл несколько тестов, но не смотрел CPU. Получилось 464, 324, 422, 395, 542 - делаю вывод, что в регрессии QPS JMeter не виноват.

Пока вывод только один: всегда замерять производительность (даже микробенчмарками) и искать hotspot'ы только на специально выделенной для этих целей железной машине.

LJ Video