# SQ Community Edition is unexpectedly slow on AWS ECS

**URL:** <https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783>\
**Category:** SonarQube Server / Community Build\
**Tags:** aws, postgres, performance, sonarqube, memory\
**Created:** [January 4, 2024, 9:34am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783 "2024-01-04T09:34:47Z")\
**Posts on this page:** 7\
**Page:** 1

<div class="post-metadata">

**Author:** ![lancedikson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lancedikson/32/36314_2.png) [@lancedikson](https://community.sonarsource.com/u/lancedikson)\
**Post date:** [January 4, 2024, 9:34am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/1 "2024-01-04T09:34:48Z")

</div>

Hi all! I’ve just rolled out a service with SQ Community Edition on AWS ECS and can’t get over it’s slow processing. There’re few things bothering me now:

1. The UI is noticeably slow, takes up 4-5 seconds to load the list of projects, opening a project for at least 6-7 seconds, but more importantly it takes more than 80s to load _any_ Project → Measures section, which is too slow for a request to fulfil in the web-server timeout range and it simply 504-s back to the request (I could adjust it with the env var, but it’s just unbearably slow).
2. Compute engine (or background tasks) seem to be quite slow as well — a relatively small project of 26k LOC takes 25 min to analyse. A bit larger one with 120k LOC takes around 50min. That’s a lot (right?).

My configuration:

- SonarQube Community edition (10.3.0.82913) from docker hub;
- AWS ECS Service running a task with SQ container on 2vCPU and 6GB RAM;
- AWS EFS Volumes (NAT) used for the `/data`, `/logs` and `/extensions`
- Postgres 12 on AWS RDS is used as the DB

I monitor utilization and it was on a very moderate level in every component, including under-utilized the ECS resources, so I went for bumping the heap settings to the following:

```auto
{
  name: "SONAR_CE_JAVAOPTS",
  value: "-Xms512m -Xmx2048m"
}, {
  name: "SONAR_WEB_JAVAOPTS",
  value: "-Xms512m -Xmx2048m"
},
{
  name: "SONAR_SEARCH_JAVAOPTS",
  value: "-Xms2048m -Xmx2048m"
},
{
  name: "SONAR_SEARCH_JAVAADDITIONALOPTS",
  value: "-Dnode.store.allow_mmap=false"
}

```

The logs are quite clear, there’s nothing extraordinary that could be related to the mentioned performance issues — no hints on why it’s that slow, no unexpected exceptions.

So, I’m wondering:

1. First of all, is the described performance normal and expected, or something is off with my service?
2. If something is off, how do I troubleshoot it? What’s the best way to debug such issues?
3. Is the heap settings the only thing I can do to “boost” performance (though honestly I haven’t noticed any change since they were applied — it performs on a level similar to default). Is there a way to turn-off particular language analyzers as I don’t use them if that would help to optimize utilization?

Here are screenshots of the System page:

 ![image_2024-01-04_113137615](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/9/5/95870a32a68fac5a4ed6ca80f510a87701918b4c.png)  
 ![image_2024-01-04_113226574](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/d/3/d3a065938ce390ca9677f4280c3198b31d194f7d.png)  
 ![image](https://europe1.discourse-cdn.com/sonarsource/uploads/sonarcommunity/original/3X/9/e/9e59266feb7a8f838319907501ca9f557bb8d482.png)

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [January 5, 2024, 10:17am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/2 "2024-01-05T10:17:05Z")

</div>

Most performance on SonarQube is related to database performance, including:

- DB Resources (CPU, memory, disk space)
- DB latency (how far away is the database network-wise)
- DB efficiency (is the database regularly having its indices and statistics refreshed)?

I would suggest you start your search there. And – be careful with your memory settings. If you’re setting a max heap of 2 GB for all 3 processes, that doesn’t leave much (any) room for the OS and other processes if the heap max is met.

---

<div class="post-metadata">

**Author:** ![lancedikson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lancedikson/32/36314_2.png) [@lancedikson](https://community.sonarsource.com/u/lancedikson)\
**Post date:** [January 5, 2024, 11:05am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/3 "2024-01-05T11:05:34Z")

</div>

Hi Colin! Thanks for a swift reply! The DB is currently located in a different region, so it might influence. I’m going to relocate it now and will circle back with the results.

---

<div class="post-metadata">

**Author:** ![lancedikson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lancedikson/32/36314_2.png) [@lancedikson](https://community.sonarsource.com/u/lancedikson)\
**Post date:** [January 5, 2024, 4:07pm UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/4 "2024-01-05T16:07:48Z")

</div>

You were right! It’s now blazing fast! 😃 The UI is very responsive and swift! Thanks a lot! Appreciate your advice! 🙏

---

<div class="post-metadata">

**Author:** ![lancedikson](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/lancedikson/32/36314_2.png) [@lancedikson](https://community.sonarsource.com/u/lancedikson)\
**Post date:** [January 5, 2024, 5:42pm UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/5 "2024-01-05T17:42:05Z")

</div>

One more question: based on your experience, what heap distribution is optimal for an average setup? Like 40% for the compute, 30% for the search and 30% for the web server?

---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [January 17, 2024, 11:11am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/7 "2024-01-17T11:11:36Z")

</div>



---

<div class="post-metadata">

**Author:** ![Colin](https://dub1.discourse-cdn.com/sonarsource/user_avatar/community.sonarsource.com/colin/32/55255_2.png) [@Colin](https://community.sonarsource.com/u/Colin)\
**Post date:** [August 14, 2024, 9:16am UTC](https://community.sonarsource.com/t/sq-community-edition-is-unexpectedly-slow-on-aws-ecs/106783/8 "2024-08-14T09:16:25Z")

</div>

Hey @lancedikson

A very late reply – but the vast majority of instances don’t need to deviate from the default. There’s no optimum “distribution”.

For commercial editions of SonarQube, we bump up the defaults

```auto
sonar.web.javaOpts=-Xmx1G -Xms128m -XX:+HeapDumpOnOutOfMemoryError
sonar.ce.javaOpts=-Xmx2G -Xms128m -XX:+HeapDumpOnOutOfMemoryError
sonar.search.javaOpts=-Xmx2G -Xms2G -XX:MaxDirectMemorySize=1G -XX:+HeapDumpOnOutOfMemoryError

```

Normally these only have to be adjusted if:

- Very large projects are being submitted (millions of lines of code)
- Multiple Compute Engine workers have been enabled (not relevant for Community Edition)