RHEL6のドキュメントページ（※）みてたのだけど

※ http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/

Technical Notes: http://docs.redhat.com/docs/en-US/Red_Hat_Enterprise_Linux/6/html-single/Technical_Notes/index.html に面白いチューニングパラメタの記述をみつけたので解説してみる。S390向けのチューニング推奨値の部分だ

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

System z Performance

Some of the default tunables in Red Hat Enterprise Linux 6 are currently not optimally configured for System z workloads. Under most circumstances, System z machines will perform better using the following recommendations.

Dirty Ratio

It is recommended that the dirty ratio be set to 40 (Red Hat Enterprise Linux 6 default 20) Changing this tunable tells the system to not spend as much process time too early to write out dirty pages. Add the following line to /etc/sysctl.conf to set this tunable:

 
vm.dirty_ratio = 40

Scheduler

To increase the average time a process runs continuously and also improve the cache utilization and server style workload throughput at minor latency cost it is recommended to set the following higher values in /etc/sysctl.conf.

 
kernel.sched_min_granularity_ns = 10000000
kernel.sched_wakeup_granularity_ns = 15000000
kernel.sched_tunable_scaling = 0
kernel.sched_latency_ns = 80000000

Additionally, deactivating the Fair-Sleepers feature improves performance on a System z machine. To achieve this, set the following value in /etc/sysctl.conf

 
kernel.sched_features = 15834234

False positive hung task reports

It is recommended to prevent false positive hung task reports (which are rare, but might occur under very heavy overcommitment ratios). This feature can be used, but to improve performance, deactivate it by default by setting the following parameter in /etc/sysctl.conf:

 
kernel.hung_task_timeout_secs = 0

ーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーーー

このへん、実のところ特殊なハードに依存した部分は一切無い。S390が標準環境だと仮定しているのはようするに

・仮想環境前提。仮想環境ではCPU能力に比べてメモリ量がプアになりがち。
CPUはゲスト間でダイナミックに譲り合いができるけど、メモリ使用量減らすのは大変だから
・バッチジョブ。IO性能を限界まで酷使するようジョブを大量につめこむ。ここのジョブの処理時間は
反応速度はどうでもいい。全体のスループット重要

そこを踏まえると

・Dirty ratio: そもそもRHEL5で40だったdirty ratioがRHEL6で20に減っているのは、レスポンス速度向上の
ためである。現在デスクトップでもメモリが4Gとかあるので、4G x 0.4 だと1.6Gで大きすぎる。これが
Xがガタつく原因だーってLinusが主張して強権発動で一回5%まで落ちて、その後数々のregression報告に
対応する形で 5 → 10 → 20 と段階的に数値が戻ってきた経緯がある。

１）バッチジョブばかり流すとわかっているならレスポンス速度は重要じゃない
２）仮想環境だとCPUは潤沢だけどメモリ512Mとか普通にあるので、20%だと100Mとかなくて簡単に制限にあたってしまう。なので、RHEL5から性能劣化するジョブが沢山検出される

とかそういう事態になり、RHEL5と同じ数値を推奨する経緯になったと思われる

・スケジューラ関係も同じ。レスポンス時間が重要では無いなら、コンテキストスイッチの回数を減らして
一回一回のタイムスライスを増やす作戦が有効。sched_latency_nsがまさにそのためのパラメタで
若干特殊な場合に使われる補助パラメタ、sched_min_granularity_ns, sched_wakeup_granularity_nsも
似たような割合で増やしている。

・kernel.sched_tunable_scaling は特殊なパラメータでスケジューラのレイテンシターゲットとかそのへんの
値はCPU数依存なので、CPUを抜き差しすると変動する。仮想環境なら負荷に応じてCPU数変えたいよね！
なんだけど、CPUが増減したときにどのぐらいレイテンシターゲットをいじるかってのは、まあ、ポリシーが
いろいろあるでござる。デフォルト（sched_tunable_scaling=1)ではレイテンシターゲットがCPU数に
log比例するようになっている。でこれを０にするとCPU数を無視するようになって手動で指定した
sched_latency_ns 通りに動くので、まあ分かりやすい挙動になる。どうせS390でCPU 1000個のマシンとか
ないので分かりやすさ優先でいいという判断なのだろう。あと、CPU増やしたときに増やしたCPUまったく
使ってないはずなのに、ジョブの性能が変わるとアドミンが発狂するのでその対処と言うことだろうか

・kernel.sched_features = 15834234 は何を言っているのか分からないマジック値に見えると思うが、
これはビットマスクでデフォルト値が 15834235 なの。ようするに最下位１ビットをOFFにしてるという
意味。最下位ビットは linux/kernel/sched_features.h を見ると

/*
 * Only give sleepers 50% of their service deficit. This allows
 * them to run sooner, but does not allow tons of sleepers to
 * rip the spread apart.
 */
SCHED_FEAT(GENTLE_FAIR_SLEEPERS, 1)

となっていて使用箇所は

static void
place_entity(struct cfs_rq *cfs_rq, struct sched_entity *se, int initial)
{
        u64 vruntime = cfs_rq->min_vruntime;

        /*
         * The 'current' period is already promised to the current tasks,
         * however the extra weight of the new task will slow them down a
         * little, place the new task so that it fits in the slot that
         * stays open at the end.
         */
        if (initial && sched_feat(START_DEBIT))
                vruntime += sched_vslice(cfs_rq, se);

        /* sleeps up to a single latency don't count. */
        if (!initial) {
                unsigned long thresh = sysctl_sched_latency;

                /*
                 * Halve their sleep time's effect, to allow
                 * for a gentler effect of sleepers:
                 */
                if (sched_feat(GENTLE_FAIR_SLEEPERS))
                        thresh >>= 1;

                vruntime -= thresh;
        }

        /* ensure we never gain time by being placed backwards. */
        vruntime = max_vruntime(se->vruntime, vruntime);

        se->vruntime = vruntime;
}

ようするに、sleepタスクが起床時にもらうタイムスライスボーナスが
GENTLE_FAIR_SLEEPERS=1(default)だとsysctl_sched_latency/2 で
GENTLE_FAIR_SLEEPERS=0だと sysctl_sched_latency になるということ。
なんで、これがバッチジョブ有利になるのかはちょっと分からなかった。

・最後は一番しょーもなくて、hung_task_timeout_secs という機能はプロセスのハングアップ監視を
してくれる機能なんだけど、バッチジョブをぎゅうぎゅうに詰めるとfalse positiveが頻発するので
disableにしてる。というかサーバOSなんだからデフォルトdisableでもよかったんじゃないかなぁ



こんな感じでした。チューニングパラメタの検討をするときの参考になれば幸いです。

関連記事

• VFSのメンテナがChristoph Hellwigに交代 (2011/04/25)
• RHEL6 S390用チューニングパラメタ推奨値解説 (2011/04/13)
• Fedora14でログイン画面の壁紙を変える方法 (2011/04/11)