GNOME Bugzilla – Bug 342338
suffers from memory fragmentation
Last modified: 2010-01-13 19:24:40 UTC
Hi, i'm using gnome-terminal 2.14.0 at work. I'm a sysadmin, so i usually have 20-60 tabs opened. With scrollback buffer of 5 MiB I started gnome-terminal 17 days ago : cpu usage : 63 minutes virtual memory : 198.8 MiB private_dirty : 53.1 MiB heap size : 177 MiB resident memory : 73.5 MiB My problem is that memory gets more and more fragmented which leads to higher memory usage. As i have several too terminals opened, i'm not able to close gnome-terminal. I actually never close it. I think the problem is that buffers are not allocated at once. It really looks like each buffer line is allocated separately. That's why the heap is so big, so fragmented and that memory is never returned to the system. Moreover, closing a tab opened a long time ago (but recently used) can take up to 15s and generate a lot of disk activity (in order to free each memory chunk that got swapped i guess). So in a perfect world, gnome-terminal (or vte, i don't know) would use a separate memory storage for each terminal buffer and would allocate big chunk of memory at once (i mean g_malloc(5MiB) if buffer size is 5MiB). Thanks.
Indeed, that's vte. Reassigning.
Vte uses g_array . I don't see how this can be improved easily. And even if you malloc one single buffer, that still will be swapped out when not used. If you 5MiB per tab and 20..60 tabs open, I don't see how the memory usage is other than expected.
Closing terminals doesnt return any memory to the system. gnome-terminal memory usage keeps increasing with time.
True... That's because g_array allocates using g_malloc... Using g_slice doesn't necessarily help, 'cause that uses memalign that is essentially same as malloc I guess. Allocing the 5MiB straight may help, but its really hard, when you resize your terminal for example.
I never suggested using g_slice. I'm just disappointed because when i close a windows with 5 tabs, no memory is returned to the system. And i never said it would be easy :)
*** Bug 354324 has been marked as a duplicate of this bug. ***
We can reduce the pain slightly by managing our heap allocations better. The preferred solution to this problem, as Behdad has suggested, is to implement a custom block allocator. This has other advantages such as perhaps implementing a MVC paradigm to enable split-view and friends. r1620: 2007-02-05 Chris Wilson <chris@chris-wilson.co.uk> cf Bug 342338 – suffers from memory fragmentation Reuse the last VteRowData instead of immediately freeing it. Avoids recreating and *regrowing* a new GArray on the heap. In the simple scrolling benchmarks this can boost performance by as much as 10%! * src/ring.c: (_vte_ring_insert), (_vte_ring_insert_preserve), (_vte_ring_remove), (_vte_ring_append): * src/ring.h: * src/vte-private.h: * src/vte.c: (_vte_reset_row_data), (_vte_terminal_ensure_cursor), (_vte_terminal_insert_char), (vte_terminal_reset_rowdata): * src/vteseq.c: (vte_insert_line_internal), (vte_sequence_handler_scroll_up_or_down), (vte_sequence_handler_cd), (vte_sequence_handler_sf), (vte_sequence_handler_clear_screen), (vte_sequence_handler_screen_alignment_test):
Hi, konsole can handle an infinite history (quite useful sometimes) and it's really fast by using an an mmapped file as the ondisk buffer. The code is here: http://websvn.kde.org/trunk/KDE/kdebase/apps/konsole/src/BlockArray.cpp?revision=662726&view=markup Maybe a similar approach can be used by vte? Thanks!
It seems that vte doesn't release memory at all when a terminal is cleared or is closed (when you close a tab for example). One way to easily test it is to start the following command line: hexdump </dev/urandom On my system, memory usage increase until about 110MB (when the buffer is filled). Then it stays constant. Clearing the terminal or closing it doesn't release memory. I don't know if this is the same bug or not, because when this command is run, all the memory is allocated in a limited time. If it's not the same bug, I'll be happy to open, a new bug report. See this for further information: https://sourceforge.net/tracker/index.php?func=detail&aid=2021978&group_id=124080&atid=698428 (bug in roxterm)
cat -tev /dev/urandom gives even worst results. I've resumed a sysadmin job and gnome-terminal is a great tool. About a dozen of open windows, 1-5 tabs each. The problem is less annoying than it used to be because my workstation now has 2GiB of memory (so it's not swapping), but i often see heap's size (with pmap) around 200MiB, even when i do some cleanup on friday night before leaving.
*** Bug 559385 has been marked as a duplicate of this bug. ***
why this bug still in unconfirmed state?
This has been completely fixed for a few months now.