On Mon, Jun 24, 2013 at 9:55 AM, David Strauss wrote:
> For example, you certainly wouldn't want the box to go into swap because of
> start-up allocation spikes.
I should clarify: that's not a context-switching example. It's just
another case where throttling might help.
--
David Strauss
| da
In our case, the issue wasn't kernel process creation; it was the CPU
and I/O overhead of service start-up. At some point, the system gets
dominated by context-switching, and throughput suffers. For example,
you certainly wouldn't want the box to go into swap because of
start-up allocation spikes.
On Thu, Jun 20, 2013 at 12:23 PM, Lennart Poettering
wrote:
> On Tue, 18.06.13 09:11, Daniel J Walsh (dwa...@redhat.com) wrote:
>
>> One concern we have is what will happen to systemd if we start 1000 services
>> at boot.
>>
>> systemctl start httpd_sandbox.target
>>
>> For example.
>>
>> Is there
On Tue, 18.06.13 09:11, Daniel J Walsh (dwa...@redhat.com) wrote:
> One concern we have is what will happen to systemd if we start 1000 services
> at boot.
>
> systemctl start httpd_sandbox.target
>
> For example.
>
> Is there anything we can do to throttle the start of so many unit files. Or
We have machines with thousands of containers on them. The key for us
was understanding that we didn't need thousands of containers to run
after start-up; we needed thousands of containers to be *accessible*
after start-up. The vast majority of our containers use socket
activation or "resurrection"
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
One concern we have is what will happen to systemd if we start 1000 services
at boot.
systemctl start httpd_sandbox.target
For example.
Is there anything we can do to throttle the start of so many unit files. Or
would systemd do something itself.
