git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: Excessive mmap [was Git server eats all memory]

From
IKIvan Kanis <expire-by-2010-08-14@kanis.fr>
Date
Aug 9, 2010, 16:34 UTC
Message-ID
<westyn3n3sa.fsf@kanis.fr>
In-Reply-To
<AANLkTi=6JcwLuyNWq9oYzE_E+7DSn-sEvR-X3AHvXM6U@mail.gmail.com>
Dmitry Potapov <dpotapov@gmail.com> wrote:
> Though Git uses MAP_PRIVATE with mmap, this only marks mapped pages as
> copy-on-write. Because cloning does not change the pack file, all those
> pages should be shared.

I reran the test today. One client is receiving while the other one is compressing. I have to interrupt both client because the server is becoming unusable. I am sure you are right about sharing the pages but I can't test it.

> On 64-bit architecture, you have plenty virtual space, and mapping
> a file to memory should not take much physical memory (only space
> needed for system tables). 

What I can tell from the mmap man page is that it should map memory to a file. I assume it shouldn't take up physical memory. However I am seeing physical memory being consumed. It might be a feature of the kernel. Is there a way to turn it off?

> You can reduce core.packedGitWindowSize in the Git configuration to
> see if it helps, but I doubt that it will have any noticeable effect.
It was worth a shot, it didn't help...

Looking some more into it today the bulk of the memory allocation happens in write_pack_file in the following loop.

for (; i < nr_objects; i++) {
    if (!write_one(f, objects + i, &offset))
        break;
    display_progress(progress_state, written);
}

This eventually calls write_object, here I am wondering if the unuse_pack function is doing its job. As far as I can tell it writes a null in memory, that I think is not enough to reclaim memory.

I also looked at the use_pack function where the mmap is happening. Would it be worth refactoring this function so that it uses an index withing a file instead of mmap?

Unless I hear of a better idea I'll be trying that tomorrow...
Take care,
-- 
Ivan Kanis

I can stand brute force, but brute reason is quite unbearable.  There
is something unfair about its use. It is hitting below the intellect.
    -- Oscar Wilde 
Previous: Dmitry PotapovNext: Avery Pennarun
Message 14 of 28 in “Git server eats all memory”
  1. Ivan KanisAug 4, 2010
  2. Matthieu MoyAug 4, 2010
  3. Ivan KanisAug 4, 2010
  4. Avery PennarunAug 4, 2010
  5. Ivan KanisAug 5, 2010
  6. Jared HanceAug 5, 2010
  7. Nguyen Thai Ngoc DuyAug 6, 2010
  8. Nguyen Thai Ngoc DuyAug 6, 2010
  9. Jakub NarebskiAug 6, 2010
  10. Ivan KanisAug 6, 2010
  11. Dmitry PotapovAug 7, 2010
  12. Excessive mmap [was Git server eats all memory]Ivan Kanis, Aug 9, 2010
  13. Dmitry PotapovAug 9, 2010
  14. Ivan KanisAug 9, 2010
  15. Avery PennarunAug 9, 2010
  16. Tomas CarneckyAug 9, 2010
  17. Avery PennarunAug 9, 2010
  18. Dmitry PotapovAug 9, 2010
  19. Ivan KanisAug 11, 2010
  20. Avery PennarunAug 11, 2010
  21. Duy NguyenJun 20, 2018
  22. Robin H. JohnsonAug 10, 2010
  23. Sverre RabbelierAug 10, 2010
  24. Sam VilainAug 11, 2010
  25. Ivan KanisAug 11, 2010
  26. Nguyen Thai Ngoc DuyAug 9, 2010
  27. Ivan KanisAug 9, 2010
  28. Dmitry PotapovAug 17, 2010

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.