On Fri, Mar 12, 2010 at 12:41 PM, Rafael Tinoco <[email protected]> wrote: > On Fri, Mar 12, 2010 at 4:09 AM, Balbir Singh <[email protected]> > wrote: >> On Fri, Mar 12, 2010 at 12:32 PM, Rafael Tinoco >> <[email protected]> wrote: >>> I'll be participating on this list. Just subscribed. Thanks for the >>> quick answer. >>> >>> I have lots and lots of web servers (4000 almost). Just started on >>> this hosting company. >>> I was a Sun employee and worked with Solaris 10 resource manager for >>> years (well since the beginning). >>> >>> The situation is the following: >>> >>> - We are using several mods for apache, migrating from user "httpd" to >>> the user id based on vhosts. >>> - When migration, the libcg daemon is listening to the netlink events >>> (new procs) and changing them to their cgroup >>> >>> (Unfortunately the httpd thread itself cannot start with the user id, >>> but Ive separated the httpd for some cpus, and after getting the user >>> id (with SUPHP, or fastcgi for example) (setuid maybe ?) they are >>> moving to the right cpuset) >>> >> >> Not sure I understand what you say here? You extract the userid on >> behalf of whom each httpd thread/process is running? > > Yep, lots of apache modules can "change" the process id based on > vhosts configured for apache user. > >> >>> Im migration all "users" on their own cgroup (inside several cpusets), >>> confining them on 1 or 2 cpus. (having 10 groups of 1 cpu each) >>> >>> Why create one cgroup for each user ? Im worried about "confining" 1 >>> fake node memory block per cpuset and limiting users (all user >>> processes) to a maximum of 512M of ram. >>> >>> Any better way of doing this ? >> >> Have you considered the cgroups CPU and Memory controller? We also >> have block I/O and network controller in place. > > Example: > > group webserver/grupo7/testeemailgb7 { > perm { > task { > uid = testeemailgb7; > gid = testeemailgb7; > } > admin { > uid = root; > gid = root; > } > } > cpuset { > cpuset.cpus = 8; > cpuset.mems = 8; > cpuset.sched_load_balance = 0; > } > cpu { > cpu.shares = 256; > } > memory { > memory.soft_limit_in_bytes = 134217728; > memory.limit_in_bytes = 268435456; > memory.memsw.limit_in_bytes = 104857600; > } > } >
Yeah, this look good. BTW, were you able to solve the original problem of 10311 groups? Balbir Singh. ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Libcg-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/libcg-devel
