Hi Stéphane, On 05/30/13 15:33, Stéphane Graber wrote: > > That's already covered by my proposal and I believe covered in the use > cases listed within it. > > "lxc-stop -g any" > > That'll stop all containers that are in the "any" group. "any" is > documented as being a special group that contains all containers even if > they have lxc.group set. >
My appologies, I have missed that. If LXC relies upon a special group to stop containers, wouldn't it be more consistent to use an "autostart" group, too? >> And one question: >> >> Do lxc-start -a ... and lxc-stop -a ... start/stop all LXC >> containers in parallel, if their order and group are the >> same? I am concerned about accumulating timeouts or delays >> at shutdown or startup time of the host. > > The usual STOPPED => RUNNING or RUNNING => STOPPED time is < 1s, so no, > we'll be doing that in serial order, but you won't really notice it > because of how quick it's. > Sorry, but I disagree in this case. Surely the containers start init very fast, but on shutdown time lxc-stop has to wait for _all_ processes running in the container. Some Java webapps might take an awful lot of time to stop (just as an example, meaning no offense to the Java folks). The LXC server might have 16 cores or more. Its more efficient if the containers are triggered to shut down in parallel, instead of shutting down one after the other, while the rest is still using up their own CPU time and keep the disks busy. If we assume a LXC server running 30 containers in parallel, and if every container needs 10 seconds to stop (this is not uncommon), then this means 5 minutes downtime just to stop all services. > That's assuming lxc.start.delay isn't set. If it's set, then obviously > startup will take longer because we'll wait of lxc.start.delay before > starting the next container (parallelizing would make the whole > priority/delay idea completely pointless obviously). > Thats not obvious at all. The containers might have different order numbers. Only the containers with the same order number should be started (or stopped) in parallel. Lxc could wait for the largest start delay, before starting the next set of containers with the next order number. Regards Harri ------------------------------------------------------------------------------ Introducing AppDynamics Lite, a free troubleshooting tool for Java/.NET Get 100% visibility into your production application - at no cost. Code-level diagnostics for performance bottlenecks with <2% overhead Download for free and get started troubleshooting in minutes. http://p.sf.net/sfu/appdyn_d2d_ap1 _______________________________________________ Lxc-devel mailing list Lxc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lxc-devel
