Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Gitea growing memory usage when unused #753

Closed
1 of 3 tasks
jmn opened this issue Jan 25, 2017 · 23 comments
Closed
1 of 3 tasks

Gitea growing memory usage when unused #753

jmn opened this issue Jan 25, 2017 · 23 comments
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail

Comments

@jmn
Copy link

jmn commented Jan 25, 2017

  • Gitea version (or commit ref): 1.0.0+133-gd2bb8ef5
  • Operating system: Docker image, gitea/gitea@sha256:dd2212f37ca2f4db03f7018fad062adbe8801f1c96d77af9c10d245e97e0a99d
  • Database (use [x]):
    • PostgreSQL
    • MySQL
    • SQLite

Description

I am since yesterday measuring memory usage on Gitea running with no user activity and here is a graph showing memory usage and the memory usage is growing what I view as quite heavily over time. Perhaps all is in order, perhaps I have not configured something correctly.

image

--- Want to back this issue? **[Post a bounty on it!](https://www.bountysource.com/issues/41307699-gitea-growing-memory-usage-when-unused?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F47456670&utm_medium=issues&utm_source=github).
@thibaultmeyer
Copy link
Contributor

Do you have the same issue with another Database backend ?

@jmn
Copy link
Author

jmn commented Jan 25, 2017

Very good question, will try and check that and come back.

@metalmatze
Copy link
Contributor

That pretty much looks like a memory leak. Would be interesting to start debugging with pprof, but one would have to include that themselves IIRC.

@jmn
Copy link
Author

jmn commented Jan 27, 2017

OK the problem seems to have been that I was just naively using the default configuration of sessions in the gitea.ini from the image gitea/gitea@sha256:dd2212f37ca2f4db03f7018fad062adbe8801f1c96d77af9c10d245e97e0a99d

and it turned out that sessions file storage very quickly grew out of hand because no SESSION_LIFE_TIME or GC_INTERVAL_TIME was set.

[session]
; Either "memory", "file", or "redis", default is "memory"
PROVIDER = file
PROVIDER_CONFIG = data/sessions
; Session GC time interval, default is 86400
; GC_INTERVAL_TIME = 86400
; Session life time, default is 86400
; SESSION_LIFE_TIME = 86400

@bkcsoft
Copy link
Member

bkcsoft commented Jan 28, 2017

@metalmatze Would be fairly simple to add pprof-http-service just like with prometheus, though would obviously need to be locked down 😛

@metalmatze
Copy link
Contributor

Yes. I now tried to find something on my local system, but I'm not able to.
Probably some config flag to turn on pprof listening on http://localhost:6060 would be nice, I guess.

@lunny
Copy link
Member

lunny commented Jan 30, 2017

@jmn so this is only a configuration problem?

@metalmatze
Copy link
Contributor

I started to add pprof to gitea yesterday and will continue to make a PR today evening. I would really like you to check gitea with pprof after a day running or so. I will do the same.

@thibaultmeyer
Copy link
Contributor

thibaultmeyer commented Jan 30, 2017

[OFF-TOPIC] Nice chart @jmn, what monitoring tools are your using?

@metalmatze
Copy link
Contributor

The UI is definitely grafana. (github)

@tboerger tboerger added the type/enhancement An improvement of existing functionality label Feb 10, 2017
@tboerger tboerger added this to the 1.1.0 milestone Feb 10, 2017
@jmn
Copy link
Author

jmn commented Feb 11, 2017

@jmn so this is only a configuration problem?

I think so yes. However, I think it would be good to try and provide default values and recommendations which try to prevent users from shooting themselves in the foot. E.g. not unlimited session lifetime with memory storage as default.

@lunny
Copy link
Member

lunny commented Feb 23, 2017

I will move this to v1.2 since no further information here.

@lunny lunny modified the milestones: 1.2.0, 1.1.0 Feb 23, 2017
@lunny lunny modified the milestones: 1.x.x, 1.2.0 Apr 20, 2017
@DrMegavolt
Copy link

DrMegavolt commented Jul 2, 2018

It is not only the case for memory provider
If you set file provider. Gitea will start creating a ton of session files. RAM is fine in this case but it quickly takes all inodes available (df -i shows 100% )

@DrMegavolt
Copy link

And to clarify we have a lot of AdminAPI calls and access to git via ssh. Nobody really uses web admin. The question is why sessions are needed at all?

@bkcsoft
Copy link
Member

bkcsoft commented Jul 3, 2018

@DrMegavolt That would be a separate issue (even though slightly related). Please create one so we can track them separetely 🙂

@lunny
Copy link
Member

lunny commented Nov 7, 2018

Maybe related with #4450 ?

@lafriks
Copy link
Member

lafriks commented Nov 8, 2018

@lunny I don't think that is related
@jmn is this still a problem in latest version

@lafriks
Copy link
Member

lafriks commented Nov 8, 2018

I'm closing issue currently, please reopen if it is still a problem in latest version

@lafriks lafriks closed this as completed Nov 8, 2018
@lafriks lafriks removed this from the 1.x.x milestone Nov 8, 2018
@lafriks lafriks added issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail and removed type/enhancement An improvement of existing functionality labels Nov 8, 2018
@poVoq
Copy link

poVoq commented Sep 23, 2019

Running with Docker and Mysql I seem to have a similar issue, both on 1.9.3 and the "latest" image. Might have been there before, but I didn't notice.
I don't have a nice graphic for it, but within a few days the memory use of the container doubles.

@kfreidank
Copy link

Just installed built and installed 1.11.5 on Rasbian Pi3. All memory is immediately used. No sessions in process. Just one user account added, no repositories. Postgres on the backend.psql (PostgreSQL) 11.7 (Raspbian 11.7-0+deb10u1)
go version go1.11.6 linux/arm
Powered by Gitea Version: 1.11.5+11-ga854846f0

top - 13:20:46 up 5 days, 44 min, 1 user, load average: 0.00, 0.03, 0.00
Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.7 us, 0.6 sy, 0.0 ni, 98.8 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
MiB Mem : 926.1 total, 95.9 free, 200.9 used, 629.3 buff/cache
MiB Swap: 1872.0 total, 1846.2 free, 25.8 used. 628.0 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1689 couchdb 20 0 117156 30560 7892 S 1.3 3.2 195:35.94 beam.smp
19027 solomon 20 0 10292 2960 2460 R 1.0 0.3 0:01.71 top
24945 gitea 20 0 1001208 122304 40100 S 1.0 12.9 18:28.23 gitea <----------- took it all
21 root 20 0 0 0 0 S 0.3 0.0 0:11.15 ksoftirqd/2

@Flashlord
Copy link

I confirm gitea took 380Mb of memory without doing anything !

@fanlix
Copy link

fanlix commented Nov 2, 2020

330M mem usage for fresh install

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
12789 pi        20   0 1068880 331784  69200 S   0.7  17.5   0:14.17 /app/gitea/gitea web 

600M mem usage after first push.

  • repo of 100 commits and total size 30M
  • call go gc
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
12789 pi        20   0 1339744 599676  70492 S   1.3  31.6   0:47.65 /app/gitea/gitea web

admin-usage

System Status
Server Uptime
22 minutes, 33 seconds
Current Goroutines
112
Current Memory Usage
205 MiB
Total Memory Allocated
2.8 GiB
Memory Obtained
604 MiB
Pointer Lookup Times
0
Memory Allocations
3924943
Memory Frees
3083970
Current Heap Usage
205 MiB
Heap Memory Obtained
575 MiB
Heap Memory Idle
355 MiB
Heap Memory In Use
220 MiB
Heap Memory Released
123 MiB
Heap Objects
840973
Bootstrap Stack Usage
1.2 MiB
Stack Memory Obtained
1.2 MiB
MSpan Structures Usage
1.2 MiB
MSpan Structures Obtained
1.7 MiB
MCache Structures Usage
6.8 KiB
MCache Structures Obtained
16 KiB
Profiling Bucket Hash Table Obtained
1.6 MiB
GC Metadata Obtained
24 MiB
Other System Allocation Obtained
1.1 MiB
Next GC Recycle
401 MiB
Since Last GC Time
112.0s
Total GC Pause
0.0s
Last GC Pause
0.000s
GC Times
30
  • pi4b 2Gb raspbian-64bit-2020.8
  • gitea 1.14.0 sqlite

@zeripath
Copy link
Contributor

zeripath commented Nov 2, 2020

If you really want to investigate:

ENABLE_PPROF = true in [server] and use:

go tool pprof http://localhost:6060/debug/pprof/heap

and it's web function to show where the memory is being used.

Then compare between the two.

@go-gitea go-gitea locked and limited conversation to collaborators Nov 24, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
issue/needs-feedback For bugs, we need more details. For features, the feature must be described in more detail
Projects
None yet
Development

No branches or pull requests