Bug 1331762 - Huge leaks in nautilus (and caribou) when adding/removing block devices
Summary: Huge leaks in nautilus (and caribou) when adding/removing block devices
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: nautilus
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Ondrej Holy
QA Contact: Desktop QE
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2016-04-29 13:05 UTC by Marian Csontos
Modified: 2020-01-09 15:13 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-09 15:13:20 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1331779 0 unspecified CLOSED Huge leaks in caribou (and nautilus) when adding/removing block devices 2021-02-22 00:41:40 UTC

Internal Links: 1331779

Description Marian Csontos 2016-04-29 13:05:31 UTC
Description of problem:
nautilus (and caribou) consuming too much memory when man block devices are present.

I was testing creating many LVs on a system with running gnome session. I expected memory to be stressed a bit but did not expect nautilus (and caribou) consuming 6.46GB (and 2.86GB) or RAM.

This might be a problem on machines running for example docker, where density of running 1000+ containers is the goal. As some of administration tools are using GUI it is not impossible and could affect customers.

Version-Release number of selected component (if applicable):
nautilus-3.14.3-7.el7.x86_64
caribou-0.4.16-1.el7.x86_64

How reproducible:
?

Steps to Reproduce:
1. for i in $(seq 1500); do lvcreate -s $VG/$THINLV; done

Actual results:
Wasted 9+ GB or RAM.

Expected results:
There should be some saner limit what file manager consumes.
Especially when doing "nothing".

Additional info:

> top - 13:22:11 up 26 days,  2:29,  8 users,  load average: 0.18, 0.29, 0.37
> Tasks: 3776 total,   1 running, 3770 sleeping,   5 stopped,   0 zombie
> %Cpu(s): 27.9 us,  4.3 sy,  0.2 ni, 67.6 id,  0.1 wa,  0.0 hi,  0.0 si,  0.0 st
> KiB Mem : 15889328 total,   165116 free, 14954932 used,   769280 buff/cache
> KiB Swap:  8388604 total,  1828152 free,  6560452 used.   204764 avail Mem 
> 
>   PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
> 19891 mrtianc   20   0 8001360 6.462g   1248 S   0.0 42.6  24:14.70 nautilus
> 19721 mrtianc   20   0 3839744 2.866g    904 S   0.0 18.9  14:04.27 caribou
> 25805 mcsontos  20   0 2028732 658272  15216 S   0.0  4.1   9:00.27 firefox

Comment 2 Marian Csontos 2016-04-29 13:48:24 UTC
Adding information from caribou Bug 1331779:

Even deactivating LVs causes both nautilus and caribou leaking a lot.

After restarting gnome, the programs were fine, until I started manipulating the LVs.
After deactivating 1000LVs it now looks like this:

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                                          
28616 mrtianc   20   0 2616316 1.698g  16968 S   0.0 11.2   5:59.90 nautilus
27886 mrtianc   20   0 1314972 751520   5044 S   0.0  4.7   2:58.94 caribou

Nautilus and caribou were running at full speed for 6 minutes, nautilus consuming 100% CPU, and caribou "only" 50%.

Reactivating all these 1000 LVs gets both applications running again.

The fact deactivating devices is causing memory going up suggests there is a huge leak - over 1MB in nautilus and 0.7MB in caribou for each activated/deactivated LV.

Activating the volumes back the leaks are much worse: 4M in nautilus and 1.8M in caribou per LV.

> 28616 mrtianc   20   0 6490804 5.334g   3052 S   0.0 35.2  20:20.58 nautilus
> 27886 mrtianc   20   0 3109652 2.407g    908 S   0.0 15.9  10:06.78 caribou

Comment 3 Ondrej Holy 2019-05-29 08:38:30 UTC
I don't have a suitable environment to test this right now, can you please confirm that this is still valid for RHEL 7.7?

Comment 4 Ondrej Holy 2020-01-09 15:13:20 UTC
Finally, I was able to run the reproducer on RHEL 7.7, but I don't see any memory leaks with nautilus-3.26.3.1-6.el7.x86_64, thus closing.


Note You need to log in before you can comment on or make changes to this bug.