From: Serge Hallyn <serge.hallyn@ubuntu.com>
To: Benoit Lourdelet <blourdel@juniper.net>,
linux-kernel@vger.kernel.org,
"Eric W. Biederman" <ebiederm@xmission.com>
Cc: lxc-users <lxc-users@lists.sourceforge.net>
Subject: Re: [Lxc-users] Containers slow to start after 1600
Date: Tue, 19 Mar 2013 15:34:22 -0500 [thread overview]
Message-ID: <20130319203422.GA27263@sergelap> (raw)
In-Reply-To: <CD6E73D8.71FE%blourdel@juniper.net>
Hi,
Benoit was kind enough to follow up on some scalability issues with
larger (but not huge imo) numbers of containers. Running a script
to simply time the creation of veth pairs on a rather large (iiuc)
machine, he got the following numbers (time is for creation of the
full number, not latest increment - so 1123 seconds to create 5000
veth pairs)
> >Quoting Benoit Lourdelet (blourdel@juniper.net):
> >> Hello Serge,
> >>
> >> I put together a small table, running your script for various values :
> >>
> >> Time are in seconds,
> >>
> >> Number of veth, time to create, time to delete:
> >>
> >> 500 18 26
> >>
> >> 1000 57 70
> >>
> >> 2000 193 250
> >>
> >> 3000 435 510
> >>
> >> 4000 752 824
> >>
> >> 5000 1123 1185
>
> Benoit
Ok. Ran some tests on a tiny cloud instance. When I simply run 2k tasks in
unshared new network namespaces, it flies by.
#!/bin/sh
rm -f /tmp/timings3
date | tee -a /tmp/timings3
for i in `seq 1 2000`; do
nsexec -n -- /bin/sleep 1000 &
if [ $((i % 100)) -eq 0 ]; then
echo $i | tee -a /tmp/timings3
date | tee -a /tmp/timings3
fi
done
(all scripts run under sudo, and nsexec can be found at
https://code.launchpad.net/~serge-hallyn/+junk/nsexec))
So that isn't an issue.
When I run a script to just time veth pair creations like Benoit ran,
creating 2000 veth pairs and timing the results for each 100, the time
does degrade, from 1 second for the first 100 up to 8 seconds for the
last 100.
(that script for me is:
#!/bin/sh
rm -f /tmp/timings
for i in `seq 1 2000`; do
ip link add type veth
if [ $((i % 100)) -eq 0 ]; then
echo $i | tee -a /tmp/timings
date | tee -a /tmp/timings
ls /sys/class/net > /dev/null
fi
done
)
But when I actually pass veth instances to those unshared network
namespaces:
#!/bin/sh
rm -f /tmp/timings2
echo 0 | tee -a /tmp/timings2
date | tee -a /tmp/timings2
for i in `seq 1 2000`; do
nsexec -n -P /tmp/pid.$i -- /bin/sleep 1000 &
ip link add type veth
dev2=`ls -d /sys/class/net/veth* | tail -1`
dev=`basename $dev2`
pid=`cat /tmp/pid.$i`
ip link set $dev netns $pid
if [ $((i % 100)) -eq 0 ]; then
echo $i | tee -a /tmp/timings2
date | tee -a /tmp/timings2
fi
rm -f /tmp/pid.*
done
it goes from 4 seconds for the first hundred to 16 seconds for
the last hundred - a worse regression than simply creating the
veths. Though I guess that could be accounted for simply by
sysfs actions when a veth is moved from the old netns to the
new?
0
Tue Mar 19 20:15:26 UTC 2013
100
Tue Mar 19 20:15:30 UTC 2013
200
Tue Mar 19 20:15:35 UTC 2013
300
Tue Mar 19 20:15:41 UTC 2013
400
Tue Mar 19 20:15:47 UTC 2013
500
Tue Mar 19 20:15:54 UTC 2013
600
Tue Mar 19 20:16:02 UTC 2013
700
Tue Mar 19 20:16:09 UTC 2013
800
Tue Mar 19 20:16:17 UTC 2013
900
Tue Mar 19 20:16:26 UTC 2013
1000
Tue Mar 19 20:16:35 UTC 2013
1100
Tue Mar 19 20:16:46 UTC 2013
1200
Tue Mar 19 20:16:57 UTC 2013
1300
Tue Mar 19 20:17:08 UTC 2013
1400
Tue Mar 19 20:17:21 UTC 2013
1500
Tue Mar 19 20:17:33 UTC 2013
1600
Tue Mar 19 20:17:46 UTC 2013
1700
Tue Mar 19 20:17:59 UTC 2013
1800
Tue Mar 19 20:18:13 UTC 2013
1900
Tue Mar 19 20:18:29 UTC 2013
2000
Tue Mar 19 20:18:48 UTC 2013
-serge
next parent reply other threads:[~2013-03-19 20:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20130319182829.GA15451@sergelap>
[not found] ` <CD6E73D8.71FE%blourdel@juniper.net>
2013-03-19 20:34 ` Serge Hallyn [this message]
2013-03-20 0:29 ` [Lxc-users] Containers slow to start after 1600 Eric W. Biederman
2013-03-20 20:09 ` Benoit Lourdelet
2013-03-20 20:38 ` Eric W. Biederman
2013-03-22 17:05 ` Benoit Lourdelet
2013-03-22 21:31 ` Eric W. Biederman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20130319203422.GA27263@sergelap \
--to=serge.hallyn@ubuntu.com \
--cc=blourdel@juniper.net \
--cc=ebiederm@xmission.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lxc-users@lists.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.