Sonarqube 4.0 performance issue when querying Issues Drilldown

classic Classic list List threaded Threaded
21 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Hi

 

We have a performance issue when querying Issues Drilldown in Sonarqube 4.0.

 

We have the following database configuration:

-Oracle Database 10g (10.2.0.4.0)

-JDBC ojdbc6-11.2.0.4.0.jar (Oracle 11 JDBC driver)

 

We have the latest plugins version:

-Java 1.5

-SQALE 2.0

-Branding 0.4

 

We have 3 Java projects in SONAR database. Each of them have 120 modules.

 

When we select the Issues Drilldown for a project which has 455 issues, the Severity, Rule, Module, Packages, Files panes are displayed but the bottom issues board take about 5 minutes to be displayed.

The display time is too long for 455 issues.

 

After doing an analysis with YourKit Java Profiler, we found that the following SQL request take too much time to be executed:

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root_snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      INNER JOIN

        (SELECT p.id AS root_project_id

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

        ) authorized_projects ON authorized_projects.root_project_id = root_snapshot_components.project_id

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized_input_components.path

      || authorized_input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

We replay this request in SQL Developer, the response time is the same for displaying 455 lines.

 

The execution plan give that:

 

Can you tell us what’s wrong?

 

Best regards

 

Laurent

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Due to this long response time, we also have a time out error when retrieving remote issues with Eclipse plugin :

 

org.sonar.ide.eclipse.wsclient.SonarWSClientException: Error during issue query org.sonar.wsclient.issue.IssueQuery@6ee095d4

                at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.findIssues(SonarWSClientFacade.java:194)

                at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.getRemoteIssuesRecursively(SonarWSClientFacade.java:170)

                at org.sonar.ide.eclipse.core.internal.remote.RemoteSourceCode.getRemoteIssuesRecursively(RemoteSourceCode.java:122)

                at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.doRefreshIssues(SynchronizeAllIssuesJob.java:136)

                at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.fetchRemoteIssues(SynchronizeAllIssuesJob.java:125)

                at org.sonar.ide.eclipse.core.internal.jobs.SynchronizeAllIssuesJob.run(SynchronizeAllIssuesJob.java:79)

                at org.eclipse.core.internal.jobs.Worker.run(Worker.java:53)

Caused by: java.lang.IllegalStateException: Fail to request http://my.sonarinstance:9091/sonar/api/issues/search?pageSize=-1&componentRoots=com.myapp:myapp:Sqale&pageIndex=1

                at org.sonar.wsclient.internal.HttpRequestFactory.execute(HttpRequestFactory.java:138)

                at org.sonar.wsclient.internal.HttpRequestFactory.get(HttpRequestFactory.java:121)

                at org.sonar.wsclient.issue.internal.DefaultIssueClient.find(DefaultIssueClient.java:48)

                at org.sonar.ide.eclipse.wsclient.internal.SonarWSClientFacade.findIssues(SonarWSClientFacade.java:190)

                ... 6 more

Caused by: java.net.SocketTimeoutException: Read timed out

                at java.net.SocketInputStream.socketRead0(Native Method)

                at java.net.SocketInputStream.read(Unknown Source)

                at java.io.BufferedInputStream.fill(Unknown Source)

                at java.io.BufferedInputStream.read1(Unknown Source)

                at java.io.BufferedInputStream.read(Unknown Source)

                at sun.net.www.http.HttpClient.parseHTTPHeader(Unknown Source)

                at sun.net.www.http.HttpClient.parseHTTP(Unknown Source)

                at sun.net.www.protocol.http.HttpURLConnection.getInputStream(Unknown Source)

                at java.net.HttpURLConnection.getResponseCode(Unknown Source)

                at org.sonar.wsclient.kevinsawicki.HttpRequest.code(HttpRequest.java:1430)

 

It is always the same SQL request which take too much times to be executed. (There are only 450 issues to retrieve…)

 

What’s wrong?

 

Laurent

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Freddy Mallet
In reply to this post by Laurent TOURREAU-2
Hi Laurent, 

Could you execute the two following SQL requests and send back the results ?

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL


Thanks

Freddy


-----
SonarQube for Continuous Inspection


On Fri, Dec 20, 2013 at 12:58 PM, Laurent TOURREAU <[hidden email]> wrote:

Hi

 

We have a performance issue when querying Issues Drilldown in Sonarqube 4.0.

 

We have the following database configuration:

-Oracle Database 10g (10.2.0.4.0)

-JDBC ojdbc6-11.2.0.4.0.jar (Oracle 11 JDBC driver)

 

We have the latest plugins version:

-Java 1.5

-SQALE 2.0

-Branding 0.4

 

We have 3 Java projects in SONAR database. Each of them have 120 modules.

 

When we select the Issues Drilldown for a project which has 455 issues, the Severity, Rule, Module, Packages, Files panes are displayed but the bottom issues board take about 5 minutes to be displayed.

The display time is too long for 455 issues.

 

After doing an analysis with YourKit Java Profiler, we found that the following SQL request take too much time to be executed:

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root_snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      INNER JOIN

        (SELECT p.id AS root_project_id

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

        ) authorized_projects ON authorized_projects.root_project_id = root_snapshot_components.project_id

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized_input_components.path

      || authorized_input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

We replay this request in SQL Developer, the response time is the same for displaying 455 lines.

 

The execution plan give that:

 

Can you tell us what’s wrong?

 

Best regards

 

Laurent

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

george.ranjan
In reply to this post by Laurent TOURREAU-2
Not sure if this helps, but i struggled with a similar problem, although my setup was 3.7 & postgres 8.1.  It got resolved when I upgraded to postgres 9.1 and sonarqube 4.0

Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
In reply to this post by Freddy Mallet

Hello Freddy (Happy New Year)

 

The request :

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

give that results:

 

COUNT(*)

3

 

This request was very fast

 

What is the second request you mentionned?

 

@george-rajan

I have to use Oracle Database instead of Postgresql L

 

Regards

 

From: [hidden email] [mailto:[hidden email]]
Sent: lundi 30 décembre 2013 14:46
To: [hidden email]
Cc: Alexandre GIGLEUX
Subject: Re: [sonar-user] Sonarqube 4.0 performance issue when querying Issues Drilldown

 

Hi Laurent, 

 

Could you execute the two following SQL requests and send back the results ?

 

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

 

Thanks

Freddy


-----

SonarQube for Continuous Inspection

 

On Fri, Dec 20, 2013 at 12:58 PM, Laurent TOURREAU <[hidden email]> wrote:

Hi

 

We have a performance issue when querying Issues Drilldown in Sonarqube 4.0.

 

We have the following database configuration:

-Oracle Database 10g (10.2.0.4.0)

-JDBC ojdbc6-11.2.0.4.0.jar (Oracle 11 JDBC driver)

 

We have the latest plugins version:

-Java 1.5

-SQALE 2.0

-Branding 0.4

 

We have 3 Java projects in SONAR database. Each of them have 120 modules.

 

When we select the Issues Drilldown for a project which has 455 issues, the Severity, Rule, Module, Packages, Files panes are displayed but the bottom issues board take about 5 minutes to be displayed.

The display time is too long for 455 issues.

 

After doing an analysis with YourKit Java Profiler, we found that the following SQL request take too much time to be executed:

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root _snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      INNER JOIN

        (SELECT p.id AS root_project_id

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

        ) authorized_projects ON authorized_projects.root_project_id = root _snapshot_components.project_id

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized _input_components.path

      || authorized _input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

We replay this request in SQL Developer, the response time is the same for displaying 455 lines.

 

The execution plan give that:

 

Can you tell us what’s wrong?

 

Best regards

 

Laurent

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

 

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Freddy Mallet
Hello Laurent, 

There are some other users encountering some trouble with this "issues" table on Oracle, the main difficulty is to reproduce this performance hotspot because the way Oracle compute the execution plan vary from one environment to the other. 

To help me figuring out what happens could you confirm that the execution time of the following sql request is short and could you send me the relating execution plan ?  

Thanks

SELECT *
FROM
  (SELECT i.id
  FROM issues i
  INNER JOIN
    (SELECT s.project_id
    FROM snapshots s,
      (SELECT project_components.id         AS id,
        snapshot_components.id              AS sid,
        root_snapshot_components.project_id AS root_project_id,
        root_snapshot_components.id         AS root_snapshot_id,
        snapshot_components.path            AS path
      FROM projects project_components
      INNER JOIN snapshots snapshot_components
      ON snapshot_components.project_id = project_components.id
      AND snapshot_components.islast    = 1
      INNER JOIN snapshots root_snapshot_components
      ON root_snapshot_components.project_id = snapshot_components.root_project_id
      AND root_snapshot_components.islast    = 1
      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')
      AND project_components.enabled                                 = 1
      ) authorized_input_components
    WHERE s.root_project_id   = authorized_input_components.root_project_id
    AND s.islast              = 1
    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id
    AND s.path LIKE authorized_input_components.path
      || authorized_input_components.sid
      || '.%' )
    OR (s.id                                                 = authorized_input_components.sid) )
    ) authorizedComponents ON authorizedComponents.project_id=i.component_id
  WHERE i.resolution                                        IS NULL
  )
WHERE rownum <= 1609;

-----
SonarQube for Continuous Inspection


On Thu, Jan 2, 2014 at 12:08 PM, Laurent TOURREAU <[hidden email]> wrote:

Hello Freddy (Happy New Year)

 

The request :

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

give that results:

 

COUNT(*)

3

 

This request was very fast

 

What is the second request you mentionned?

 

@george-rajan

I have to use Oracle Database instead of Postgresql L

 

Regards

 

From: [hidden email] [mailto:[hidden email]]
Sent: lundi 30 décembre 2013 14:46
To: [hidden email]
Cc: Alexandre GIGLEUX
Subject: Re: [sonar-user] Sonarqube 4.0 performance issue when querying Issues Drilldown

 

Hi Laurent, 

 

Could you execute the two following SQL requests and send back the results ?

 

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

 

Thanks

Freddy


-----

SonarQube for Continuous Inspection

 

On Fri, Dec 20, 2013 at 12:58 PM, Laurent TOURREAU <[hidden email]> wrote:

Hi

 

We have a performance issue when querying Issues Drilldown in Sonarqube 4.0.

 

We have the following database configuration:

-Oracle Database 10g (10.2.0.4.0)

-JDBC ojdbc6-11.2.0.4.0.jar (Oracle 11 JDBC driver)

 

We have the latest plugins version:

-Java 1.5

-SQALE 2.0

-Branding 0.4

 

We have 3 Java projects in SONAR database. Each of them have 120 modules.

 

When we select the Issues Drilldown for a project which has 455 issues, the Severity, Rule, Module, Packages, Files panes are displayed but the bottom issues board take about 5 minutes to be displayed.

The display time is too long for 455 issues.

 

After doing an analysis with YourKit Java Profiler, we found that the following SQL request take too much time to be executed:

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root _snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      INNER JOIN

        (SELECT p.id AS root_project_id

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

        ) authorized_projects ON authorized_projects.root_project_id = root _snapshot_components.project_id

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized _input_components.path

      || authorized _input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

We replay this request in SQL Developer, the response time is the same for displaying 455 lines.

 

The execution plan give that:

 

Can you tell us what’s wrong?

 

Best regards

 

Laurent

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

 


Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Hello Freddy

 

The execution of this following request is very long (about 124 seconds to retrieve 450 lignes) :

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root_snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized_input_components.path

      || authorized_input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

The execution time of this following request is short (less than one second):

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

The result is:

COUNT(*)
3

The complete execution plan for the first request is the following:

 

 

If anything is missing tell me.

 

Regards

 

Laurent TOURREAU 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

José Gomez
Hello Laurent,

To investigate deeper, could you please tell me :
- what is your amount of data ? how many total SonarQube issues do you have in your database ? (<1 000 000, < 5 000 000, ...)
- did you migrate to SonarQube 4.0 ? In this case, from which SonarQube version ?

Thanks

Regards


José GOMEZ | SonarSource



On 3 January 2014 17:50, Laurent TOURREAU <[hidden email]> wrote:

Hello Freddy

 

The execution of this following request is very long (about 124 seconds to retrieve 450 lignes) :

 

SELECT *

FROM

  (SELECT i.id

  FROM issues i

  INNER JOIN

    (SELECT s.project_id

    FROM snapshots s,

      (SELECT project_components.id         AS id,

        snapshot_components.id              AS sid,

        root_snapshot_components.project_id AS root_project_id,

        root_snapshot_components.id         AS root_snapshot_id,

        snapshot_components.path            AS path

      FROM projects project_components

      INNER JOIN snapshots snapshot_components

      ON snapshot_components.project_id = project_components.id

      AND snapshot_components.islast    = 1

      INNER JOIN snapshots root_snapshot_components

      ON root_snapshot_components.project_id = snapshot_components.root_project_id

      AND root_snapshot_components.islast    = 1

      WHERE ( project_components.kee                                 ='com.mycompany:myapp:FindBugsBlockerCritical')

      AND project_components.enabled                                 = 1

      ) authorized_input_components

    WHERE s.root_project_id   = authorized_input_components.root_project_id

    AND s.islast              = 1

    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id

    AND s.path LIKE authorized_input_components.path

      || authorized_input_components.sid

      || '.%' )

    OR (s.id                                                 = authorized_input_components.sid) )

    ) authorizedComponents ON authorizedComponents.project_id=i.component_id

  WHERE i.resolution                                        IS NULL

  )

WHERE rownum <= 1609;

 

The execution time of this following request is short (less than one second):

SELECT count(*)

        FROM group_roles gr

        INNER JOIN projects p

        ON p.id                                                      = gr.resource_id

        AND p.scope                                                  = 'PRJ'

        AND p.qualifier                                              = 'TRK'

        WHERE gr.role                                                ='user'

        AND gr.group_id                                             IS NULL

The result is:

COUNT(*)
3

The complete execution plan for the first request is the following:

 

 

If anything is missing tell me.

 

Regards

 

Laurent TOURREAU 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Hello Jose

 

In our database we have:

-64694 lines for issues table

-16578 lines for projects table

-17150 lines for snapshots table

-8508 lines for group_roles table

 

We previously used SonarQube 3.7, and we preferred to start our analysis from a new baseline.

 

So we removed 3.7 installation and dropped all the tables and sequences in the database before installing SonarQube 4.0.

 

This morning, i have relaunched all db statistics calculation:

 

BEGIN

  FOR i IN

  (SELECT table_name FROM user_tables

  )

  LOOP

    dbms_stats.gather_table_stats(USER,i.table_name);

  END LOOP;

END;

 

The response time for displaying issues in issue bottom panel is better!

 

Maybe this problem was due to stats are not calculated after a analysis?

 

Regards

 

Laurent TOURREAU

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
In reply to this post by José Gomez

Hi

 

Today we face again the same problem drilldown performance problem although I ran the db stats sql routine:

 

BEGIN

  FOR i IN

  (SELECT table_name FROM user_tables

  )

  LOOP

    dbms_stats.gather_table_stats(USER,i.table_name);

  END LOOP;

END;

 

I tried this (which is supposed to be more reliable because it force the stats calculation for the indexes too):

BEGIN

    dbms_stats.gather_schema_stats(NULL,cascade=> true);

END;

 

The response time is always awful.

 

Laurent TOURREAU

 

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
In reply to this post by José Gomez

Freddy, Jose

 

Today we have done the test with Postgresql 9.3 database.

We don’t have such drilldown timeout problem with Postgres.

 

Here is the execution plan with Postresql:

 

Nested Loop  (cost=2.13..25.12 rows=1 width=4)

  Join Filter: (p.id = gr.resource_id)

  ->  Nested Loop  (cost=1.85..24.76 rows=1 width=20)

        Join Filter: ((p.id = root_snapshot_components.project_id) AND (((s.root_snapshot_id = root_snapshot_components.id) AND ((s.path)::text ~~ (((snapshot_components.path)::text || (snapshot_components.id)::text) || '.%'::text))) OR (s.id = snapshot_co (...)

        ->  Nested Loop  (cost=1.56..24.32 rows=1 width=54)

              ->  Nested Loop  (cost=1.27..23.14 rows=1 width=54)

                    Join Filter: (p.id = s.root_project_id)

                    ->  Nested Loop  (cost=0.99..17.21 rows=1 width=25)

                          ->  Nested Loop  (cost=0.70..16.75 rows=1 width=21)

                                ->  Index Scan using projects_kee on projects project_components  (cost=0.41..8.43 rows=1 width=4)

                                      Index Cond: ((kee)::text = 'com.myApp:myApp'::text)

                                      Filter: enabled

                                ->  Index Scan using snapshot_project_id on snapshots snapshot_components  (cost=0.29..8.31 rows=1 width=25)

                                      Index Cond: (project_id = project_components.id)

                                      Filter: islast

                          ->  Index Scan using projects_pkey on projects p  (cost=0.29..0.45 rows=1 width=4)

                                Index Cond: (id = snapshot_components.root_project_id)

                                Filter: (((scope)::text = 'PRJ'::text) AND ((qualifier)::text = 'TRK'::text))

                    ->  Index Scan using snapshots_root_project_id on snapshots s  (cost=0.29..3.81 rows=170 width=29)

                          Index Cond: (root_project_id = snapshot_components.root_project_id)

                          Filter: islast

              ->  Index Scan using issues_component_id on issues i  (cost=0.29..1.16 rows=2 width=8)

                    Index Cond: (component_id = s.project_id)

                    Filter: ((resolution IS NULL) AND ((severity)::text = 'CRITICAL'::text))

        ->  Index Scan using snapshot_project_id on snapshots root_snapshot_components  (cost=0.29..0.41 rows=1 width=8)

              Index Cond: (project_id = snapshot_components.root_project_id)

              Filter: islast

  ->  Index Scan using group_roles_resource on group_roles gr  (cost=0.28..0.35 rows=1 width=4)

        Index Cond: (resource_id = root_snapshot_components.project_id)

        Filter: ((group_id IS NULL) AND ((role)::text = 'user'::text))

 

Its du to Oracle 10g which hang when executing the request?

I will send you by mail the complete execution plan for Oracle as its not viewable through the forum.

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

RE: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
In reply to this post by José Gomez

Hi Jose, Freddy

 

Today we have upgraded our database from Oracle 10g to 11g. The performances are incredibly better!

 

The execution plan is completely different between Oracle 10g and 11g:

 

11g:

 

 

10g:

 

We have also tested the SonarQube Eclipse Plugin. The analysis command now respond correctly.

 

I think we can conclude that SonarQube should be used on Oracle 11g rather than Oracle 10g.

 

Regards

 

Laurent TOURREAU

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Freddy Mallet
Thanks for this notification Laurent !!!!

-----
SonarQube for Continuous Inspection


On Wed, Jan 29, 2014 at 10:20 AM, Laurent TOURREAU <[hidden email]> wrote:

Hi Jose, Freddy

 

Today we have upgraded our database from Oracle 10g to 11g. The performances are incredibly better!

 

The execution plan is completely different between Oracle 10g and 11g:

 

11g:

 

 

10g:

 

We have also tested the SonarQube Eclipse Plugin. The analysis command now respond correctly.

 

I think we can conclude that SonarQube should be used on Oracle 11g rather than Oracle 10g.

 

Regards

 

Laurent TOURREAU

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


Reply | Threaded
Open this post in threaded view
|

Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Hi Freddy, Jose

 

Unfortunately the issue came back in Oracle 11g.

 

The execution plan has changed recently (I didn’t tune anything in Oracle database) :

 

Here are my observations :

 

-The issue drilldown request take longer time to be displayed on Internet Explorer 9.

-The same request is fast when displayed in Chrome v32.

-The response time is completely degraded when doing a Analysis with Sonarqube Eclipse plugin, but no time out occurred at this stage.

 

Do you have any clue about what happened?

 

Regards

 

Laurent TOURREAU

 

 

 

This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

tlueecke
Not sure if that helps, but we were facing the same problem with this query, going even so far that it did not return. After much monitoring we found out that the Oracle DB was performing background tasks all the time, which somehow led to this strange behaviour.

We now scheduled the sql tuning advisor job to run only on the weekend, and since then we had a good and stable performance on this query. We found the problem by enabling the SQL monitoring feature on Oracle as described here:

http://www.oracle-base.com/articles/11g/real-time-sql-monitoring-11gr1.php

The SQL monitoring report showed, that most of the time was spent on the resmgr:cpu quantum activity, which seems - after a little research - to be related to the background jobs. So creating such a report for your query might be helpful in finding out what the problem is.

Brgds,
Tim
Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
Hi Sonarqube Team

We are still fighting against that performance problem.

We have discovered we don't have this issue when we are login into SonarQube. It seems that the SQL statement (for the same result) is not the same:

SELECT i.id
  FROM issues i
  INNER JOIN
    (SELECT s.project_id
    FROM snapshots s,
      (SELECT project_components.id         AS id,
        snapshot_components.id              AS sid,
        root_snapshot_components.project_id AS root_project_id,
        root_snapshot_components.id         AS root_snapshot_id,
        snapshot_components.path            AS path
      FROM projects project_components
      INNER JOIN snapshots snapshot_components
      ON snapshot_components.project_id = project_components.id
      AND snapshot_components.islast    = 1
      INNER JOIN snapshots root_snapshot_components
      ON root_snapshot_components.project_id = snapshot_components.root_project_id
      AND root_snapshot_components.islast    = 1
      INNER JOIN projects root_project
      ON root_project.id=root_snapshot_components.project_id
      INNER JOIN
        (SELECT p.kee AS root_project_kee
        FROM group_roles gr
        INNER JOIN projects p
        ON p.id           = gr.resource_id
        AND p.scope       = 'PRJ'
        AND p.qualifier   = 'TRK'
        WHERE gr.role     = 'user'
        AND (gr.group_id IS NULL
        OR gr.group_id   IN
          (SELECT gu.group_id FROM groups_users gu WHERE gu.user_id=10000
          ))
        UNION
        SELECT p.kee AS root_project_kee
        FROM user_roles ur
        INNER JOIN projects p
        ON p.id                                                       = ur.resource_id
        AND p.scope                                                   = 'PRJ'
        AND p.qualifier                                               = 'TRK'
        WHERE ur.role                                                 = null
        AND ur.user_id                                                = 10000
        ) authorized_projects ON authorized_projects.root_project_kee = root_project.kee
      WHERE ( project_components.kee                                  ='com.myApp:myApp')
      AND project_components.enabled                                  = 1
      ) authorized_input_components
    WHERE s.root_project_id   = authorized_input_components.root_project_id
    AND s.islast              = 1
    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id
    AND s.path LIKE authorized_input_components.path
      || authorized_input_components.sid
      || '.%' )
    OR (s.id                                                 = authorized_input_components.sid) )
    ) authorizedComponents ON authorizedComponents.project_id=i.component_id
  WHERE i.resolution                                        IS NULL
  )
WHERE rownum <= 15000

The performance are better.
Here is the plan:

1 SELECT STATEMENT  
         COUNT STOPKEY
1  NESTED LOOPS  
5   NESTED LOOPS  
1    NESTED LOOPS  
1     NESTED LOOPS  
2      NESTED LOOPS  
2       NESTED LOOPS  
2        NESTED LOOPS  
2         VIEW  
2          SORT UNIQUE
                   UNION-ALL  
                    FILTER  
1             NESTED LOOPS  
363              NESTED LOOPS  
363               TABLE ACCESS BY INDEX ROWID GROUP_ROLES
363                INDEX RANGE SCAN GROUP_ROLES_ROLE
1               INDEX UNIQUE SCAN SYS_C003794
1              TABLE ACCESS BY INDEX ROWID PROJECTS
1             INDEX UNIQUE SCAN GROUPS_USERS_UNIQUE
                    FILTER  
1             NESTED LOOPS  
1              NESTED LOOPS  
1               TABLE ACCESS BY INDEX ROWID USER_ROLES
1                INDEX RANGE SCAN USER_ROLES_USER
1               INDEX UNIQUE SCAN SYS_C003794
1              TABLE ACCESS BY INDEX ROWID PROJECTS
1         TABLE ACCESS BY INDEX ROWID PROJECTS
1          INDEX RANGE SCAN PROJECTS_KEE
1        TABLE ACCESS BY INDEX ROWID SNAPSHOTS
1         INDEX RANGE SCAN SNAPSHOT_PROJECT_ID
1       TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72        INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
1      TABLE ACCESS BY INDEX ROWID PROJECTS
1       INDEX UNIQUE SCAN SYS_C003794
1     TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72      INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
5    INDEX RANGE SCAN ISSUES_COMPONENT_ID
1   TABLE ACCESS BY INDEX ROWID ISSUES

For comparison, the plan when we are not logged is that:
1 SELECT STATEMENT  
         COUNT STOPKEY
1  NESTED LOOPS  
4   NESTED LOOPS  
1    NESTED LOOPS  
1     NESTED LOOPS  
1      NESTED LOOPS  
1       NESTED LOOPS  
2        HASH JOIN  
16422         TABLE ACCESS FULL SNAPSHOTS
19893         MERGE JOIN  
16422          TABLE ACCESS BY INDEX ROWID SNAPSHOTS
23802           INDEX FULL SCAN SNAPSHOTS_ROOT_PROJECT_ID
16422          SORT JOIN
16422           TABLE ACCESS FULL SNAPSHOTS
1        TABLE ACCESS BY INDEX ROWID PROJECTS
1         INDEX UNIQUE SCAN SYS_C003794
1       TABLE ACCESS BY INDEX ROWID ISSUES
5        INDEX RANGE SCAN ISSUES_COMPONENT_ID
1      TABLE ACCESS BY INDEX ROWID PROJECTS
1       INDEX UNIQUE SCAN SYS_C003794
1     TABLE ACCESS BY INDEX ROWID PROJECTS
1      INDEX RANGE SCAN PROJECTS_KEE
4    INDEX RANGE SCAN GROUP_ROLES_RESOURCE
1   TABLE ACCESS BY INDEX ROWID GROUP_ROLES

Is it possible to implement the same request when the user is not logged into it?

@ tlueecke
We are going to ask to our DBAs to manage the faulty request using Oracle SQL Plan Management.

Cordialement / Best regards

Laurent TOURREAU




This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

José Gomez
Hi Laurent,

We have discovered we don't have this issue when we are login into SonarQube

What do you mean ? All previous email were while not logged in SonarQube ?

Regards

José GOMEZ | SonarSource



On 14 February 2014 16:35, Laurent TOURREAU <[hidden email]> wrote:
Hi Sonarqube Team

We are still fighting against that performance problem.

We have discovered we don't have this issue when we are login into SonarQube. It seems that the SQL statement (for the same result) is not the same:

SELECT i.id
  FROM issues i
  INNER JOIN
    (SELECT s.project_id
    FROM snapshots s,
      (SELECT project_components.id         AS id,
        snapshot_components.id              AS sid,
        root_snapshot_components.project_id AS root_project_id,
        root_snapshot_components.id         AS root_snapshot_id,
        snapshot_components.path            AS path
      FROM projects project_components
      INNER JOIN snapshots snapshot_components
      ON snapshot_components.project_id = project_components.id
      AND snapshot_components.islast    = 1
      INNER JOIN snapshots root_snapshot_components
      ON root_snapshot_components.project_id = snapshot_components.root_project_id
      AND root_snapshot_components.islast    = 1
      INNER JOIN projects root_project
      ON root_project.id=root_snapshot_components.project_id
      INNER JOIN
        (SELECT p.kee AS root_project_kee
        FROM group_roles gr
        INNER JOIN projects p
        ON p.id           = gr.resource_id
        AND p.scope       = 'PRJ'
        AND p.qualifier   = 'TRK'
        WHERE gr.role     = 'user'
        AND (gr.group_id IS NULL
        OR gr.group_id   IN
          (SELECT gu.group_id FROM groups_users gu WHERE gu.user_id=10000
          ))
        UNION
        SELECT p.kee AS root_project_kee
        FROM user_roles ur
        INNER JOIN projects p
        ON p.id                                                       = ur.resource_id
        AND p.scope                                                   = 'PRJ'
        AND p.qualifier                                               = 'TRK'
        WHERE ur.role                                                 = null
        AND ur.user_id                                                = 10000
        ) authorized_projects ON authorized_projects.root_project_kee = root_project.kee
      WHERE ( project_components.kee                                  ='com.myApp:myApp')
      AND project_components.enabled                                  = 1
      ) authorized_input_components
    WHERE s.root_project_id   = authorized_input_components.root_project_id
    AND s.islast              = 1
    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id
    AND s.path LIKE authorized_input_components.path
      || authorized_input_components.sid
      || '.%' )
    OR (s.id                                                 = authorized_input_components.sid) )
    ) authorizedComponents ON authorizedComponents.project_id=i.component_id
  WHERE i.resolution                                        IS NULL
  )
WHERE rownum <= 15000

The performance are better.
Here is the plan:

1       SELECT STATEMENT
         COUNT STOPKEY
1         NESTED LOOPS
5          NESTED LOOPS
1           NESTED LOOPS
1            NESTED LOOPS
2             NESTED LOOPS
2              NESTED LOOPS
2               NESTED LOOPS
2                VIEW
2                 SORT UNIQUE
                   UNION-ALL
                    FILTER
1                    NESTED LOOPS
363                   NESTED LOOPS
363                    TABLE ACCESS BY INDEX ROWID GROUP_ROLES
363                     INDEX RANGE SCAN GROUP_ROLES_ROLE
1                      INDEX UNIQUE SCAN SYS_C003794
1                     TABLE ACCESS BY INDEX ROWID PROJECTS
1                    INDEX UNIQUE SCAN GROUPS_USERS_UNIQUE
                    FILTER
1                    NESTED LOOPS
1                     NESTED LOOPS
1                      TABLE ACCESS BY INDEX ROWID USER_ROLES
1                       INDEX RANGE SCAN USER_ROLES_USER
1                      INDEX UNIQUE SCAN SYS_C003794
1                     TABLE ACCESS BY INDEX ROWID PROJECTS
1                TABLE ACCESS BY INDEX ROWID PROJECTS
1                 INDEX RANGE SCAN PROJECTS_KEE
1               TABLE ACCESS BY INDEX ROWID SNAPSHOTS
1                INDEX RANGE SCAN SNAPSHOT_PROJECT_ID
1              TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72              INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
1             TABLE ACCESS BY INDEX ROWID PROJECTS
1              INDEX UNIQUE SCAN SYS_C003794
1            TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72            INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
5           INDEX RANGE SCAN ISSUES_COMPONENT_ID
1          TABLE ACCESS BY INDEX ROWID ISSUES

For comparison, the plan when we are not logged is that:
1       SELECT STATEMENT
         COUNT STOPKEY
1         NESTED LOOPS
4          NESTED LOOPS
1           NESTED LOOPS
1            NESTED LOOPS
1             NESTED LOOPS
1              NESTED LOOPS
2               HASH JOIN
16422            TABLE ACCESS FULL SNAPSHOTS
19893            MERGE JOIN
16422             TABLE ACCESS BY INDEX ROWID SNAPSHOTS
23802              INDEX FULL SCAN SNAPSHOTS_ROOT_PROJECT_ID
16422             SORT JOIN
16422              TABLE ACCESS FULL SNAPSHOTS
1               TABLE ACCESS BY INDEX ROWID PROJECTS
1                INDEX UNIQUE SCAN SYS_C003794
1              TABLE ACCESS BY INDEX ROWID ISSUES
5               INDEX RANGE SCAN ISSUES_COMPONENT_ID
1             TABLE ACCESS BY INDEX ROWID PROJECTS
1              INDEX UNIQUE SCAN SYS_C003794
1            TABLE ACCESS BY INDEX ROWID PROJECTS
1             INDEX RANGE SCAN PROJECTS_KEE
4           INDEX RANGE SCAN GROUP_ROLES_RESOURCE
1          TABLE ACCESS BY INDEX ROWID GROUP_ROLES

Is it possible to implement the same request when the user is not logged into it?

@ tlueecke
We are going to ask to our DBAs to manage the faulty request using Oracle SQL Plan Management.

Cordialement / Best regards

Laurent TOURREAU




This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email



Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2

Hi Jose

 

Yes all previous email were while we didn’t logged in SonarQube.

 

Regards

Laurent TOURREAU

 

 

From: [hidden email] [mailto:[hidden email]]
Sent: vendredi 14 février 2014 17:22
To: [hidden email]
Subject: Re: [sonar-user] Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

 

Hi Laurent,

 

We have discovered we don't have this issue when we are login into SonarQube

 

What do you mean ? All previous email were while not logged in SonarQube ?

 

Regards


José GOMEZ | SonarSource

Support team
http://sonarsource.com

 

 

On 14 February 2014 16:35, Laurent TOURREAU <[hidden email]> wrote:

Hi Sonarqube Team

We are still fighting against that performance problem.

We have discovered we don't have this issue when we are login into SonarQube. It seems that the SQL statement (for the same result) is not the same:


SELECT i.id
  FROM issues i
  INNER JOIN
    (SELECT s.project_id
    FROM snapshots s,
      (SELECT project_components.id         AS id,
        snapshot_components.id              AS sid,
        root_snapshot_components.project_id AS root_project_id,
        root_snapshot_components.id         AS root_snapshot_id,
        snapshot_components.path            AS path
      FROM projects project_components
      INNER JOIN snapshots snapshot_components
      ON snapshot_components.project_id = project_components.id
      AND snapshot_components.islast    = 1
      INNER JOIN snapshots root_snapshot_components
      ON root_snapshot_components.project_id = snapshot_components.root_project_id
      AND root_snapshot_components.islast    = 1

      INNER JOIN projects root_project
      ON root_project.id=root_snapshot_components.project_id
      INNER JOIN
        (SELECT p.kee AS root_project_kee

        FROM group_roles gr
        INNER JOIN projects p
        ON p.id           = gr.resource_id
        AND p.scope       = 'PRJ'
        AND p.qualifier   = 'TRK'
        WHERE gr.role     = 'user'

        AND (gr.group_id IS NULL
        OR gr.group_id   IN
          (SELECT gu.group_id FROM groups_users gu WHERE gu.user_id=10000
          ))
        UNION
        SELECT p.kee AS root_project_kee
        FROM user_roles ur
        INNER JOIN projects p
        ON p.id                                                       = ur.resource_id

        AND p.scope                                                   = 'PRJ'
        AND p.qualifier                                               = 'TRK'

        WHERE ur.role                                                 = null
        AND ur.user_id                                                = 10000
        ) authorized_projects ON authorized_projects.root_project_kee = root_project.kee
      WHERE ( project_components.kee                                  ='com.myApp:myApp')

      AND project_components.enabled                                  = 1
      ) authorized_input_components
    WHERE s.root_project_id   = authorized_input_components.root_project_id
    AND s.islast              = 1
    AND ( (s.root_snapshot_id = authorized_input_components.root_snapshot_id
    AND s.path LIKE authorized_input_components.path
      || authorized_input_components.sid
      || '.%' )
    OR (s.id                                                 = authorized_input_components.sid) )
    ) authorizedComponents ON authorizedComponents.project_id=i.component_id
  WHERE i.resolution                                        IS NULL
  )

WHERE rownum <= 15000

The performance are better.
Here is the plan:

1       SELECT STATEMENT
         COUNT STOPKEY
1         NESTED LOOPS
5          NESTED LOOPS
1           NESTED LOOPS
1            NESTED LOOPS
2             NESTED LOOPS
2              NESTED LOOPS
2               NESTED LOOPS
2                VIEW
2                 SORT UNIQUE
                   UNION-ALL
                    FILTER
1                    NESTED LOOPS
363                   NESTED LOOPS
363                    TABLE ACCESS BY INDEX ROWID GROUP_ROLES
363                     INDEX RANGE SCAN GROUP_ROLES_ROLE
1                      INDEX UNIQUE SCAN SYS_C003794
1                     TABLE ACCESS BY INDEX ROWID PROJECTS
1                    INDEX UNIQUE SCAN GROUPS_USERS_UNIQUE
                    FILTER
1                    NESTED LOOPS
1                     NESTED LOOPS
1                      TABLE ACCESS BY INDEX ROWID USER_ROLES
1                       INDEX RANGE SCAN USER_ROLES_USER
1                      INDEX UNIQUE SCAN SYS_C003794
1                     TABLE ACCESS BY INDEX ROWID PROJECTS
1                TABLE ACCESS BY INDEX ROWID PROJECTS
1                 INDEX RANGE SCAN PROJECTS_KEE
1               TABLE ACCESS BY INDEX ROWID SNAPSHOTS
1                INDEX RANGE SCAN SNAPSHOT_PROJECT_ID
1              TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72              INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
1             TABLE ACCESS BY INDEX ROWID PROJECTS
1              INDEX UNIQUE SCAN SYS_C003794
1            TABLE ACCESS BY INDEX ROWID SNAPSHOTS
72            INDEX RANGE SCAN SNAPSHOTS_ROOT_PROJECT_ID
5           INDEX RANGE SCAN ISSUES_COMPONENT_ID
1          TABLE ACCESS BY INDEX ROWID ISSUES

For comparison, the plan when we are not logged is that:
1       SELECT STATEMENT
         COUNT STOPKEY
1         NESTED LOOPS
4          NESTED LOOPS
1           NESTED LOOPS
1            NESTED LOOPS
1             NESTED LOOPS
1              NESTED LOOPS
2               HASH JOIN
16422            TABLE ACCESS FULL SNAPSHOTS
19893            MERGE JOIN
16422             TABLE ACCESS BY INDEX ROWID SNAPSHOTS
23802              INDEX FULL SCAN SNAPSHOTS_ROOT_PROJECT_ID
16422             SORT JOIN
16422              TABLE ACCESS FULL SNAPSHOTS
1               TABLE ACCESS BY INDEX ROWID PROJECTS
1                INDEX UNIQUE SCAN SYS_C003794
1              TABLE ACCESS BY INDEX ROWID ISSUES
5               INDEX RANGE SCAN ISSUES_COMPONENT_ID
1             TABLE ACCESS BY INDEX ROWID PROJECTS
1              INDEX UNIQUE SCAN SYS_C003794
1            TABLE ACCESS BY INDEX ROWID PROJECTS
1             INDEX RANGE SCAN PROJECTS_KEE
4           INDEX RANGE SCAN GROUP_ROLES_RESOURCE
1          TABLE ACCESS BY INDEX ROWID GROUP_ROLES

Is it possible to implement the same request when the user is not logged into it?

@ tlueecke
We are going to ask to our DBAs to manage the faulty request using Oracle SQL Plan Management.

Cordialement / Best regards


Laurent TOURREAU




This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.

---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email

 

Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

tlueecke
Hi all,

for whomever it may interest: in our case the performance problem unfortunately reoccurred after a week and even worsened until the analysis job could no longer be executed. After a deeper analysis, the projects_kee index on the projects table seemed to cause the sessions to hang, even after the Sonarqube server was shut down. We dropped the index and recreated it as a unique index and now everything runs smooth.

Brgds,
Tim
Reply | Threaded
Open this post in threaded view
|

Re: Sonarqube 4.0 performance issue when querying Issues Drilldown

Laurent TOURREAU-2
Hi

Finally we have asked to our DBA to create a profile to manage those issues drilldown requests.
The performance are incredibly better!

The response time is less than one second instead of more than 30 second previously!
The Eclipse plugin work better.

According to our DBA, the indexing of the concerned tables should be reviewed.

Can SONARQube team take account to review and improve the indexation of the table for issue drilldown requests?

Regards

Laurent TOURREAU



This message and any attachments (the "message") is
intended solely for the intended addressees and is confidential.
If you receive this message in error,or are not the intended recipient(s),
please delete it and any copies from your systems and immediately notify
the sender. Any unauthorized view, use that does not comply with its purpose,
dissemination or disclosure, either whole or partial, is prohibited. Since the internet
cannot guarantee the integrity of this message which may not be reliable, BNP PARIBAS
(and its subsidiaries) shall not be liable for the message if modified, changed or falsified.
Do not print this message unless it is necessary,consider the environment.

----------------------------------------------------------------------------------------------------------------------------------

Ce message et toutes les pieces jointes (ci-apres le "message")
sont etablis a l'intention exclusive de ses destinataires et sont confidentiels.
Si vous recevez ce message par erreur ou s'il ne vous est pas destine,
merci de le detruire ainsi que toute copie de votre systeme et d'en avertir
immediatement l'expediteur. Toute lecture non autorisee, toute utilisation de
ce message qui n'est pas conforme a sa destination, toute diffusion ou toute
publication, totale ou partielle, est interdite. L'Internet ne permettant pas d'assurer
l'integrite de ce message electronique susceptible d'alteration, BNP Paribas
(et ses filiales) decline(nt) toute responsabilite au titre de ce message dans l'hypothese
ou il aurait ete modifie, deforme ou falsifie.
N'imprimez ce message que si necessaire, pensez a l'environnement.


---------------------------------------------------------------------
To unsubscribe from this list, please visit:

    http://xircles.codehaus.org/manage_email


12