鷹巣さんの所の自宅サーバーWebRingに登録をさせてもらった。バナーはもっとサイト名の分かるものの方が良かったか？
本登録の連絡がいただく。
Ringをたどって鷹巣さんの所まで戻ってみたがなかなか大変。これを素直にたどってここまでたどり着く方は少ないだろうなぁと思う。
本登録の連絡を12時ほんの少し前にいただいた後、16時44分に百度検索エンジンBaiduspiderがクロールしていって、18時48分にはYahoo! JpanaのY!J-SRDがクロールしていった。素早い。ただ、Googleのクローラと違いトップページのみ。Baiduspiderはrobots.txtを確認したログが見つからなかった。無視するのかなぁ。
自宅サーバなので、ネットワークの底から外界を見る感じになるはずです。大阪大学工学部のFTPサーバとJPIXのFTPサーバにpingを打たしてもらって、MRTGで変化をみられるようにしてしてみた。
自宅が兵庫なので大阪大学の方が早いかと思えばさにあらず。JPIXの方が遅延が少ない。半分程度。さすが日本の商業インターネットのおへそといったところ。
百度検索エンジンBaiduspiderが昨日の深夜から今日の午前中にかけてゆっくりと全てのページをクロールしていった。今回はrobots.txtを確認していった。Yahoo! JpanaのY!J-SRDはもう少し早い周期でトップページのみクロールしていく。GoogleのGooglebotは、昼前から午後すぐにちょっとだけクロールしていった。
しかし、これだけクロールしてくるのに検索結果に載ってないのはなぜかな。探し方が悪いのかな。
ISP内の遅延が分かるように追加でデフォルトルータのグローバル側にpingをかけさせてもらった。
グラフの形が予想外。どの時間もほぼ一定の感じ。遅くなる確率が増える感じ。もっと波打つ様なグラフを想像していた。
cpufreqがCore2に対応しないかなぁ。
検索エンジンに掲載はされていないのに、アクセスが増えてきた。自宅サーバWebRingに参加の効果がもう現れている。
昨日make updateであたらしいソースを取得して反映させたところ、ACPIのエラーが無くなった。
2007/06/03 Sunより前 acpi0: <AOpen AWRDACPI> on motherboard acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi_bus_number: can't get _ADR acpi0: Power Button (fixed) が2007/06/03 Sun acpi0: <Open AWRDACPI> on motherboard acpi0: Power Button (fixed)
もしかすると、ACPIうまく認識するようになって、TシリーズのCore2 Duoでうまくcpufreqとpowerdが動くかも知れないと、淡い期待。すぐにロードしてみるが以前（2007/05/21 Mon)と同じ症状。残念。
ISPの事を通信網のページに詳しく記載。過去のことより、現在のことに絞った方が良かったかな？
読み直すとおかしな所がいっぱいで改訂。
珍しいスパイダを発見。2つだけリクエストが来た。robots.txtもちゃんとアクセス。
[05/Jun/2007:08:59:10 +0900] BlogSearchBot2007 http://www.yama.info.waseda.ac.jp/~taku/crawl.htm
自身の出身をちゃんと名乗っているので、それをYahoo!で確認した後「早稲田大学理工学部コンピュータ・ネットワーク工学科の山名研究室」へ。UBQ班と言うグループで「Webを代表とするような大規模なデータから，新しい知識を抽出する，また知識を抽出する手法を作ることをテーマとして研究」と書いてあるので元々その関係の研究をしておられるらしい。情報大航海プロジェクトに関わっておられるようなのでその関係かもしれない？様々な研究があるんだなぁ。
「robot.txt」の連続アクセスもあり。
[06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" [06/Jun/2007:13:33:22 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-"
エージェントはWindows NT 5.0 ja Firefox/2.0.0.4なので手動のアクセスだとは思うのだけど…。robots.txtをアクセスするかどうかは確認しているのですけどrobots.txt自身はないんです。
スパイダがたくさんクロールしていく割には、このサイトへのリンクは登録されていてもこのサイト自身は「百度」以外には登録されていない感じ。「百度」はえらく上位にランクされる。「自宅サーバ」＆「FreeBSD」の検索で本日は4位にランクされていた。
ルータ(YAMAHA SRT100）のログを確認すると、このサーバとのＥthernetの接続が変動している。
2007/05/31 22:01:35: LANC1: PORT4 link down 2007/05/31 22:01:38: LANC1: PORT4 link up (10BASE-T Half Duplex) 2007/05/31 22:01:41: LANC1: PORT4 link down 2007/05/31 22:01:44: LANC1: PORT4 link up (100BASE-TX Half Duplex) 2007/05/31 22:01:47: LANC1: PORT4 link changed (100BASE-TX Full Duplex) 2007/05/31 22:02:20: LANC1: PORT4 link changed (100BASE-TX Half Duplex) 2007/05/31 22:02:23: LANC1: PORT4 link changed (100BASE-TX Full Duplex) 2007/05/31 22:02:41: LANC1: PORT4 link down 2007/05/31 22:02:44: LANC1: PORT4 link up (100BASE-TX Full Duplex)
上記はほんの一部。四六時中変動している。メンテのためにアクセスしていると変動しない。これは、PHYが「低消費電力のためにリンク状態を変化させる」というやつかと納得。いつだったかYAMAHA RTのメーリングリストでも変化が話題になっていた。元々サーバ用のM/Bで無くクライアント系の低消費電力系M/Bを流用している上に、FreeBSDのドライバはこの辺きっちりやっていそう。通信に支障はないようなので自宅サーバ運用の消費電力低減のためにもこのまま行くことにしよう。
留守中に落雷による物らしき停電で停止！
18:27:29秒付近で停電し、18:34:33には復電した模様（ルータのSRT100のログより推定)。他の機器の状態から見ても瞬停のレベルではなく十数秒以上ではあるが十数分に達した停電ではなかった様に思える。
FreeBSD 6 stableが正しくシャットダウンしなかったときどのように振る舞うか分からなかったので、電源回復でもOFFを維持するようにBIOSに設定していた。この為、帰宅する20:50:22まで停止してしまった。
回復の様子を見ると、立ち上がり時にfsckで止まるようなことはなく立ち上がり、バックグラウンドfsckでサービスを行いながら回復開始。バックグラウンドfsckはサービスに大きな影響を与えることなく、13分34秒でチェックを完了して通常状態に戻った。
FreeBSDのファイルシステムの特徴である、soft-updatesは、設計者が言うほど障害に強くないなどと言われるのを聞いたりしていたが、何の何の見事な物である。今度からは、停電回復で停電前の電源ON/OFF状態を維持するようにBIOSに設定しておくことにしようと思う。
昨日の停電は広範に被害が及んでいたよう。停電で停止する前に、通信の異常が検出されていた。
Date: Fri, 8 Jun 2007 17:25:23 +0900 (JST)
^^^^^^^^当サイトが止まる前の時間
PING mikaze.comm.eng.osaka-u.ac.jp (133.1.44.10): 56 data bytes
--- mikaze.comm.eng.osaka-u.ac.jp ping statistics ---
10 packets transmitted, 0 packets received, 100% packet loss
全パケットがロスト^^^^^^^^^^^^^^^^
直近のゲートウエイまではもちろん東京側へのpingにもエラーが出ていなかったので相手側ローカルに近いところのトラブルだろうか？これ以外は検出されていないので、旧帝大の通信網は強いなと感心。
WebRingの稼働監視のリクエストも当サイトが止まる前から止まっていて、かなり立ってから回復していた。
○昨日の最後の稼働確認リクエスト： [08/Jun/2007:15:17:07 +0900] "OPTIONS / HTTP/1.1" 200 - "-" "JSWC/0.3" この間稼働確認用のパケットが来ず。本日の最初の稼働確認リクエストは以下の通 り未明の04時台。 ○本日最初の稼働確認リクエスト： [09/Jun/2007:04:41:32 +0900] "OPTIONS / HTTP/1.1" 200 - "-" "JSWC/0.3"
いや、実に広範囲に影響が出ていたのだなぁ。
停電回復後、通信回線の通信遅延時間が大幅に減少。それが続いている。
80％弱の減少に相当する7ms以上の減少。リトレーニングの効果と思うが、サーバを設置するときにさんざん電源入来りしたのに、今回に限ってなぜ？
MSNに2007/06/08 22時頃MSNに登録してみた。
Live Search URL の登録 http://search.msn.co.jp/docs/submit.aspx?FORM=SUNO
すると、1時間もかからずにスパイダがクロールを始た。すばやい。
[08/Jun/2007:23:19:38 +0900] GET /robots.txt msnbot/1.0 [08/Jun/2007:23:19:38 +0900] GET /history.html msnbot/1.0
昨日（2007/06/09 Sat）には、もうインデックス入りして、「自宅サーバの運用(FreeBSD)」で引くとランク1位で表示。「()」をマルチバイト系からANSI系にするだけでページ外にランクダウンするのでGoogleと違って一致が優先なのだろうと思う。
あまり聞いた来たことのない、外国のサイトのスパイダーがクロールしていった。
[08/Jun/2007:23:31:05 +0900] GET /robots.txt Ask Jeeves/Teoma [08/Jun/2007:23:31:06 +0900] GET / Ask Jeeves/Teoma
こんな、英語記述のない日本語の自宅サーバをクロールしていっても、効果は薄い気がする。
Yahoo!には登録していないのに、2007/06/06のモバイル版Yahoo!のスパイダに続いて2007/06/04には本体側のスパイダのYahoo! slurpもやってきてクロールして行った。WebRing本登録は2007/06/02でリング登録サイト一覧への掲載は2007/06/04だったように思うので、一覧側への掲載直後からクロールしていっていることになる。
[04/Jun/2007:11:40:43 +0900] GET /robots.txt Yahoo! Slurp [04/Jun/2007:11:40:44 +0900] GET / Yahoo! Slurpモバイル版Yahoo!は初めの頃やってきたあときていないが、本家のYahoo! slurpは2007/06/07から1日に8ページ、1時間に1〜2ページぐらいをゆっくりクロールしていた。
[07/Jun/2007:01:39:48 +0900] GET /robots.txt Yahoo! Slurp [07/Jun/2007:01:39:58 +0900] GET / Yahoo! Slurp [08/Jun/2007:06:06:23 +0900] GET /robots.txt Yahoo! Slurp [08/Jun/2007:06:06:42 +0900] GET /link/index.html Yahoo! Slurp [08/Jun/2007:06:20:09 +0900] GET /pc/index.html Yahoo! Slurp [08/Jun/2007:07:11:49 +0900] GET /robots.txt Yahoo! Slurp [08/Jun/2007:07:12:34 +0900] GET /tips/index.html Yahoo! Slurp
ところが急に本日（2007/06/10 Sun）になってやたらにがんばってクロールしていく。
[10/Jun/2007:00:37:36 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:00:38:31 +0900] GET /link/ Yahoo! Slurp [10/Jun/2007:02:05:44 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:02:07:05 +0900] GET /tips/makej.html Yahoo! Slurp [10/Jun/2007:02:20:36 +0900] GET /profile/ Yahoo! Slurp" [10/Jun/2007:03:48:05 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:03:49:43 +0900] GET /tips/ Yahoo! Slurp" [10/Jun/2007:04:01:50 +0900] GET /pc/ Yahoo! Slurp [10/Jun/2007:04:17:44 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:04:19:59 +0900] GET /tips/makeconf.html Yahoo! Slurp [10/Jun/2007:06:39:20 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:06:41:05 +0900] GET /pc/hknd0101.html Yahoo! Slurp [10/Jun/2007:10:22:52 +0900] GET /robots.txt Yahoo! Slurp" [10/Jun/2007:10:23:08 +0900] GET / Yahoo! Slurp [10/Jun/2007:10:28:58 +0900] GET /log/index.html Yahoo! Slurp" [10/Jun/2007:10:31:15 +0900] GET /tips/index.html Yahoo! Slurp [10/Jun/2007:10:32:12 +0900] GET /history.html Yahoo! Slurp [10/Jun/2007:10:33:23 +0900] GET /pc/index.html Yahoo! Slurp [10/Jun/2007:10:34:15 +0900] GET /stat/index.html Yahoo! Slurp [10/Jun/2007:10:34:40 +0900] GET /link/index.html Yahoo! Slurp [10/Jun/2007:10:35:21 +0900] GET /profile/index.html Yahoo! Slurp [10/Jun/2007:10:38:52 +0900] GET /tips/makeconf.html Yahoo! Slurp [10/Jun/2007:10:43:29 +0900] GET /tips/ Yahoo! Slurp [10/Jun/2007:10:43:51 +0900] GET /mrtg/ettcrt.local_1.html Yahoo! Slurp [10/Jun/2007:10:44:24 +0900] GET /pc/ MozillaYahoo! Slurp [10/Jun/2007:10:45:38 +0900] GET /link/ Yahoo! Slurp [10/Jun/2007:10:46:42 +0900] GET /pc/hknd0101.html Yahoo! Slurp [10/Jun/2007:10:56:54 +0900] GET /tips/kernelconf.html Yahoo! Slurp [10/Jun/2007:10:57:35 +0900] GET /profile/ Yahoo! Slurp [10/Jun/2007:12:25:55 +0900] GET /robots.txt Yahoo! Slurp [10/Jun/2007:12:26:10 +0900] GET /mrtg/ Yahoo! Slurp
更新頻度の高い自宅通信網の運用日誌に関しては、16時過ぎにもう一度クロールしていった。Yahoo! Slurpは日本のサイトの情報を集めようという意欲が見られるように思う。この積極性が、スパイダからのアクセスが嫌いな人たちからは「うっとうしい」という評価につながるかと思うと、なかなかこのての物の調整の苦労がしのばれる
かたや、Googleが、2007/05/28に本格的にクロールしてからは、トップページと更新履歴程度しかクロールする様子がなく、更新の多いページ自宅通信網の運用日誌等の情報を持って行っていないのに比べるとその差は大きいように思う。
当サイトの場合、WebRing以外の被リンクは多分ない状況なので、来ていただける方も少なく処理能力にはまだ余裕がある。通信回線も実測13Mbpsを超えている（VDSLなので上下対称が基本で、特に上りは余裕があるはず）ので、下記の通りの負荷の現状は回線能力にも余裕がある。（現状の詳細はシステムの運用状況(MRTG)通信状況(SRT100)を参照）
現状に回線に余裕があるので、情報がインデックスに掲載されて、興味のある人に見てもらえるのならばクロールしてもらえるのに不満が有るどころか有難い。けれども、クロールするだけクロールしていって、インデックス化する気配もなくYahoo!は1週間、Googleは2週間が経過。クロールされるだけなのはもの悲しい。
特にGoogleに関しては、情報を貪欲に収集してインデックス化。絶対優位の情報力の上でランク付けをしていて、その結果上位のランクに上がるか上がらないかが話題になるのだと思っていた。しかし、現状を見ると、収集をしていってもインデックス化していない情報があり、またクロールの間隔が長いので、新しい情報そのものを集めていないことが有るだろう事が見て取れる。多分巨大故、重要ではないと判断した当サイトの様な小さなサイトについては手が回れないのだろう。
こと、情報収集やインデックス化の早さについては、他社が大きく差を付けていることもあるのだと分かった。自身でサイトを運用して初めて実感できたことであった。何事に関しても1社独占は良くないのだなぁ。
クロールのみでインデックス化されないと嘆いていたら、昨晩23時頃、Googleが参照元のアクセスを発見。試してみたら登録されていた。良かった。約5日前の内容が登録されている。初回のクロールの物が出るような遅延が無く信頼を取り戻した感じ。
訪問していただける方が一気に増加したので、今日は内容を増やさずに恥ずかしい、誤記、誤字、脱字を訂正。Made in JapanをMaid in Japanと間違えていた。妙な願望があるのだろうか。恥ずかしい。
著名なログ解析ソフトであるAnalogの解析結果をシステムの運用状況（MRTGとAnalog）にて公開。Analogはメッセージが日本語化されておりとても見やすいのもありがたい。Host解析系の解析結果はあまりにも生々しすぎるので公開を断念した。
当サーバettcweb0の直接のディスプレイとして、今まで自作パソコン群と自宅通信網１−３．コンソールラックの左側にあるメインクライアントettc-main2用の縦置きの液晶モニタを使っていた。
直接のディスプレイとしては無駄におおきい上に、縦置きなので270度回転した形になり見にくい。その上、サーバを接続しておくと、メインクライアントのettc-main2が低消費電力モードに入ったときにうまく画面側がスタンバイ状態にならない。リブートさせたときなどは切り替えずに様子を見ていたいことも多い。
そこで、縦置ディスプレイの上にあるポータブル液晶テレビのほうへコンソール画面が出るようにしてみた。ettcweb0は元々ビデオ出力を持っているので接続もAVケーブルを用意するだけで接続簡単。
文字はつぶれているが、行の長さや配置でだいたいのことは分かるし、変化があったときだけ、SSHで接続して見に行けばよいのでこれで十分役に立つ。簡単な割に便利にできた。
ftpを使って、公開サーバのettcweb0とメインクライアントのettc-main2間の通信能力試験をした。FreeBSD6.2RのISOイメージをFFTPで公開サーバにアップロードすることにより調べた。
ほとんど、YAMAHA SRT100の転送能力になるはず。下記のグラフの通り様子で21.9Mbit/sとなった。
かなり複雑なフィルタをかけているので、かなり負担になっていると思う。
ettc-mai2のRAID関係基本ソフトUpdate。
自作パソコン群と自宅通信網のとおり、通常経路用ルータにはYAMAHA SRT100を使っている。このルータには、セキュリティ診断機能がある。
ワンクリック診断の実効ボタンを押すと次のような画面がでる。
ここで実行すれば、自宅通信網への入力側はインターネット側アドレスから、自宅通信網の出力側はYAMAHAの公開サーバへのパケットをとばしてポート開閉診断をしてくれるようになっている。
結果の判断は自身でしなくてはならない。しかし、複雑なフィルタを組んでいると、意図しない穴が開いていることがあるが、網羅的に調べてくれるのでそれを発見してくれる。
今回、実効してみたところ、意図したところしか開いていなかった。自身で保守しているとなかなか有難い機能だ。
昨日の日誌中に2枚の画像を貼り付けていた。20070620001.pngと20070620002.png。これが、20070620001.PNGと20070620002.PNGとなっていたので、WindowsXP上で確認したときはうまく表示されても、FreeBSDで動作する当サーバ上では表示できないというトラブルになる。
yetibot@nave.comというスパイダがクロールしていく。非常に過激なクロールをしていく。1秒に1リクエストを超えているしrobots.txtを何度も何度もアクセスしていく。
[21/Jun/2007:18:24:52] "GET /robots.txt HTTP/1.1" 404 285 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:24:52 +0900] "GET /pc/RackFront.png HTTP/1.1" 200 193681 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:25:23 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:25:23 +0900] "GET /pc/ettcweb0.html HTTP/1.1" 200 4860 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:25:51 +0900] "GET /pc/Noah945A-B-11.jpg HTTP/1.1" 200 94672 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:26:21 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:26:22 +0900] "GET /pc/Noah945A-B-12.jpg HTTP/1.1" 200 130333 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:26:51 +0900] "GET /robots.txt HTTP/1.1" 404 285 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:26:51 +0900] "GET /pc/hknd0101.html HTTP/1.1" 200 4018 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:27:23 +0900] "GET /pc/Noah945A-B-2.jpg HTTP/1.1" 200 266356 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)" [21/Jun/2007:18:27:51 +0900] "GET /pc/ettcmain2.html HTTP/1.1" 200 11405 "-" "Yeti/0.01 (nhn/1noon, yetibot@naver.com, check robots.txt daily and follows it)"
NaverBotという悪名高きスパイダらしい。実際の仕草も上記の通り。延々と続く。振る舞いが怖いので、robots.txtによる拒否の意思を表明することにした。
User-agent: NaverBot Disallow: /
無視されそう。
robot.txtを日に何回も読み出していくが今のところ無視されていない。
異常なログが残っているので、公開するかどうか迷ったAnalogの「検索語句レポート」と「検索語レポート」。生データを確認すると、わざとそのような形でアクセスしてきているしているとしか思えない。
多分このようなことは表に出ずに運用情報として不足している情報だと思う。また自宅サーバ運用してログ解析をすると多くの人が困ることだと思うので、きっとそれなりに有用な情報になると思う。迷ったが注釈を付けた上で表示させるようにした。最終的には解説にもしっかり取り上げようと思う。
本日08時に不審な原因の分からない負荷がかかっている。下記の赤線で囲んだ所が怪しく思う。
サーバから見て出力ではなく入力。messagesにもhttpd-access.logにもそれらしきログがない。MRTGの表示から見るとインターネットからサーバへ貫通しているので、上記に記録がないとする、icmpか？東京方面と大阪方面両方の遅延状況も増大していて、特に大阪方面からの遅延が極端に増大しているので、関西方面からのアクセスだろうか。不審な負荷のように思うが、ルーター(YAMAHA SRT100）側の「不正アクセス検知の状態」の方は異常なし。何でしょう？
昨日はICMPか？とは思ったが、どちらかと言えば、正しく成立しない、HTTP(TCP/IP)の方が濃厚かと思い始めた。そうだとしてもどうしたもんだか。
昨日はICMPで無かったとしても、少しフィルタを強化しようと思う。ICMPを通したのは、パケット分割などに対応する為の用心だった。現状ICMP中でもpingが通ればいいので、異常が特に見かけられない限りpingだけに制限を変更した。
通常レベルのアップデートが公開された。
修正箇所は多いものの、多くは影響を受けていなかった。一部少ないながらリブートがらみの物もあることもありアップデートを実施。
ところが、うまくいかない。
毎度すんなり行かないなあ。
ネットワークの遅延状況の測定に使わせていただいている大阪大学の公開FTPが深夜から早朝にかけて停止。夜間でもあり、計画メンテナンスだったのか？
| No. | 開始 | 終了 |
|---|---|---|
| 1 | 2007/06/28 00:40:21 | 2007/06/28 00:45:21 |
| 2 | 2007/06/28 01:05:22 | 2007/06/28 01:15:22 |
| 3 | 2007/06/28 01:35:22 | 2007/06/28 03:40:22 |
| 4 | 2007/06/28 04:10:24 | 2007/06/28 04:15:22 |
| 5 | 2007/06/28 04:25:21 | 2007/06/28 04:40:22 |
| 6 | 2007/06/28 05:05:22 | 2007/06/28 05:20:22 |
| 7 | 2007/06/28 05:25:22 | 2007/06/28 05:35:22 |
| 8 | 2007/06/28 05:40:22 | 2007/06/28 05:45:22 |
| 9 | 2007/06/28 05:50:22 | 2007/06/28 06:20:22 |
| 10 | 2007/06/28 06:40:22 | 2007/06/28 06:50:22 |
| 11 | 2007/06/28 07:10:22 | 2007/06/28 08:00:22 |
長期間にわたって断続的にとまっている。00時から08時と言う時間から見て計画停止だったのかもしれない。ただ、これまでも突然レスポンスが大きく遅れることがあった。何か抱えていた様にも思うのでその対処かも？とも思う。
メインクライアントのettc-main2のFirefoxのキャッシュを移動。毎日のバックアップにキャッシュが保存されてしまい無駄なのと、せっかくテンポラリ専用ドライブが高速なので、Firefoxのキャッシュを以下を参考にしてT Drive配下に動かした。
2007/06/09 Satに、Googlebotが新しい内容をクロールしていかないと愚痴ってYahoo! Slurpの方がデータを集める意欲があると褒めたが、現在のインデックス化の状況を含めるとこの評価があまり当を得ていなかったと反省。
現在、Googleは、当サイトの中でもこのページのように更新頻度の高いページは、わずか3日遅れ程度でインデックス化している。こんな泡沫サイトをわずか3日遅れにおさえるとは！また、遅れ程度に違いがある物の全てのページのインデックス化が行われている。その上ランクも高く、「自宅サーバ FreeBSD」で検索すると8位、「自宅サーバ 運用 FreeBSD」の検索で1位になる。いったいどういう風の吹き回しかとも思う。このおかげで、多くの人に見ていただけるようになってきたようだ。
当サイトは被リンクが極端に少ないので、被リンクの関係で決まる有名なページランクだけでこうはならないのは明らか。「自宅サーバーWebRing」の中に当サイトより有力なサイトはたくさんあるし、それらのサイトは有力なサイトから被リンクされている。だから被リンクの関係で決まるページランクだけならもっと上位にくるサイトはたくさんあるはず。
当サイトが単純な構成でテキスト中心のページなので、Googleが使っている解析ソフトに内容が捕まえやすいだろうと言う事もこの結果に関係しているかも知れないと想像してしまう。巷で言われているほど被リンクの関係で決まるページランクは、Googleの検索結果順位付けの中では大きなウエイトを占めていない気がする。
Yahoo!の方は、現在も精力的にYahoo! Slurpがクロールしてくのに、当サイト自身のインデックスかが行われる気配がない。当サイトへの自宅サーバーWebRing内のリンクがインデックス化されているだけのように見える。
鷹の巣さんの所から、稼働チェックのパケットが来なくなっている。
[29/Jun/2007:14:16:36 +0900] "OPTIONS / HTTP/1.1" 200 "JSWC/0.3"
これが本日の最後。大丈夫だろうか？何かあったのでなければよいが。
無事、本日早朝に鷹の巣さんの所からの稼働チェックのパケットが再開。
[30/Jun/2007:04:41:27 +0900] "OPTIONS / HTTP/1.1" 200 "JSWC/0.3"
SRT100のCPUとMemoryの利用率をMRTGの監視対象にして、システムの運用状況(MRTGとAnalog)負荷状況(SRT100)に掲載。
NATやFWのセッション数の監視をしたかったのだが、適切なOIDを見付けられなかった。