Memory consumption (of Gramps session that has been running since 11 Apr 2026)

Help
,
1

Gramps v. 6.0.8 on macOS

I usually don’t shut down Gramps, so at the moment Gramps has been running since April 11th.
During this time the memory allocation has grown from around 300 MB at startup till 10.61 GB as of today. It looks like it’s growing 500 MB per day (when I’m actively using Gramps).

Resource wise it’s not a problem as I have plenty of unused memory.

Will make a cron job to monitor Gramps, so I get a better picture of the memory allocation.
Are there any tools to investigate into running Python applications, that I should use?

2

We have some memory leak fixes for an upcoming release.

3

@csam the change Doug mentioned is currently a pull request that can be found here Fix Resource Leaks by stevenyoungs · Pull Request #2237 · gramps-project/gramps · GitHub

It is not formally approved yet, but has been through some rounds of review and improvement already.

4

A follow up on the memory issue.

Gramps has not been stopped since April 11th, and it has now allocated 18,68 GB memory.

I think that I have found at least one reason for the memory leak - Gramps Web Sync

Each time I run the Web Sync - even if there’s no data to sync - the memory consumption grows with 8 MB.

@DavidMStraub can you please take a look at this?

5

I’m using FamilyTreeView (FTV) and it looks like FTV is allocating a lot of memory every time you shift focus from one person to another.
@ztlxltl can you please investigate

6

What is FTV?

Are you talking about memory (RAM) or storage? When using gunicorn, I don’t see how memory could grow without bounds, as workers have a limited lifetime.

Grampshub is a pretty powerful diagnostic for me to detect memory leaks if Gramps Web had any, and I don’t see any right now (there we some in the past!).

7

I’m only talking about memory allocation in Gramps Desktop. The Gramps Web Sync is run in Gramps Desktop, and it looks like memory used is not freed after the sync has finished.

FTV with the full name FamilyTreeView is an add-on that displays a family tree graphically. Very powerful and very intuitive.

I did put your name in the post because I thought, that you are the maintainer of the Gramps Web Sync add-on.

8

Oh I see. Sorry.

Yes, in that case the Sync addon could well be leaky, I’ll look into it!

9

Been digging a bit more into the memory consumption growth.

I have made a small script using ‘ps’ to log memory usage, that I run after each operation in Gramps. I have then manually added comment to the log file.

The script looks like this:

#!/bin/bash
LOG=/Users/sam/mygramps/memprofile.log
dato=`date "+%Y-%m-%d %H:%M:%S"`
echo -n ${dato} '   ' >> ${LOG}
ps -xm -o rss='',start='' -p $(pgrep Gramps) >> ${LOG}

‘rss’ is real memory size of the process in 1024 bytes units

Here’s the log from a few operations in Gramps (columns are timestamp, rss, starttime, comment):

2026-06-01 15:38:35    1823128 22May26	Before backup
2026-06-01 15:39:49    1825904 22May26	After backup	[+2776]
2026-06-01 15:41:36    1843436 22May26	After Web Sync	[+17532]
2026-06-01 15:43:29    1844692 22May26
2026-06-01 15:43:48    1861564 22May26	After open/close Person editor from FTV [+16872]
2026-06-01 15:45:06    1875972 22May26	After open/close Person editor from FTV same person [+14408]
2026-06-01 15:46:54    1877244 22May26	Shift to Person List via Navigator [+1272]
2026-06-01 15:47:54    1893788 22May26	After open/close Person editor from Person List same person [+16544]
2026-06-01 15:55:35    1893660 22May26
2026-06-01 15:56:24    1931172 22May26	After open/close Person->Event->Citation->Note editors same person [+35512]

The numbers in square brackets is the growth in Kb after each operation.
The total growth in memory allocated for these few operations are 108 Mb.
I first thought that FTV was a main reason as I do all my work from within FTV, but the growth happens independent of FTV.
@ztlxltl suggested that the memory growth might be GTK related.

10

@csam sent me a log of his tool from a different test, According to his comments, simply zooming in and out and moving the visualization around increased the memory usage. FTV is not doing much in those cases, except changing the scale of the GooCanvas and changing the Gtk.Adjustments of the Gtk.ScrolledWindow.

I ran a slightly modified version of @csam’s script to see if memory usage would increase similarly when using GraphView, because it also uses a Gtk.ScrolledWindow and a GooCanvas. And memory usage of GraphView seems to increase similarly to FTV.
I also tested switching views and scrolling in the People Tree View. Memory usage constantly increased, albeit more slowly and not with every switch after switching views back and forth a few times.

There may be a deeper-rooted problem, perhaps even in GTK. However, I think that’s unlikely.

11

The Uncollected Objects gramplet can be useful for debugging this type of issue.

12

The only Uncollected Objects gramplet I can find is PR140 which has been pending years, and does not currently build. Is there another?

13

Yes. There is one in core Gramps.

14

I did a ‘grep’ for ‘import gc’ on the source files.
Found plugins/gramplets/leak.py
The description in this source file is “Show uncollected objects in a window.”
Is this the gramplet you mention?

I can’t find it neither in the plugin manager nor in the add-on manager

15

Yes.

It is a developer gramplet, so you need to run Gramps without the -O flag to use it.

16

Listed as a “Debug feature” in the wiki.

https://www.gramps-project.org/wiki/index.php/Gramps_6.0_Wiki_Manual_-_Gramplets#Uncollected_Objects

1703308211
1703308211401×532 15.6 KB

Is there any possibility that such Debug/Developer features might be enabled on-the-fly (within the Gramps GUI) some time in the future? (At that point, the Developer audience for plugin registration becomes more functional, useful and interesting. It becomes a viable way to decomplicate the interface without making rarely-needed features too inaccessible.)

Command line enabled options are… complicated… whenever the Gramps application is not in the command path. (Particularly for sandboxed Gramps … like a Snap, Flatpak or PortableApps install. Or where there are multiple versions of Gramps installed on a system.)