SVX日記
2005-02-06(Sun) 一足早くバレテンの日
なんだ? 以前にIPをハジいたハズなのに、またアホがリファラスパムをかけてきている。やめてほしいなぁ。この高尚なサイトに下劣なリンクをお貼りになるのは。またiptablesでハジいちゃうかな? アクセスログからnslookupで相手のIPを求めてiptablesに入れて完了!! ……と、思いきや今回はその技が効かないッ!! なにッ!? 相手もレベルアップしておるのか!? いったい今度はどんな手口なんじゃ?
試しにnslookupで求めた相手のIPにWebアクセスしてみたが、どうやらあまり関係のないIPをアクセス元として偽装しているらしい。この大学、踏み台にされとるんちゃうか? なんだかよくわからんが、ソッチがその気ならコッチもどうにかして排除しちゃうもんね。別の方法を考えるのである。
で、今回はapacheレベルでハジいてしまうことにした。リファラ文字列を見てハジくことができれば、アクセス元に関係なくハジくことができる。iptablesの方法も悪くはないが、登録が増えるとネットアクセス全てのパフォーマンスに影響しそうで気持ち悪かったんだよね。apacheでハジけばそういう問題もなくなるしな。設定方法は簡単だ。「vi /home/svx/public_html/diary/.htaccess」でアクセス制御ファイル開き、ファイルの最後尾に、
SetEnvIf referer "sex.*\.com/" refuse
Order allow,deny
Allow from all
Deny from env=refuse
という記述を加えるだけ。今回の手口では貼りたいリンクをrefererに記述せねばならんので、それを参照して直接排除することができる。排除したいリンクが増えたらSetEnvIfの行を複数並べればよい。こりゃ簡単だ。ついでに、既に貼られてしまったリンクも削除してしまおう。これはtdiary側の操作になる。「vi /home/svx/diary/2005/200502.tdr」でファイルから下品なリンク元を削除、「rm /home/svx/diary/cache/200502.*」でページキャッシュを削除。コレだけだ。
……とか作業していたら、今度はなんだ!? 今日のアクセス数がイキナリ300以上になっている。最近は平均して1日100チョイくらいなのに、300とは……すわ攻撃か!? ……と思ったら、なんだ、米Yahooの検索クローラ「Yahoo! Slurp」がサイトを絨毯爆撃しただけかよ。そういや昨晩、このSVX日記に「全日記一覧」機能を試験的に付けたんだった。しかし1時間でバラバラなIPから次々に300アクセスって……許容範囲だとは思うが、びっくりするじゃねぇかよ。
さて、今晩はカミさんの友達夫婦が遊びに来るので、昼過ぎから酒を買いにいく。で、ついでといってはなんだが、一足早いバテレンデーということでカミさんにスコッチをプレゼントしてもらう。オイラは甘いものが苦手なのだ。近所の酒屋で買える程度のスコッチなので、そう種類を選べるワケではないが、そう呑み尽くしているワケでもないので、ワクワクしながら選ぶ。今回は呑んだことのないモルトにしよう。
前々回のMcCLELLAND'S-ISLAYでは失敗したが、かといって味見できるわけでもないので、運をドーンと天に任せるコトになる。コレがホントの任天ドーン……って、ファミコンかよ!! ……とか、ひとりツッコミつつ、決定!! 今回はお気に入りのグレンモーレンジ(Glenmorangie)と同じHighland系ながら、Skye島というトコロで醸造されたタリスカー(Talisker)というモルトだ。島で醸造ってのが、前々回のMcCLELLAND'S-ISLAYを想像させてちょっと不安だが。
2006-02-06(Mon) ディスクキャッシュで腹イッペイ
そうそう、Linuxのサポートを仕事にしていると、当然ながらOSの挙動について詳しくなる。システムのトラブルを解決するには、大量のシステム統計情報をガリガリと読みこなし、原因を推定し、診断を下さねばならないからだ。だから、最近はLinuxのメモリ利用状況は、ログを読むだけで手に取るようにわかる。
いきなり昔話になるが、太古のOS(MS-DOSなど)には、ディスクキャッシュという機能があった。搭載されているメモリの一部に、フロッピーディスクやハードディスクから読み込んだ部分を貯蔵して(残して)おいて、再度必要になったときに、ディスクから読まずに、メモリから取り出すことで高速化する機能である。キャッシュに利用されるメモリ量はキャッシュ機能をオンにする時に設定によって決まる。キャッシュ用のメモリ量が多いほど快適になるが、その分メインメモリが減るので、設定には熟慮を要した。
しかし、近年のOSにはディスクキャッシュの設定は存在しない。だが、別にディスクキャッシュという機能がなくなったわけではない。搭載メモリの遊んでいる部分は、すべてディスクキャッシュに利用してしまおうという方針になっているのである。確かに余っているメモリを有効活用するという意味で、ディスクキャッシュはうってつけである。
だから、システム起動時はともかくとして、システムが稼動するにつれて、空きメモリにはどんどんディスクの内容が充填されていく。この段階では、キャッシュした内容が再度使われるかどうかの判断なんて行われない。なにしろ、カタッパシから読んだディスクの内容を空きメモリに充填していくのである。これは、設定にもよるが、搭載メモリの90%以上が利用された状態になる程度まで進行する。つまり、真に空いているメモリが10%以下になってしまうまで続くのである。
[mitsu@colinux mitsu]$ free
total used free shared buffers cached
Mem: 61416 60000 1416 0 3516 38636
-/+ buffers/cache: 17848 43568
Swap: 65528 0 65528
上記は、coLinuxを64MBで起動して、しばらくの後の状況である。搭載メモリが61416KB、利用メモリが60000KB、空きメモリが1416KB。実にメモリ使用率97.7%である。で、どれくらいキャッシュに利用されているかというと、buffersとcachedの合計値がそれだ。42152KB。これは68.6%である。実に搭載メモリの7割近くは、ディスクキャッシュに利用されているのである。
で、大変に質問に多いのがこの状況についてである……「たいへんです!! ウチのサーバ、ほとんど空きメモリが残ってないんです!!」……という質問である。結論から言うと、思いっきり大丈夫である。何の心配もない。ディスクキャッシュの内容なんてのは「別になくても構わない」内容であるから(だって、同じデータがディスク上にあるのだ)、別途必要になった時には即座に開放することができるからである(例外はあるが)。
この状況では「-/+ buffers/cache」の行に注目しなくてはいけない。usedの欄はかなり少なく、freeの欄はかなり多い。これは、キャッシュに利用しているメモリ容量を、空きメモリであるとして計上した場合の容量である(実際にbuffersとcachedの数値を加減してみてほしい)。つまり「実質の空きメモリ」はこの行で確認できるようになっているのである。それを加味すると、メモリ使用率は29%。まだまだ余裕であることがわかる……
……と、このようにLinux環境においては、サクっとメモリについて語れるオイラであるが、Windowsはわからない。統計情報をどこで見たらいいのかさえわからない。え? やっぱそう? タスクマネージャ? そーなのか……やっぱり、テキスト至上主義のUNIXの方がどう考えても正しい姿だよな。ホントにこんな情報しかないの? でも、項目の意味すらわからないんだよねぇ。ググる……
……概ねわかった。タスクマネージャの「物理メモリ」と「コミットチャージ」が重要な情報らしい。まずは「物理メモリ」の「合計」だが、これは実際の搭載メモリを現している。搭載メモリが512MBなら、約512000を表示しているはずだ。
で、重要なのが「コミットチャージ」の「合計」だ。これはシステムが利用しているメモリ容量だ。400000とか表示されていたら、400MB利用しているという意味。なに? ウチは512MBしか搭載してないのに、800MB以上使っているコトになってるって? 大丈夫。別におかしくない。ざっと言うと、足りない部分はハードディスクをメモリ代わりに利用しているからだ。それが仮想メモリ。ただし、ハードディスクをメモリ代わりに使う場合は、必要なときにメモリに呼び戻さなければならないので、遅くなる。これがPhotoshopのウィンドウに切り替えるときにモッサリする理由だ。
結局、どうすればいいのか? それは「コミットチャージ」の「最大値」を見ればいい。自分が普段使うように……できればちょっと贅沢めにアプリをたくさん立ち上げて、ウィンドウを開きまくって「最大値」を見るのだ。それが望ましいメモリ搭載量である。理論的には、その値が「物理メモリ」の「合計」を上回らない限り、仮想メモリは利用されないはずである。つまり、それでもモッサリを感じるとしたら、それはメモリのせいでなく、CPUの処理能力のせいであるということだ。
ちなみに「コミットチャージ」の「制限値」は「物理メモリ」の「合計」と仮想メモリの容量を足した数値だ。どうがんばっても、これを超えてメモリを利用することはできないという限界量だが、限界量付近ではかなりレスポンスが悪化するハズなので、ここまで大丈夫であるとは思わないほうがいいだろう。
2007-02-06(Tue) SVX発見ッ!!
登場はこの一瞬で、バトルどころか、登場人物にさえ「ビタ一文からまない」のだが、この番組に出演するためには3Dモデリングが必要になるワケで、製作者側にそれなりのコダわりがなければ出てこれないハズなのである。ちょっとうれしい(同作の別シーンにも出ていたというウワサもあるが、未確認)。
2022-02-06(Sun) 補修して、散歩して、工作して
昨年の11月末ごろ、出先でロードスターに乗り込んだ勢いで、ハンドル下部に爪を押し当ててしまい、レザーが薄くメクれてしまった。それが、ちょうど2時の角度の辺りだもんだから、気になって仕方ない。悩んだ挙げ句、木工用ボンドをスキ間に流し込んで補修してみた。丁寧に扱っていても、どうしてもやらかしてしまうことはあるんだよな。でもまぁ、割とイイ感じに補修できたかも。
空は雪模様だが、昼前からカミさんとお散歩に出かける。なんとなく、港区の港から遠い辺りへ。もうすぐ移転が予定されている競馬場とか、潰れてしまった大規模ショッピングモールとか、川沿いの公園でも歩こうかと。ついでにスーパー銭湯に寄ろうかと思ったら……なんだ、一緒に潰れてたのか。ダメじゃん。
競馬場に車を駐めて、競馬場内を一回り。実際にレースをしていないことは確認済だが、中継で数レース遊ぼうと思っていたのに、うまく馬券が買えず。あきらめて、散歩に向かおうと思った時に、入り口で配布していた出走表に気付き、佐賀も高知も午後からのレースと知る。なんだ、そういうことか。じゃ、帰りに遊ぼう。
ちょっと吹雪になりかける中、川沿いの公園を南へ向かうと、カモメが大量にくつろいでいる浮島へ。エサくれるんじゃないかという期待で、ギリギリまで寄ってくるが、手の届く距離ギリギリで、シブシブ飛び立つという距離感が面白い。
さて、晩飯を食ったら、少し工作。先日、バッテリフレームを付け替えてみたが、ロッドボルトは元のものを使っていた。しかし、ちょっとロッドボルトが長く、ナットから出る量が多いので、トルクレンチのソケットの奥につかえ、トルクレンチでナットを締めることができない。
一方で、買ったバッテリフレームに付属のロッドボルトは、ありえないほどに長い。バッテリフレームの説明書には「ロッドボルトとボンネットが接触する場合、ロッドボルトを金ノコ等でカットしてください」とあるが、この長さで接触しない車種なんて存在するのであろうか。そして「金ノコ等でカットして」なんて軽く書いてあるが、その作業はそれほど容易ではないと思う。そもそも、いくらなんでも、そんな切り方の説明もないだろうに。
しかし、逆に考えれば、ロッドボルトをベストな長さにカットできれば、微妙に軽量化できるし、トルクレンチでナットを締めることもできるようになる。いやなに、ほとんど気分的な問題であることはわかっている。ほとんど気分的な問題ではあることはわかっているが、やたらとカーボン調のシールをあちこちに貼る行為よりは、いくらかでも意味はあると思う。
つうわけで、ワザワザ金ノコを買ってきた。100円ショップで安く済まそうと思ったが、結局バッテリフレーム代以上かかってしまった。まぁ、次の機会があれば使えるけれど……と、簡単な治具を作り、ナットの隙間で切断位置を固定し、ゴリゴリとやる。最初はテスト。いい感じ。そして、本番。
金ノコをネットで物色していたら「対象物は切れません。切れるのは息だけ」というレビューを見つけてウケる。自分が購入した刃は割と順調に切断してくれた。ステンレスは硬い。力ではなく、手数で切るのがコツのようだ。
ちなみに、ナットを通しておいたのは、切断位置を固定する意味もあるが、ナットを外す時に切断面付近の潰れたネジ山を整形させる意味もあったのだが、特に抵抗もなく外せてしまったので杞憂だったようだ。切断面は割とキレイだが、電動ルータと砥石で整形した。うむ。よいデキである。