G1 мусор с одним замедленным рабочим

Question

У меня проблема с GC-паузой (~ 400 мс), которую я пытаюсь уменьшить. Я заметил, что у меня всегда есть один работник намного медленнее, чем другие:

2013-06-03T17:24:51.606+0200: 605364.503: [GC pause (mixed) 
Desired survivor size 109051904 bytes, new threshold 1 (max 1) 
- age 1: 47105856 bytes, 47105856 total 
, 0.47251300 secs] 
[Parallel Time: 458.8 ms] 
    [GC Worker Start (ms): 605364503.9 605364503.9 605364503.9 605364503.9 605364503.9 605364504.0 
    Avg: 605364503.9, Min: 605364503.9, Max: 605364504.0, Diff: 0.1] 
--> [**Ext Root Scanning (ms)**: **356.4** 3.1 3.7 3.6 3.2 3.0 
    Avg: 62.2, **Min: 3.0, Max: 356.4, Diff: 353.4**] <--- 
    [Update RS (ms): 0.0 22.4 33.6 21.8 22.3 22.3 
    Avg: 20.4, Min: 0.0, 

Как вы можете видеть один работник принял 356 мс, когда другие потребовалось всего 3 мс !!!

Если кто-то имеет представление о том или думать, что это нормально ..

Answer 1

[Я бы предпочел опубликовать это как комментарий, но я до сих пор не хватает необходимых очков, чтобы сделать это]

Нет идеи относительно того, это нормально, но я столкнулся с той же проблемой:

2014-01-16T13:52:56.433+0100: 59577.871: [GC pause (young), 2.55099911 secs] 
    [Parallel Time: 2486.5 ms] 
     [GC Worker Start (ms): 59577871.3 59577871.4 59577871.4 59577871.4 59577871.4 59577871.5 59577871.5 59577871.5 
     Avg: 59577871.4, Min: 59577871.3, Max: 59577871.5, Diff: 0.2] 
     [Ext Root Scanning (ms): 152.0 164.5 159.0 183.7 1807.0 117.4 113.8 138.2 
     Avg: 354.5, Min: 113.8, Max: 1807.0, Diff: 1693.2] 

Я не смог найти много об этой теме, но здесь http://mail.openjdk.java.net/pipermail/hotspot-gc-use/2013-February/001484.html

В основном, как вы предполагаете, рабочие потоки GC удерживаются до при обработке одного корня. Я видел подобную проблему, вызвавшую , заполнив кеш кода (где хранятся JIT-скомпилированные методы). Кэш кода обрабатывается как один корень и поэтому заявляется в своем целиком одним рабочим потоком GC. Когда кеш кода заполняется, поток, который утверждает, что кеш кода для сканирования начинает задерживаться.

полный GC очищает вопрос, потому что, где G1 в настоящее время делает класс выгрузки: полный GC разгружает целую кучу классов, позволяющих любых скомпилированный кода любых из методов ненагруженных классов, чтобы быть освобожденной от nmethod уборочный. Таким образом, после полного GC количество скомпилированных методов в кеше кода меньше.

Это также может быть просто огромное количество загруженных классов, поскольку системный словарь также рассматривается как единственный искомый корень.

Я думаю, что попробую включить кеш-код для очистки и сообщить об этом. Если вам, наконец, удастся решить эту проблему, пожалуйста, дайте мне знать, я тоже хочу с этим справиться.

С уважением