Issue #702 closed

Abnormal memory usage with thg > 2.0

xumix
created an issue

Strating with 2.0 thg has become a resource hog. See screenshot. With thg 1.1.x it was consuming at most 100mb in total My mercurial.ini

{{{

!ini

[patch] eol = auto

[extensions] color = children = graphlog = convert = extdiff = highlight = progress = eol = keyword = mq = transplant = rebase = mercurial_keyring = bookmarks = fetch =

hggit=c:\Program Files (x86)\TortoiseHg\extensions\hggit

[ui] merge = araxis

[tortoisehg] vdiff = araxis authorcolor = True diffcolorstyle = foreground changeset-expander = False longsummary = True tabwidth = 4 fullpath = True stderrcapt = True postpull = update cipushafter = default issue.regex = (\w+-\d+) issue.link = http://192.168.121.110:8080/browse/{1}

[http_proxy] host = 192.168.121.150:8080 no = 192.168.121.110,sdkdev

[diff] git = True nodates = False

[keyword] .txt = .cs = **.rdl =

[keywordmaps] Rev = {rev} [keywordset] svn = True

[gtools] fontdiff = Consolas 11 fontlog = Consolas 11 fontcomment = Consolas 11

}}}

Comments (22)

  1. xumix reporter

    I'have 14 repos in the repo registry, 2-4 repos opened in tabs. Version 2.0.4 x64 It looks like mem leak, because memory amount grows with time. When just opened thg uses 50Mb, then it grows. So does overlay server.

  2. Adrian Buehlmann

    Some mercurial devs laugh at me when I mention object cycles, but I wouldn't be surprised if we got some new ones there. At least I do have some deja vu feelings. Or perhaps it's one of the extensions.

  3. Adrian Buehlmann

    Trying 1.1.10 would be interesting.

    After further pondering: IIUC, the overlay server doesn't load any extensions, so I think we can assume it's not caused by an extension.

    Another experiment would be to try a unstable build (upcoming Mercurial 1.9 / TortoiseHg 2.1, due on July 1st): https://bitbucket.org/tortoisehg/thg-winbuild/downloads/

    I think I eliminated at least one object cycle in mercurial there. I'm using TortoiseHg unstable myself.

  4. xumix reporter

    THG 2.1.3 Still the same, Thg uses up to 1.5 Gb, Overlay server up too 500Mb. Any way to profile the application?

  5. Anonymous

    guys, you really messed it up... me too has up to 1 GB, the applications i _very_ slow to start, my coworkers are having the same problem. We have a very large repo, some 2 years history (30k changesets). A while ago this took maybe 200MB, now up to 1 GB when I do soemthing in the UI. Restarting thg didn't help.

    We use mainly Win7 64bit machines, any way to profile this? Unfortunately giving you the dumpts would be out of question, but how could we help analysing this?

  6. Yuya Nishihara

    xumix Thanks for the info. Could you provide more detail?

    • Is it the number of thgw.exe or overlay server?
    • If the memory usage grows, what operation significantly increases it?
    • Are you using third-party extensions like hgsubversion or hggit?
  7. xumix reporter

    Here is my config. This is the number for thg.exe, the memory usagemainly grows after pull+updating of many repos. I have at least 20 of them. I do use hg-git, but the memory usage is the same without them.

    [patch]
    eol = auto
    
    [extensions]
    color =
    children = 
    graphlog = 
    convert = 
    extdiff = 
    highlight = 
    progress =
    eol = 
    keyword = 
    mq = 
    rebase = 
    mercurial_keyring = 
    bookmarks = 
    fetch = 
    purge = 
    
    [ui]
    merge = araxis
    username = xumix
    commitsubrepos = True
    
    [tortoisehg]
    vdiff = araxis
    authorcolor = True
    diffcolorstyle = foreground
    changeset-expander = False
    longsummary = True
    editor = c:\Program Files (x86)\ToTaLCmD\EmEditor\EmEditor.exe
    tabwidth = 4
    fullpath = True
    stderrcapt = True
    postpull = update
    issue.regex = (\w+\-\d+)
    issue.link = http://192.168.121.110:8080/browse/{1}
    refreshwdstatus = always
    
    [http_proxy]
    host = 
    no = 192.168.121.110,sdkdev
    
    [diff]
    git = True
    nodates = False
    
    [keyword]
    **.txt = 
    **.cs = 
    **.rdl = 
    
    [keywordmaps]
    Rev = {rev}
    [keywordset]
    svn = True
    
    [gtools]
    fontdiff = Consolas 11
    fontlog = Consolas 11
    fontcomment = Consolas 11
    
  8. Yuya Nishihara

    cmdui: disown used CmdThread on finish so that it can be removed (refs #702)

    cmdui.Core creates new thread on each runNext(), and it's owned by the parent widget. Thus, it won't be freed until the parent widget is closed.

    This reduces memory usage a little, but still garbages seem to exist.

    → <<cset 65e3b80ded12>>

  9. Yuya Nishihara

    We've fixed several circular reference problems in thg, resource leak in overlay server (#3223), isolated Mercurial command process, etc. I hope some of them had good effect on this issue.

    If the memory use still increases drastically, please reopen.

  10. Log in to comment