週記になりつつあるな……
週末の地震被害は特にはなし。2F の本だなからちょっと本がおちたぐらい。事務所はけっこうフィギアがこけてたそうな。
ただ、電車（東西線）うごかなくて、づの人の東京進出おめの歓迎会にいけなかったのが残念無念。
空が青くて暑い……
GMOどこでもLANが無料試用できるので試してみたり。原理的には SoftEther とかと同様な仮想HUBに仮想LANカードで接続するやつです。セットアップはかなり簡単やねー。現時点では Win 専用だけど。
とりあえず、光接続 - どこでもLAN - 光接続、を経由して、Windows ファイル共有においてある ムービを見てみたりする。そこそこ普通に使えますな。たまにちょっと止まるけど。一般的なファイルやりとりなどには問題なくつかえそうです。これ、HUB の部分でファイル共有とかのサービスもあわせてくれると便利なのに。
あー、さくらとかのホスト屋さんで「ＶＰＮサーバのホスティング」なさーびすやってくれないかなー。
こんなかんじ？
導入時に追加セットアップ料をいただくことにして、月々の追加料金はナシ（ホスティング料金のみ）、接続速度はベストエフォートだしってことでユーザ数制限とかけちなことはナシ、管理は原則ユーザ側が行なうの前提だけど、管理作業委託は別途有料保守サービス扱いで可能、とか、そんなかんじでやってくれると、社内に（コンセントとスペース足りないので）サーバあまりおきたくない、 SOHO 社員多い中小な会社とかにウケると思うんだがなー。事務所からは、対外ルータの IPSec 使って LAN からスルーで見れるようにして、SOHO でおうちな人は、OpenVPN で単体マシンから作業時のみ接続ね。
そのうち暇ができたら具体的な構成を練って、管理部とかでっちあげるので、どっか買ってください（ぉ。その前にどこかが似たものを実現した/すでにしてるなら、それはそれで使用を検討するので教えて下さい（笑）
吉里吉里ベースの新システム（予定は未定）で必要だということで、 けんじょさんに作業依頼して（対価：うまい晩飯n回）、現行システムに近いフォトショップ互換な合成モードをつくってもらいました。寄贈したので、2.25 beta8 から組み込んでいただける予定です。
効果用のデータとかを作成する時に、フォトショップで確認しながら作業できるようになるので、うれしい人はそれなりにいるんじゃないかな？かな？
あと、Win32OLE もとりこんでもらったけど、もすこし具体的なサンプル欲しいっすね。 PhotoShop 制御研究するかなぁ。
おもいついてためしに書いてみたらさっくり動いたのでなげときます。参考用コードのレベルは越えてないけど。そのうちだいたいの機能が網羅できるように拡張予定。
ああ、こうして環境依存度が高いプラグインが増える罠（爆）。マルチ環境指向なら libart とか選択するべきなんだろうねー。
GDI+ ははじめてさわりましたが、わりと素直な構成ですね。あ、そうか、EMF/WMF が簡単に扱えるんだ……。ベクタ画像を透過的に扱えるレイヤとか組むとおもしろそう。拡大してもぼけないのでロゴ用途とかに超最適。
レイヤの内部に GraphicsPath を保持して、それにラスタ/ベクタ画像や各種プリミティブを次々追加描画して、それをバックバッファとみなして、なにか更新とか変形とかあった時はそこからラスターとしてのレイヤに書き戻すようなインターフェースを組めばいいんだな。うむうむ。
はるばるしんがぽーるから、Adobe のアップデートの荷物がどかっと届く。
PhotoShop と Illustrator はそれなりに使ってるからいいんだけど、 InDesign が習得できないままバージョンだけがあがってるなぁ（汗）
ここのんにさそわれたので、大塚三浦屋でうなぐ。時間勘違いしてて、あやうく大遅刻しかける。うお、開店前で既に行列が……。
うまー。パリパリでやわらかいのだ。３度おいしいひつまぶし。
そして店をでると、来た時よりも長い行列が（汗）
ファイルキャッシュの量、基本的に空いてる部分の活用、なので、それを調整する（制限する）という概念は、UNIX 系OS には無いのじゃないかなーと思います。たぶん（汗）
UNIX 系 OS における「スワップ」というのは、メモリに入りきらなくなったものを待避する場所、ではなく、アクセスする優先度が低いものをおいておく「メモリの一部」なので、確保したばかりのメモリがスワップにおかれてしまうのはそれはそれで一理あります。もちろん実際に使う時にはメインメモリにないとだめですから、最終的には頻繁に使っているのであれば全部メインメモリにのっかるはずです。
ただ、キャッシュとしての物理メモリにすごく余裕があるのに、それを解放せずにまずはスワップにながしちゃう、というのはどうなのよ、ってのは素直な感情ですよね……。実際、Solaris や BSD では普通に期待通り動いてくれるようなのですが、どうも、Linux (2.4系？) はそのあたりの挙動が非常に怪しい、という噂はちらほら。実際のとこは未確認なのですが……。どんなもんでしょう？＞識者
free のサイズ分の範囲なら一発でメモリからとるのだと思うのですが、 free な領域は Linux では、標準で「物理メモリ量の 1/128」が維持目標になってるようです。つまり、1G のメモリをのせていても、常時 free 確保分は 8M。現在利用分＋ free 8M ＋ 残りはキャッシュにまわされる、という状態なわけです。
これを変更するには、Linux カーネル中の zone_balance_ratio という変数を調整すれば良くて、これはカーネル構築時か、起動時のカーネルパラメータで変更できます。 memfrac=32,4,128 とか指定すると（標準は32,128,128らしい）、全メモリの 1/4 を Free として保持してくれるはずです（自分では未確認）。なお、パラメータの 1つめは DMA 用、2つ目が通常のメモリ、3つ目が HIMEM 用領域です。
ただ、これ、下手に大きくすると、その維持のためにメモリが食いつぶされそうな気もしますな……。まあ、ほどほどにってことで。
そもそも「アプリによる消費がさほどでもないにも関わらず頻繁かつ不定期な処理落ちが発生している」のは、それ swap が原因なの？という気がしなくもないかも。cron とかの設定ミスで、すごい勢いで謎プロセスが走ってるとか、どっかに busy loop なロジックかかえたタコなプロセスがいるとかで CPU 食いまくりー、とかのほうがありそうな気がするんですね^^;
まずは、vmstat とかのコマンドで確認してみるべきかと。 si / so の部分でどのくらいの頻度でスワップがおこっているのか検出できます。ちなみに安定した状態のシステムではずっと0 になります。もしそれで確認した上でスワップ頻発だと判断してるならごめんなさい^^;
あと、目的の環境がスワップ無しなら、開発試験用の環境もスワップ無しにするとか、いろいろあわせられるところはあわせておいたほうが、あとあとのトラブルで泣かなくてすむように思います。