Hello @jasondamour huge thanks for taking the time to help us troubleshoot that by giving us all those informations and testing the different scenarios.
Based on what you gave us, there is still something i would like to try based on the configuration of your cluster.
Could you try to run the same tests but inside the pod, with a sidecar container targeting localhost ?
In order to do that we have Values.extraContainers
that let you define sidecar containers. ( there is an h2load docker image, but it might be old and untrusty, we could build a small one for that or just script everything in an official os image)
I have seen similar cases caused by the cloud infra and would like to do the most precise test really close to the SonarQube instance.
Depending on the result i will be very happy to keep investigating on what could be wrong.
Ps: i never worked in depth with google cloud, but on similar cloud platform i have seen many issue caused by :
- the iops of the disk
- the bandwith of the card interface
- the container network interface bugs
- …
Another point, the default monitoring cloud gives us might be misleading. For example when it was a microsoft process taking up all the iops, it would not be shown on the graph so on our side it was all ‘OK’
PS2: that does not exclude it could be a SonarQube bug, and i hope the test will give us that information.