Suggestion on config item

144 views
Skip to first unread message

ravirajk...@gmail.com

unread,
Jun 5, 2025, 5:14:26 AMJun 5
to Repo and Gerrit Discussion
Hi All,

We are running Gerrit 3.5.6 and we are planning to upgrade to 3.7.9

The Gerrit 3.6 release notes  [1] says that we need to add a config item like below. Is it fixed in Gerrit 3.7.9 to or should we add this to our config after the upgrade?

[cache "changes_by_project"]
      memoryLimit = 0

Matthias Sohn

unread,
Jun 5, 2025, 5:23:41 AMJun 5
to ravirajk...@gmail.com, Repo and Gerrit Discussion
On Thu, Jun 5, 2025 at 11:14 AM ravirajk...@gmail.com <ravirajk...@gmail.com> wrote:
Hi All,

We are running Gerrit 3.5.6 and we are planning to upgrade to 3.7.9

You should consider upgrading to a supported release (at least 3.10.6, see https://endoflife.date/gerrit).
 

The Gerrit 3.6 release notes  [1] says that we need to add a config item like below. Is it fixed in Gerrit 3.7.9 to or should we add this to our config after the upgrade?

[cache "changes_by_project"]
      memoryLimit = 0

it seems Gerrit releases at least up to 3.11 are affected by this issue.

I don't know if there's a fix already.

-Matthias
 
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/bdaad64a-98b0-4141-be07-bc1b9db15b1en%40googlegroups.com.

Luca Milanesio

unread,
Jun 5, 2025, 6:24:59 AMJun 5
to Repo and Gerrit Discussion, Luca Milanesio

On 5 Jun 2025, at 10:23, Matthias Sohn <matthi...@gmail.com> wrote:

On Thu, Jun 5, 2025 at 11:14 AM ravirajk...@gmail.com <ravirajk...@gmail.com> wrote:
Hi All,

We are running Gerrit 3.5.6 and we are planning to upgrade to 3.7.9

You should consider upgrading to a supported release (at least 3.10.6, see https://endoflife.date/gerrit).

+1

Please look at all the different migration options at the talks in [2].

 

The Gerrit 3.6 release notes  [1] says that we need to add a config item like below. Is it fixed in Gerrit 3.7.9 to or should we add this to our config after the upgrade?

[cache "changes_by_project"]
      memoryLimit = 0

The answer is always “it depends”.

The question is: do you have git clone latency issues on replicas because of a very high number of changes?
If the answer is no, then just disable the “changes_by_project” cache as that cache isn’t providing any value to your setup.

If the answer is yes and you don’t have any changes with server-ids coming from other servers, then just do nothing as the cache is enabled by default.



it seems Gerrit releases at least up to 3.11 are affected by this issue.

I don't know if there's a fix already.

Actually, the fix is disabling the cache for now :-) and that’s indicated in the release notes.
There is no bug, just that cache isn’t designed for a setup with change numbers conflicts or different server-ids.

I’ll be happy to review any changes to that cache for making it compatible with changes with foreign server-ids.

HTH



-Matthias
 
--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/bdaad64a-98b0-4141-be07-bc1b9db15b1en%40googlegroups.com.

--
--
To unsubscribe, email repo-discuss...@googlegroups.com
More info at http://groups.google.com/group/repo-discuss?hl=en

---
You received this message because you are subscribed to the Google Groups "Repo and Gerrit Discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to repo-discuss...@googlegroups.com.

Nuno Costa

unread,
Jul 18, 2025, 6:23:14 AMJul 18
to Repo and Gerrit Discussion
Hi All,

We are testing upgrade to 3.9 (last version that supports java 11 and we will upgrade java after Gerrit upgrade) and cache changes_by_project always shows empty.

I tried list changes in a repo using the API, normal clones, mirror clones and pushing review but nothing seems to populate the cache.

Also explicitly set memLimit=10000 but it is still empty.

Since we don't see any issues with clone latency and to avoid potencial problems we will disable the cache as suggested.

How is this cache populated?
Is there some gerrit config that might be overriding populating the cache?
I'm running the wrong tests?
something else? :)

Thanks,
Nuno

Luca Milanesio

unread,
Jul 18, 2025, 6:25:46 AMJul 18
to Repo and Gerrit Discussion, Luca Milanesio
On 18 Jul 2025, at 11:23, Nuno Costa <nunoco...@gmail.com> wrote:

Hi All,

We are testing upgrade to 3.9 (last version that supports java 11 and we will upgrade java after Gerrit upgrade) and cache changes_by_project always shows empty.

Are you testing it on primary or replicas?

Luca.

Nuno Costa

unread,
Jul 18, 2025, 6:29:07 AMJul 18
to Repo and Gerrit Discussion
Primary for now.

We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.

Luca Milanesio

unread,
Jul 18, 2025, 6:31:21 AMJul 18
to Repo and Gerrit Discussion, Luca Milanesio

On 18 Jul 2025, at 11:29, Nuno Costa <nunoco...@gmail.com> wrote:

Primary for now.

We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.

That change isn’t for you then: just disable the cache altogether.

Luca.

Nuno Costa

unread,
Jul 18, 2025, 7:05:59 AMJul 18
to Repo and Gerrit Discussion
Thanks for the followup Luca.

I disabled the cache:

$ git config -f gerrit.config -l | grep cache.changes_by
cache.changes_by_project.memorylimit=0

but it still shows when running show-caches.

% date ; ssh -p 29418 gerrit.server gerrit show-caches | grep changes_by_project

Fri Jul 18 11:41:00 WEST 2025
changes_by_project            |                     |         |         |


Is this expected?

Luca Milanesio

unread,
Jul 18, 2025, 7:23:04 PMJul 18
to Repo and Gerrit Discussion, Luca Milanesio


> On 18 Jul 2025, at 12:05, Nuno Costa <nunoco...@gmail.com> wrote:
>
> Thanks for the followup Luca.
>
> I disabled the cache:
> $ git config -f gerrit.config -l | grep cache.changes_by
> cache.changes_by_project.memorylimit=0
> but it still shows when running show-caches.
> % date ; ssh -p 29418 gerrit.server gerrit show-caches | grep changes_by_project
> Fri Jul 18 11:41:00 WEST 2025
> changes_by_project | | | |


The documentation at [1] says that the values are NOT stored in memory, but doesn’t say that the cache disappears.
IMHO it is correct that is listed, because its loader is invoked and the overall mechanism is there, but just doesn’t keep the value in memory.

HTH

Luca.

[1] https://gerrit-documentation.storage.googleapis.com/Documentation/3.12.0/config-gerrit.html#cache.name.memoryLimit
> To view this discussion visit https://groups.google.com/d/msgid/repo-discuss/b16aa460-c64c-4e6c-8e51-46e7ba8416e2n%40googlegroups.com.

Nasser Grainawi

unread,
Jul 21, 2025, 4:55:32 PMJul 21
to Luca Milanesio, Repo and Gerrit Discussion
On Fri, Jul 18, 2025 at 4:31 AM Luca Milanesio <luca.mi...@gmail.com> wrote:


On 18 Jul 2025, at 11:29, Nuno Costa <nunoco...@gmail.com> wrote:

Primary for now.

We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.

That change isn’t for you then: just disable the cache altogether.

It can be helpful on primaries, so I wouldn't disable it just because the testing results weren't what you expected...
 

Luca.


On Friday, 18 July 2025 at 11:25:46 UTC+1 Luca Milanesio wrote:
On 18 Jul 2025, at 11:23, Nuno Costa <nunoco...@gmail.com> wrote:

Hi All,

We are testing upgrade to 3.9 (last version that supports java 11 and we will upgrade java after Gerrit upgrade) and cache changes_by_project always shows empty.

Are you testing it on primary or replicas?

Luca.


I tried list changes in a repo using the API, normal clones, mirror clones and pushing review but nothing seems to populate the cache.

Also explicitly set memLimit=10000 but it is still empty.

Since we don't see any issues with clone latency and to avoid potencial problems we will disable the cache as suggested.

How is this cache populated?
Is there some gerrit config that might be overriding populating the cache?
I'm running the wrong tests?
something else? :)

You're probably running the tests as a user with some kind of "global read" permission, like an admin. If you have read permission on refs/* for the repos you tested with, then there won't be any refs filtered and there won't be any entries in the cache.
 

Luca Milanesio

unread,
Jul 21, 2025, 4:58:25 PMJul 21
to Repo and Gerrit Discussion, Luca Milanesio

On 21 Jul 2025, at 21:55, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:



On Fri, Jul 18, 2025 at 4:31 AM Luca Milanesio <luca.mi...@gmail.com> wrote:


On 18 Jul 2025, at 11:29, Nuno Costa <nunoco...@gmail.com> wrote:

Primary for now.

We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.

That change isn’t for you then: just disable the cache altogether.

It can be helpful on primaries, so I wouldn't disable it just because the testing results weren't what you expected...

What would be the benefit on Gerrit primary nodes?
Because the Lucene index is there, I did not see any improvement in the benchmark included in the change.

Thanks for clarifying, so that we can amend the release notes.

Luca.

Nasser Grainawi

unread,
Aug 8, 2025, 12:47:06 PMAug 8
to Luca Milanesio, Repo and Gerrit Discussion
On Mon, Jul 21, 2025 at 2:58 PM Luca Milanesio <luca.mi...@gmail.com> wrote:


On 21 Jul 2025, at 21:55, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:



On Fri, Jul 18, 2025 at 4:31 AM Luca Milanesio <luca.mi...@gmail.com> wrote:


On 18 Jul 2025, at 11:29, Nuno Costa <nunoco...@gmail.com> wrote:

Primary for now.

We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.

That change isn’t for you then: just disable the cache altogether.

It can be helpful on primaries, so I wouldn't disable it just because the testing results weren't what you expected...

What would be the benefit on Gerrit primary nodes?
Because the Lucene index is there, I did not see any improvement in the benchmark included in the change.

It's mentioned in the docs that it can help with git push (receive-pack) performance in some cases. I don't remember all the details, but I think the benchmark to repro that improvement either wasn't as simple or was confirmed post-merge, so it wasn't included in the commit message.

Nasser
 

Luca Milanesio

unread,
Aug 12, 2025, 3:34:16 PMAug 12
to Repo and Gerrit Discussion, Luca Milanesio


> On 8 Aug 2025, at 17:46, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:
>
>
>
> On Mon, Jul 21, 2025 at 2:58 PM Luca Milanesio <luca.mi...@gmail.com> wrote:
>
>
>> On 21 Jul 2025, at 21:55, Nasser Grainawi <nasser....@oss.qualcomm.com> wrote:
>>
>>
>>
>> On Fri, Jul 18, 2025 at 4:31 AM Luca Milanesio <luca.mi...@gmail.com> wrote:
>>
>>
>>> On 18 Jul 2025, at 11:29, Nuno Costa <nunoco...@gmail.com> wrote:
>>>
>>> Primary for now.
>>>
>>> We use replicas with UI (basically Master with readonly plugin) but did not tested on them yet.
>>
>> That change isn’t for you then: just disable the cache altogether.
>>
>> It can be helpful on primaries, so I wouldn't disable it just because the testing results weren't what you expected...
>
>
> What would be the benefit on Gerrit primary nodes?
> Because the Lucene index is there, I did not see any improvement in the benchmark included in the change.
>
> It's mentioned in the docs that it can help with git push (receive-pack) performance in some cases.


I have personally performed extensive tests on the performance improvements on git push (see [1]) and had very successful improvements (10x faster) by simply changing the receive.advertiseOpenChangesRefs values, kudos to Jacek [2], by lowering the default value of 32 and without having to cache the open changes by project on a primary node.

The advantage of using [2] vs. adding yet another cache, is less memory footprint, less CPU utilisation, more speed.

HTH

Luca.

[1] https://gerrit-review.googlesource.com/c/gerrit/+/246195/1//COMMIT_MSG#11
[2] https://gerrit-review.googlesource.com/c/gerrit/+/452582
Reply all
Reply to author
Forward
0 new messages