2015年3月12日

freeの出力が大幅改善された話

最近freeコマンドを叩くとこんな感じで出力されます。

$ free

              total        used        free      shared  buff/cache   available
Mem:       20209620     3859396     6594188      502492     9756036    15323144
Swap:      32767996           0    32767996

availableってなんでしょう? そして -/+ buffers/cache の行がなくなっています。

その背景をちらっと紹介します。

最近linuxの3.14で/proc/meminfo に MemAvailable というフィールドが追加されました。RHEL7.0や6.6にもバックポートされています。(RHEL6.6では互換性に配慮してデフォルトではdisableされています)
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

    /proc/meminfo: provide estimated available memory

    Many load balancing and workload placing programs check /proc/meminfo to
    estimate how much free memory is available.  They generally do this by
    adding up "free" and "cached", which was fine ten years ago, but is
    pretty much guaranteed to be wrong today.

    It is wrong because Cached includes memory that is not freeable as page
    cache, for example shared memory segments, tmpfs, and ramfs, and it does
    not include reclaimable slab memory, which can take up a large fraction
    of system memory on mostly idle systems with lots of files.

    Currently, the amount of memory that is available for a new workload,
    without pushing the system into swap, can be estimated from MemFree,
    Active(file), Inactive(file), and SReclaimable, as well as the "low"
    watermarks from /proc/zoneinfo.

    However, this may change in the future, and user space really should not
    be expected to know kernel internals to come up with an estimate for the
    amount of free memory.

    It is more convenient to provide such an estimate in /proc/meminfo.  If
    things change in the future, we only have to change it in one place.

    Signed-off-by: Rik van Riel 
    Reported-by: Erik Mouw 
    Acked-by: Johannes Weiner 
    Signed-off-by: Andrew Morton 
    Signed-off-by: Linus Torvalds 
このフィールドは「だいたいこのくらいはswap発生させずにアプリケーションがallcoateできそう」というメモリ量の推定です。
procps-ngに含まれるfreeコマンドがbuffer や cacheとして使われているメモリをfreeに足して表示する機能があった(過去形)ことも手伝って、これらを単純に全て「カーネルがパフォーマンス改善のために未使用メモリをうまいこと使っている」と見做してシステム管理している人が多くいます。しかしこの見方は正しくありません。buffer や cacheは非常に重要で、もしこれらが0になってしまえばシステムは全く稼動できないでしょう。どれくらい存在すれば十分なパフォーマンスがでるかも、アプリケーションの特性により非常に大きくかわります。

そこでもうちょっとましな推定値をつくろうということで導入されたのがMemAvailableです。現在の実装ではかならずしもカーネルの中でこの推定をする必要はないのですが、将来的にカーネルのメモリ管理のしくみが変わっても同じように利用できるよう追加されました。


さて、これにともなってprocps-ngも3.3.10で更新されています。このprocps-ng 3.3.10はRHEL7.1に含まれています。

availableフィールドを追加  https://gitorious.org/procps/procps/commit/ba6396f886f1a9911221e1c7c4b66dc75acb6948

MemAvailableがなくても同等の計算を他のフィールドからするfallback https://gitorious.org/procps/procps/commit/b779855cf15d68f9038ff1809db18c0788e9ae70

MemAvailableはあくまでざっくりした推定値なので、既存の統計情報を足したり引いたり適当な割り算をしたりして出しています。なので、その元になっているフィールドが提供されているlinux 2.6.27以降であれば同じような計算をしてavailableを出す機能です。
-----------------------------------------------------------
  /* zero? might need fallback for 2.6.27 <= kernel
  if (!kb_main_available) {
    if (linux_version_code < LINUX_VERSION(2, 6, 27))
      kb_main_available = kb_main_free;
    else {
      FILE_TO_BUF(VM_MIN_FREE_FILE, vm_min_free_fd);
      kb_min_free = (unsigned long) strtoull(buf,&tail,10);

      watermark_low = kb_min_free * 5 / 4; /* should be equal to sum of all 'low' fields in /proc/zoneinfo */

      mem_available = (signed long)kb_main_free - watermark_low
      + kb_inactive_file + kb_active_file - MIN((kb_inactive_file + kb_active_file) / 2, watermark_low)
      + kb_slab_reclaimable - MIN(kb_slab_reclaimable / 2, watermark_low);

      if (mem_available < 0) mem_available = 0;
      kb_main_available = (unsigned long)mem_available;
    }
  }
-----------------------------------------------------------
もはや不要となった free: remove -/+ buffers/cacheの削除  https://gitorious.org/procps/vnwildman-procps/commit/f47001c9e91a1e9b12db4497051a212cf49a87b1

そういうわけで、freeコマンドの出力が劇的に改善されたのでした。

2015年3月9日

RHELに機能拡張リクエストをだすためのノウハウ

RHELは当たり前のようにサポート窓口で機能拡張リクエストを受け付けるんですが、あまりそういうノウハウとか知られてない気がするのでメモ

ポリシー的に機能拡張が入れられるProduction 1の製品にリクエストを出す(今からならRHEL7)。

RHELにはライフサイクルポリシーがあります。この内機能拡張を入れることができるのはProduction 1とよばれる最初の4.5年間だけ。
今でているバージョンの次(時期によっては次の次)のバージョンがどのフェーズにあたるか確認すると無駄になりません。
Production 2以降では重大なバグの修正ならいいのですが機能拡張はポリシー上対応できません。

RHEL6のProduction1は2016年第2四半期におわるので、今から新規の機能をいれてと言うとほんとうにギリギリ。今からリクエストするならRHEL7が狙い目です。

できるだけ何をどうすればいいのか具体的にする(upstreamにパッチがあればそれを明記してとりこみをリクエスト) 

「それで結局何をどうしたいの?」というやりとりをやっている間に簡単に半年とかあっさり経過します。あらかじめ何をどうすればいいのか具体的なほうがよいです。

ただ自分でパッチを書くところは求められません。むしろupstreamのポリシーとずれたパッチをつくって「これ入れてくれ」というとあっさりrejectされてしまいます。対応方法ではなく目的がはっきりしていることが重要です。

リソースが潤沢にある場合にリクエストする側でできるベストの活動としては、upstreamのコミュニティに機能拡張を提案してパッチをつくりはじめ、並行してRHにリクエストをだす。というのがあります。なかなかここまでできるお客様はいらっしゃいませんが。。

そこまでできなくても「ぼくが欲しい出力のイメージはこんなの」みたいな例を書いてみるとか伝わりやすく工夫するのが大事です。

たくさんRH製品を買っている顧客の意見が重視されるのでたくさん買う(!)

文字通りです。レッドハットも商売なので。はははは。

自社ビジネスへのインパクトが大きいことを説明する

RHのサポートのあらゆる場面に言えることですが、基本的にインパクトが大きい人ほど優先して作業してもらえます。誰かの知的好奇心を満たすための説明や、審美眼的な問題、監視しづらいなどの理由だとないがしろにされ、サービスが停止してほんとうに困るという人が優先されます。

RH製品買ってない人はサポート窓口では対応できませんが  には書けます

普通はおすすめできないのですが、bugzillaにアカウントをつくって直接レポートするという手段もあります。ただしサポート窓口経由でないというだけで優先度は地の底まで下がります。製品を買っている人はサポート窓口経由でケースを開いた方が良いです。

顧客ではない場合、対応してもらえるという約束はありません。期待せずに待ちつづける根気が必要です。お客様のサポートのついでにチラ見してもらえるくらいの気持ちで。ありがちな問題であれば顧客が同じ問題にぶつかって対応してもらえることもあります。

あきらかなバグや問題でちょろいやつならbugzillaに直接レポートしても勝算はあります。upstreamのパッチとりこみで副作用がほとんどないとかですね。

なおbugzillaにいきなり書くときには「英語しか読めないエンジニアが直接読むのだ」ということを意識して、あらかじめ明らかなバグや修正まで問題をおとしておかないと「アカウント担当にいけ、ここはサポート窓口じゃないぞ」と言われてあっさりケースがcloseされます。

2015年3月4日

IPアドレスのvalid lifetime

ip addr とかで
3: em1: mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether d4:3d:7e:dc:c8:ad brd ff:ff:ff:ff:ff:ff
    inet 10.64.193.115/23 brd 10.64.193.255 scope global dynamic em1
       valid_lft 82874sec preferred_lft 82874sec
    inet6 fe80::d63d:7eff:fedc:c8ad/64 scope link
       valid_lft forever preferred_lft forever
みたいになっているとき、em1のアドレスに有効期限がついている。
valid_lft 82874secが有効期限の設定。
この期限が切れた時には、kworkerがアドレスを切り離す。


これを設定しているのは /usr/sbin/dhclient-script で、以下みたいなコードで設定している。
ip -4 addr add ${new_ip_address}/${new_prefix} broadcast ${new_broadcast_address} dev ${interface} \
valid_lft ${new_dhcp_lease_time}
preferred_lft ${new_dhcp_lease_time} >/dev/null 2>&1