pmap -x 1
1: /sbin/init
Address Kbytes RSS Dirty Mode Mapping
7f9799767000 0 16 0 r-x-- libnss_files-2.15.so
7f9799773000 0 0 0 - libnss_files-2.15.so
7f9799972000 0 4 4 r libnss_files-2.15.so
7f9799
@jamesodhunt: Please let me know what information I should provide (the
output of specific commands and content of specific logs).
I don't think the init is supposed to use 50 MB of RAM or more forever
after running 5000 containers or less - even after CPU goes down to 1-2%
for the init process. T
@uj__:
> The init process is certainly leaking memory.
How have you proved that init is leaking memory? Can you say that PID 1 is not
just still busy processing the flurry of events that would result from starting
all these docker containers? Please provide further details.
> I've looked at the
The init process is certainly leaking memory. This can be observed by
starting a lot of Docker containers which exit right away. I'm able to
get upstart's init process to 50-100 MB of memory usage by running
5000-2 Docker containers which only print something and then exit.
I've looked at the
As a control I have been hammering a trusty system with a continuious
stream of synthetic memory events and see no change in the RSS for
upstart-udev-bridge. There is clearly some subtlety here. In some
cases it seems clear there is a large and valid queue of pending work,
which may account for t
This almost sounds like bug 1235649, but unlikely given that the
upstart-udev-bridge uses the correct NIH D-Bus calls.
I suspect the reason for the memory growth is that the events that are
being created cannot be destroyed until some other job has finished with
them. Once that happens, memory wil
** Changed in: upstart (Ubuntu)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1198180
Title:
possible leak in upstart 1.5
To manage notifications about this bug g
Update: I've found another memory-hog, the upstart-udev-bridge. Looks
like stopping it (sudo stop upstart-udev-bridge) also stops memory
leaking in the upstart (init) process.
$ pmap -x 368
368: upstart-udev-bridge --daemon
Address Kbytes RSS Dirty Mode Mapping
I confirm this behaviour.
I use lxc for testing purposes. For each set of tests a few containers are
created. Lifetime span is about a few seconds, and the tests are beeing run one
after another continuously. After a few days init takes more than 2GB of
memory. What's interesting - after stoppin
Status changed to 'Confirmed' because the bug affects multiple users.
** Changed in: upstart (Ubuntu)
Status: New => Confirmed
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1198180
Title:
po
To clarify: we have about 200-300 containers running simultaneously, and
the average lifetime of a single container is 2-10 mins; the network
interfaces are also destroyed when the container goes down. So, in a
specific point in time, we have about 200-300 network interfaces, and
they're created an
Approximately how many running jobs do you have after you've created 40k
containers? If you stop all those network interfaces, is the memory
reclaimed?
Please provide further details so we can investigate more fully.
--
You received this bug notification because you are a member of Ubuntu
Bugs,
12 matches
Mail list logo
