swap file と swap partition のパフォーマンス比較

Linux

サーバ屋の友人から、「客に突然swap増やしてと言われて困ってるんだけど、swap file でいいと思う？」と聞かれたのでgoogle様でプチ調査。とりあえず、次の２サイト:


が参考になりそうなので、読んでみた。


Linux (kernel 2.4) の場合、基本的には、swap file より swap partition のほうがパフォーマンスが良いという意見が多い。

> No need to waste a partition for swap space. Just make a swap file.

A swap file is good to use in a pinch; however, if the system swaps on a frequently, it's best to use a partition. A swap file has the added overhead of the filesystem writes that a swap partition does not.

しかし、差は体感できるほどとは思えないという意見や、fileかpartitionかよりも、swapがディスク上のどこ(物理的位置)に配置されているかのほうが効いてくるという意見もあった。


kernel 2.6 系の場合は、VMの改良によりどちらでも差がないと言っている人がいる。正式なカーネルドキュメントにそう書いてあるわけではないのですが、まぁ信用できるかなと。

Actually I seem to remember reading an article by Linus which stated that a swap file in a 2.6 kernel would not have any noticeable performance hit vs a swap partition.

(http://www.codemonkey.org.uk/post-halloween-2.5.txt より)

VM Changes:
- Due to various changes, swap files should be just as fast as swap partitions.


個人的には、「swapのパフォーマンスが重要なサーバなんて作るのやめましょう」「メモリ買って来ましょう」という方向に思考が行ってしまうので、どっちでもいいかな。どうしてもどちらかを選べと言われたら、swap file のpenaltyをほぼ零にした(はずの)カーネルハカーの努力に敬意を表して file をチョイスいたします :-)

Christopher Alexander さん

software

パタン・ランゲージ―環境設計の手引


パターン関係の文献を読んでいてふと思ったこと。


パターン言語という考え方は、Christopher Alexander という建築家が著著 " A Pattern Language: Towns, Buildings, Construction" (邦訳: パタン・ランゲージ―環境設計の手引) で著したのが最初ということですが、今、googleで"pattern language"や"Christopher Alexander"を検索すると、少なくとも日本語のサイトで上位に来るのはソフトウェア関係のサイトばかりです。


ソフトウェア業界でのパターン言語の果たした（ている）役割云々とは別に、もともとの建築業界でのこの人の評価はどうなんだろうとふと気になりました。

  1. どの程度有名？
  2. 過去の人？
  3. 著作って有名？ 現代でも通用してる？

あたりです。


...ごく身近に建築を学んでいる人がいるので聞いてみました：

> 有名？
建築史の教科書に「こんな一派もあった」的に書かれる程には有名。
時代の主流意見に一石を投じた意味で、注目は高かった人。

> 過去の人？
今70歳くらいのはず。まあ、過去の人かな…。

> 著作って有名？
パタン・ランゲージは有名。あとは『都市はツリーではない』とか。

> 現代でも通用してる？
思想は否定されていないけど、その理論をもとに彼が設計した建築*1が、ユーザーにとっていい建築かは疑問視する声も。

また、「建築理論屋さんだからかもしれないが、実作が少ないのが気になる」そうです。建築業界で、「パターン言語」から発展した何か(曖昧ですが…)がないか聞いてみましたが、「当時(70年代)でも主流とは言いがたい位置にいた人なので、そこから発展したものというのは思いつかない」とのこと*2。


ソフトウェア業界でよく引き合いに出される旨 話したところ「ソフトウェア業界よりは、もうすこし熱の落ち着いた目で見られているお人かと思います」との見解を頂きました。いやまぁ、一人に聞いただけですが*3、ちょっとお勉強になりました。( ・∀・)つ〃∩ ヘェーヘェーヘェー


(追記) お、http://www.ogis-ri.co.jp/otc/hiroba/Report/OOSympo2003/pattern.html には

建築業界ではソフトウェア業界のようにパターンが広く認識されていないので、ソフトウェア業界から影響を与えてもらって、建築業界での認識を広げていきたいというお話もありました。

なんて記述もありますねぇ。

*1:埼玉の学校: http://ma-museum.com/saitama/ten-higasino/30-higasino-koko.htm など

*2:まぁAlexanderさんは最近の著作もあるようなので、それを読んでみるのも面白いかもしれない。あーでも訳されていないな。畑違いの分野の洋書はちょっと私にはムリだ

*3:そんなに詳しくないと言ってたし

TSF一覧

C++ POSIX

"[C++] UNIX上でのC++ソフトウェア設計の定石 (6)"で、"SUSv3に、TSF(Thread Safe Function) の一覧はないと思う" と書きましたが、ありますね。


正式な規格ではなくRationaleとしてですが、XSI Supported Functionsのところに、

On XSI-conformant systems, the symbolic constant _POSIX_THREAD_SAFE_FUNCTIONS is always defined. Therefore, the following functions are always supported:


asctime_r() ctime_r() flockfile() ftrylockfile() funlockfile()
getc_unlocked() getchar_unlocked() getgrgid_r() getgrnam_r()
getpwnam_r() getpwuid_r() gmtime_r() localtime_r() putc_unlocked()
putchar_unlocked() rand_r() readdir_r() strerror_r() strtok_r()

という記述があります。実質的にSUSv3で定義されたTSFの一覧...だと思います。