About this list Date view Thread view Subject view Author view Attachment view

From: Gregory (Grisha) Trubetskoy (grisha_at_ispol.com)
Date: Thu 21 Oct 2004 - 21:11:22 BST


As promised, here are my vsched findings. My set up is
util-vserver 0.30.195 and vs 1.9.3.

The token-bucket scheduler principle is pretty well explained here:

http://www.linux-vserver.org/index.php?page=Linux-VServer-Paper-06

vsched takes the following arguments:

    --fill-rate

         The number of tokens that will be placed in the bucket.

    --interval

         How often (the above specified) number of tokens will be placed.
         This is in jiffies. Through some googleing I've found references
         that a jiffy is about 10ms, but it seems to me it's less than
         that. Not sure if the CPU speed has bearing on it. (Anyone know?)

    --tokens

         The bucket starts out with this many tokens. Tokens_max takes
         precedence here, so it cannot be higher than tokens_max.

    --tokens_min

         When a bucket is empty, the context is on hold _until_ at least
         this many tokens are in the bucket.

    --tokens_max

         The size of the bucket. When tokens aren't being used, the bucket
         will be getting fuller and fuller, but up to this value. So in effect
         this is your CPU burst parameter.

    --cpu_mask

         This is obsolete, but I've found the current vsched is a little
         picky and will segfault if you omit parameters, so I always
         specified 0 here.

According to the VServer paper, "At each timer tick, a running process
consumes exactly one token from the bucket". Here running means actually
needing the CPU as opposed to "running" as in "existing". Most processes
are not running most of the time, e.g. an httpd waiting on a socket isn't
running, even though ps would list it.

A token is quite a bit of CPU time (again I'm not sure if this is CPU
speed dependent, my tests were on a 2.8GHz Xeon). Typing "python" on the
command line (which is a huge operation IMHO) consumes 17 tokens in my
tests. Having 100000 tokens in your bucket is probably sufficient for a
medium size compile job.

Here are some guidelines. All this is very much unscientific and without a
lot of testing and theory behind, so if someone has better quigelines,
please pitch in.

When trying to come up with a good setting in my environment (basically
hosting), I was looking for values that would not cripple the snappiness
of the server, but prevent people from being stupid (e.g. cat /dev/zero |
bzip2 | bzip2 | bzip2 > /dev/null).

The fill interval should be short enough to not be noticeable, so
something like 100 jiffies. The fill rate should be relatively small,
something like 30 tokens. Tokens_min seems like it should simply equal to
the fill rate. The tokens_max should be generous so that people can do
short cpu-intensive things when the need them, so something like 10000
tokens.

You can see current token stats by looking at

/proc/virtual/<xid>/sched

on the mother server. (If fill_rate is 115 no matter what you do, see my
vsched posting earlier in the list).

You can also use vsched to pace any cpu intensive command, e.g.:

vcontext --create -- \
   vsched --fill-rate 30 \
          --interval 100 \
          --tokens 100 \
          --tokens_min 30 \
          --tokens_max 200 \
           --cpu_mask 0 -- /bin/my_cpu_hog

While playing with this stuff I've run into situations where a context has
no tokens left, at which point you cannot even kill the processes in it.
Don't panic - you can always reenter the context and call vsched with new
parameters.

I think that's about it.

HTH,

Grisha
_______________________________________________
Vserver mailing list
Vserver_at_list.linux-vserver.org
http://list.linux-vserver.org/mailman/listinfo/vserver


About this list Date view Thread view Subject view Author view Attachment view
[Next/Previous Months] [Main vserver Project Homepage] [Howto Subscribe/Unsubscribe] [Paul Sladen's vserver stuff]
Generated on Thu 21 Oct 2004 - 21:11:38 BST by hypermail 2.1.3