Question about downsizing VM of Sonarqube and where does the elastic search happens?

My current setup for Sonarqube has one VM that houses the application itself and a separate postgresql database server to host the database.

Now I’m planning to downsize the VM of my Sonarqube instance from:

DS4v2:
General purpose
vCPUS = 8
RAM = 28
Data Disk = 32
MAX IOps 25600
Local Storage 56 (GiB)
Premium Disk Supported

“Ideal size” = D8s_v3:

General Purpose
vCPU = 8
RAM = 32
Data Disk 16
MaxIOPS 12800
Local Storage 64GiB
Premium Disk Supported

From the data above, MaxIOPS will be downgraded from 25600 to 12800. Am I correct in my understanding that this won’t be an issue if the disk activity of the VM only spikes at almost 4MiB/s in a span of 90 days?

I checked the hard requirements of Sonarqube and I believe each points have already been addressed (hardware wise), the only thing that I didn’t see there is the recommended number of IOPS.


For Elastic Search I wanted to understand, where does this activity of “ESing” coming from? Does it use disk activity in the VM itself (that houses the application server) or in the database (which is separate from the VM that houses the application)?

Hi @popac00 ,

Your new machine is matching (or even exceeding) our hardware recommendations. We don’t explicitly state what number of Max IOPS is good enough - this depends on many things (number of concurrent users, size of the projects) that differ between the instances. It shouldn’t be an issue based on the data that you shared but have in mind that disk read/write throughput is not the same metric as IOPS.

I would mostly be worried about your data disk being two times smaller than before and I hope you validated in your current machine that 32 GB is just not needed.

Does it use disk activity in the VM itself (that houses the application server) or in the database (which is separate from the VM that houses the application)?

Elasticsearch activity puts stress on the disk in the VM itself. That being said, in case rebuilding of elasticsearch indexes is needed it will indirectly put some stress on the database (as it needs to fetch the data).

2 Likes

Hi, as regards to the number of disks that’s fine. The “32 down to 16” doesn’t pertain to the storage size of the disks however, it pertains to the number actual disks storage that I can potentially attach to the VM. Currently the disks provisioned are 3 (1 - OS, 2 data). Once I resized it to D8s_v3, I should be able to attach 13 disks more.

Btw, thanks ffor your help in validating max IOPS and elastic search activity.

1 Like