David Touzeau put forth on 12/23/2010 5:40 PM:
> Many thanks Stan
You're welcome. Please note [1] at bottom.
> But to be honest, you document is very hard to understand... for my
> skills
> cpusets are set to create cpu tasks environnements
> my problem is to ensure that all postfix tasks will go into the defined
> cpuset filesystem
Forks, execs, and clones are handled automatically in cpusets. See #6
below.
> because if i set the first process "/usr/sbin/postfix start" to cpu 1
>
> it will run /usr/libexec/postfix/master
> according /usr/libexec/postfix/master will run /usr/libexec/postfix/qmgr
> and others tasks and depends of the SMTP behavior
For now, concentrate on section 1.9 at location 584 toward the bottom of
that doc and read to EOF. That should cover most/all of your questions
WRT implementation. Examples are provided. It's not complicated stuff.
If you understand Linux in general, and taskset, you'll easily digest
everything from line 662 on down.
> Have you a such set examples of command lines to cpuset or the commande
> line tool according postfix artchitecture ?
This is all covered in section 1.9 thru 2.3 starting at line 584. Quote:
"To start a new job that is to be contained within a cpuset, the steps are:
1) mkdir /dev/cpuset
2) mount -t cgroup -ocpuset cpuset /dev/cpuset
3) Create the new cpuset by doing mkdir's and write's (or echo's) in
the /dev/cpuset virtual file system.
4) Start a task that will be the "founding father" of the new job.
5) Attach that task to the new cpuset by writing its pid to the
/dev/cpuset tasks file for that cpuset.
6) fork, exec or clone the job tasks from this founding father task."
#6 is precisely why I recommend using cpusets for your needs. This
should eliminate the hassle of writing custom scripts to grab the PIDs
of all of Postfix' deamon processes that get started by master and then
manually binding their cpu affinity via taskset or runon. With cpusets
you only monkey with one PID.
If necessary you should be able to modify your Postfix startup scripts
to accomplish #5.
Trust me, cpusets is what you need to accomplish what you've asked for.
Read on. It's all there. If you get stumped, ask questions on LKML as
well as here. This is FLOSS, and free help is plentiful (if not always
prompt, but it usually is). :)
[1] HOWEVER, as Victor rightly pointed out, unless you have a real
_NEED_ for locking each Postfix instance to its own exclusive CPU/core,
such as certain types of SLAs, then don't bother with any of this. It's
a waste of time unless you really really have a _need_ for it. Postfix
isn't a CPU or memory bound application, but I/O bound, and mostly disk
I/O bound. There isn't a valid technical reason to justify your stated
desire. Not one that you have expressed here anyway.
What is your deployment requirement that is dictating the need to lock
each Postfix instance to an individual CPU? None of us can imagine a
realistic technical scenario which would require this. Is it technical?
If it's an SLA thing please state so.
Lastly, if there is a real world requirement for doing this on Linux
with Postfix, you cannot be the first one to need it, and thus someone
else has already done it with cpusets and you should be able to find it
documented somewhere, the world be such as it is these days.
--
Stan
