[DGD] swapout tuning

Shentino shentino at gmail.com
Thu Aug 25 05:25:34 CEST 2011


On Wed, Aug 24, 2011 at 1:57 PM, Felix A. Croes <felix at dworkin.nl> wrote:
> Working set size will vary during the day for a running mud.  Unless your
> notion of working set is sufficiently flexible, you could end up with
> something that has worse performance (cache_size in DGD has very little
> to do with the size of the working set).

I must admit that in these uncharted waters I'm currently in the "ooh
look at those shiny flashy numbers" stage.  Which does remind me that
I'm also pondering runtime tuning.

Two scenarios that I have noticed are difficult to achieve though with
a simple swap fragment, since the needed "x intercept" of the swap
rate graph doesn't intersect zero:

1.  A steady trickle of objects out of dmem and into swap.

Letting the swapper "nibble" on a steady diet of stale objects might
well be gentler on the disk than aggressive swapouts meant to avoid
the disadvantage cited in case 2.

2.  A logical number of objects that are exempt from swap churn and
given some elbow room in dmem without having overages therein slow in
eviction.

My hypothesis is that this is useful if you have a fixed-ish number of
objects that are constantly busy (think mobs, players, and the objects
they frequently interact with) and which would find themselves simply
thrashing in and out of swap if they were sent out prematurely.

Increasing swap fragment to take into account this set has an
undesired side effect of less aggressive handling of objects that go
over this imaginary quota and are effectively dead weight, while
decreasing swap fragment to give overflows speedier stashing also
decreases the effective working set size.

> The biggest drawback of swap_fragment is that the way it relates to the
> swap rate is unintuitive.  Making something that is easier to understand
> and manage should be your primary design goal.

This has crossed my mind.

Especially since you get 1/frag per task and not any fixed unit of
time, which has the side effect of tying swapout load to mud activity.

To compensate for this, I have an object called sparkd in System that
does nothing but callout itself.  It's sole purpose is to provoke
steady swapping.



More information about the DGD mailing list