В приборной панели SonarQube, задание вопросов длительное время

Question

ПРИМЕЧАНИЕ: Это было опубликовано первоначально в списке рассылки пользователей SonarQube, который теперь отключен, поэтому перемещая его сюда.

У меня есть SonarQube 5.0.1 установка. Пользователю требуется много времени, чтобы отредактировать проблему с веб-панели (например, назначить проблему), даже если нет заданий анализа. Я включил ведение журнала сервера на «FULL» и заметил, что основное время потреблялось, как показано ниже, между вставкой записи в issue_changes и следующим выбором вопроса о проблемах. Кажется, что ожидания и опрос для некоторых уведомлений.

Вот записи журнала:

2015.05.28 14:18:02 INFO http-bio-0.0.0.0-9000-exec-2 web[sql] 15ms Executed SQL: update issues set action_plan_key=?, severity=?, manual_severity=?, ... 
2015.05.28 14:18:02 INFO http-bio-0.0.0.0-9000-exec-2 web[sql] 0ms Executed SQL: INSERT INTO issue_changes (kee, issue_key, user_login, change_type, change_data, ... 
2015.05.28 14:18:38 INFO pool-5-thread-1 web[sql] 0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1> 
2015.05.28 14:19:38 INFO pool-5-thread-1 web[sql] 0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1> 
2015.05.28 14:20:38 INFO pool-5-thread-1 web[sql] 0ms Executed SQL: select id, data from notifications order by id asc limit ? - parameters are: <1> 
2015.05.28 14:20:53 INFO pool-2-thread-3 web[sql] 171370ms Executed SQL: select i.kee,root.uuid,i.updated_at,i.action_plan_key,i.assignee,i.effort_to_fix,i.issue_attributes,... 
2015.05.28 14:20:53 INFO pool-2-thread-3 web[bulk] 15ms ES bulk request for [Action 'UpdateRequest' for key '9b985185-349f-48a8-9762-21ec952c66ea' on index 'issues' on type 'issue'], 
2015.05.28 14:20:53 INFO pool-2-thread-3 web[refresh] 63ms ES refresh request on indices 'issues' 
2015.05.28 14:20:53 INFO http-bio-0.0.0.0-9000-exec-2 web[get] 0ms ES get request for key 'intellijinspection:ConstantConditions' on index 'rules' on type 'rule' 

Дополнительная информация Объем: У меня есть около 17 проектов, каждый из которых имеет 22 модулей, в общей сложности 3М строк кода каждого и 200K вопросов каждый.

UPDATE:

Так после некоторого копаться в коде, я понимаю, что следующий вызывается, когда пользователь редактирует сохранить, и это приводит к тому, индексирование быть сделано на месте. Следовательно, время, затрачиваемое на запрос запроса select выше, как итерация и индексирование происходит по его результирующему набору.

ServerIssueStorage { 

    .... 

    @Override 
    protected void doAfterSave() { 
     indexer.index(); 
    } 

} 

Я думаю, это одна из причин, почему SQ предостережений команды обновиться до 5. * версии, если у вас есть и проблема подсчет> 5M.

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

Answer 1

Действительно, в версии 5.0 на общие характеристики может влиять количество параллельных анализов (например, непрерывный контроль, запланированный для нескольких подчиненных работорговлей). Это ограничение было улучшено в 5.1, и усилия продолжаются в 5.2.