本業ではない書き込みが多いこのごろですが「こういう事態に困った時はお互い様として動けない会社は○○だ！(^^」と思い、出来る範囲で支援・活動をさせていただいております。
という事で、震災直後から約３ヶ月にわたり中継を行ってきたガイガーカウンターin柏ですが、事務所移転を機に、終了とさせていただき、新たな生かし方として期間限定無料レンタルをする事にしました。無料といっても「Amazonの被災地ほしい物リストに何かを送る」事を条件とします。金額は問いません。100円でも200円でもOKです。「一つのガイガーカウンターが、少しでも被災地の直接支援に繋がれば」と願う次第です。
詳しくは http://syun.jp/geiger_counter/rental/
なお、この３ヶ月間の中継エピソードです。
- 地震発生の夜、原発が危ないという噂からガイガーカウンターを注文。まだこの時は、RADEX1503も正常価格で2万円前後。
- 首都圏で放射線が検知された3/15の午前中に届きました
- この届いた時、オフィス内の放射線量は0.05μSv/hでまだ平和でした。
- 昼を過ぎたあたりで、聞きなれない「ピピッ！ピッ！」というキーボードのクリック音のような音が聞こえました。なんだろうと思っていると、気づけばガイガーカウンターの値が室内で0.8になっていました。窓の外に出して見ると1.5以上。
- 夕方ぐらいから落ち着き始め、翌日16日には0.1台へ。これはまずいと3/16からUstreamで中継を開始。
- 3/21の朝、雨と共に再びアラームがなり始めました。この時の雨雲が放射性プルームだったことを後から知りました。
- この日を境に室内で0.2前後。外は0.3～0.4前後。
- 雨が多い日をきっかけにすこしは下がるがそれほど変わらず
- 以下、中継中の噂
- ある日、Ustreamの中継プログラムがスタックした際、ネット上で「政府の圧力でやめさせられた」との噂
- 市役所に問い詰めた人が、当サイトを紹介されたという噂
- 事務所移転は放射能から逃げるためという噂
- etc
- あとは、同じビルの八百屋さんのPCの画面に常時表示されていた事があとから判ったり、知り合いが弊社でやっていることに気づかず見ていたり、昔の友人から突然連絡があったり、TV局から取材のTELがあったり、といろんなことがありました。(^^
- 最終的にはUstreamは3ヶ月で68万pvでした
ガイガーカウンターを持っているみなさんへ!
みんなで近所の放射線量を地図上にマッピングして公開してみませんか？
そんな支援ツールを作ってみました。詳しくはこちら。
メインの仕事が忙しすぎてなかなか進まないのですが、ようやくあらゆる環境から柏市に設置した私設ガイガーカウンターの値を閲覧できるようにしました。
http://syun.jp/geiger_counter/
Ustreamの画面を１分に１回キャプチャして、OpenCVでカウンター部分を切り出しています。
もしかすると、切り出しが失敗することがあるかもしれません。(^^;
予め御了承願います。
なお、Androidアプリはwosagを使って作ってみました。
去年の夏にはほぼ出来ていたのですが、仕事が忙しすぎて、公開をずっと躊躇していました。
作成に関わったスタッフのみんなにはお詫び申し上げます。
「遅すぎたんだ・・・腐ってやがる」って感じになってしまいましたが、いまさらながら公開をさせて頂きます。(^^;
ターゲットは、コンテンツホルダー向けのサービスになりますが、ブラウザでぽちぽちするだけで、スマートフォンアプリを自動生成できるサービスです。
ぶっちゃけ、Android端末だけでアプリが作れます。
というとすごそうですが、作れるのはRSSリーダーかWebサイトを開くだけのアプリです。(^^;
去年しらべた時は、Google App Inventorではこのパターンが作れず、隙間としてはありだと思っていたのですが、
先日出たFlash Builder 4.5では作れそうです。（未テスト）
また、思想としては、一度の操作で全てのスマートフォンのアプリが作れる予定だったのですが、iPhoneが微妙にヘマったままの公開となっています。すいません。。。
突っ込み処やバグが満載の状況ですが、取り急ぎオープンとさせていただきます。
サイト： http://wosag.com/
御好評(?)いただいており、辞められなくなってしまった(^^;) Ustreamで提供している素人計測のガイガーカウンターモニターの今後のロードマップです。
■4月
・屋外に設置(4/21 9:30作業完了)
・Ustreamをやめて１分ごとの静止画に変更（ガラケー対応、時系列履歴保存目的）
・静止画をつかったスマフォアプリのリリース
■5月
・静止画の解析によるテキスト数値の抽出
・素人計測なので値自体はあてにならないのですが、上昇の検知はあてになりそうなので、検知したときにメールで通知する無料メールサービスの作成
・測定ポイントの複数化（全く同じ測定器を広範囲に複数設置して上昇を検知）
■6月
・サービスの終了(予定。炎天下の熱でこれより前に、機器が壊れて終了する可能性もあります。）
このサービスのページには全て広告を貼り、収益の100%を義捐金として寄付いたします。
震災で被害に遭われた皆様にお悔やみとお見舞いを申し上げます。
■データセンターの状況
データセンターは特に被害はありませんでした。また、計画停電の影響ですが、発電機も完備しておりますので、さしあたっては影響は御座いません。
■弊社の被害状況
オフィスはかなりの物が壊れましたが、スタッフ一同、無事でした。柏オフィスについても、発電機の導入やリモートメンテナンス環境の充実をはかることにより、停電が起こっても業務に影響をきたさない環境を構築する事が出来ました。
■震災に対する弊社の取り組み
社内で保有していたマスク等の物資を現地に送りました。
また、柏オフィス内の、放射線量のUstreamを行っております。安物の装置＆室内窓際なので、どこまで正確かは不明ですが、近隣住民の方々のお役にたてればと思っております。
お客様のサーバで、SSIをふんだんに使いまくっているページがあるのですが、一日に何度も、途中でコンテンツが切れる現象が発生していました。初め、全く原因がわからなかったのですが、SSIが走った瞬間にApacheの子プロセスがSegmentaion Fault(11)で落ちていることがわかりました。色々と格闘したところ、apacheの設定のEnableMMAP offで回避できました。こんなオプションがあったんですね。不勉強でした。(^^;
RapidSSLのWildカード証明書を使っていたサイトで有効期限が切れたので、いつものように更新作業を行ったのですが、なぜかIE,Safari,Chromeは問題なかったのですが、FireFoxだけsec_error_unknown_issuer rapidsslで証明書がエラーになってしまいました。よくよく調べてみると、去年からシングルルート証明書ではなくなっていた事に気づきました。
- wget https://knowledge.rapidssl.com/library/VERISIGN/ALL_OTHER/RapidSSL%20Intermediate/RapidSSL_CA_bundle.pem
- ssl.confに SSLCACertificateFile /etc/httpd/conf/keys/RapidSSL_CA_bundle.pem を追加
ここのところサーバ工事やネットワーク工事で「負け」が続いています。でもこの負けの蓄積こそがIT職人の重要な財産だと思っています。以下は、ここ最近の負け実績です。(^^ゞ
■fsckが途中で10分間停止
客先でlinuxサーバを再起動したところ、180日を経過していた(tune2fsでoffにしていなかった）ので起動時にfsckが走りました。このfsckが29.8%のところでピタっと止まってしまいました。
左脇の「／」がくるくる回るアニメーションも停止したままです。サーバのdisk i/oのランプはつきっぱなしでした。10分まっても状況が変わらず予定作業時間をオーバーしてしまったので、リセット＆fastbootでfsckスキップでサービス再開せざるおえませんでした。ただ、/var/log/messageにもEXT3 Error等は待ったく出ません。
後日、スタンバイサーバへの切替を行い、落ち着いてfsckをかけたところ、やはり同じ29.8%でピタッと止まったのですが、待つこと15分。正常に動き出しました。ちなみにbadblocksでも何も出ませんでした。
教訓：「fsckのアニメーションが10分ぐらい止まってもdisk i/oがあるうちは信じて待つべし」
■日曜日にサーバが過負荷になる
毎週、日曜日、処理が微妙に遅延するという連絡がありました。調査すると確かにロードアベレージが高い。よくよく見ると99-raidなるプロセスがcron.weeklyで起動されていました。
これは、software RAIDのチェックプログラムで、昔は無く、CentOS5の途中からmdadmのパッケージ内で供給されるようになったようです。
このサーバは、2TBのハードディスクをSoftware RAID1していたため、チェックプログラムが半日近く走っていました。ただ、実際には0.1TBぐらいしか使っていないのが現状でした。
教訓：「ハードディスクが大容量になったとは言え、使いもしない容量のパーティションは切らないほうが良い。」
■apacheのリバースプロキシのリクエストが切れる
apacheのリバースプロキシを運用しているサーバで、「時々真っ白の画面になる」との連絡。apacheのログにはエラー無し。tcpdumpをすると、apacheまでパケットは来ているのに、裏の実サーバには届かない。結局原因は、リバースプロキシの設定を外部のシステムから制御できる仕組みがありこの仕組みで/etc/init.d/httpd reloadを使っていた。よくよく調査すると、apachectlのreloadは、セッションは保持されるが、/etc/init.d/httpd のreloadはセッションは保持されないrestartと同じである事が判明しました。
教訓：「/etc/init.d/httpd reload は使ってはいけない」
■SSDなのに異常に遅い
近年、SSDの恩恵に預かることが非常に多くなったのですが、あるときSSDに換装すると逆に遅くなる現象に出くわしました。ベンチマークを取ると数MB/sぐらいしか出ない始末。認識もなぜか /dev/hda1。対策としては、grub.conf のkernelパラメータにhda=noprobe hda=noneで、/dev/sda1として認識されるようになり、ベンチマークも100MB/sを超えるようになりました。
■vistaとwindows7だけインターネットに出れない
あるお客さんの環境で、ある日突然、vistaとwindows7だけがインターネットに出れない現象が発生しました。そのフロアには、Mac,XP,Vista,Windows7と4種類のOSがあったのですが、MacとXPだけは全く問題がありせんでした。wiresharkを使ってパケットを解析すると、ルータまでpingのICMPのパケットは来るのですが、ルータがなぜか応答パケットを返せない始末。結局は、BuffaloのDWR-PGがクレードル経由でネットワーク上に接続されていたのが原因でした。DWR-PGはクレードルでLANに接続するとルータとして機能するようになり、この時のIPが既存のルータとぶつかっていたようです。通常同じネットワーク内であれば、pingを打つとIPがぶつかっている場合は、duplicateとワーニングが出るはずなのですが、この時は、HUBのせいかこのワーニングが出なかったため、気づくことが出来ませんでした。
教訓：「pingの応答パケット来ているのにackがない場合はルーティングだけでなく同一IPの機器がネットワーク上にいないが調べるべし」
IT系の仕事にむいているかどうかは、トラブル解決を楽しめる性格（≒マゾ?）かどうかだと思っています。自分は比較的むいているほうだと思うのですが、さすがにこれだけ続くと・・・くたびれました。(^^ゞ
弊社の過去15年の泥臭い現場経験から、保守が数年必要なシステムには、
- 机上論や流行でシステムを複雑にしない
- メーカー固有仕様のハードは使わない
- 出来る限り枯れた技術を使う
という設計ポリシーがあります。
そのため、ほとんどの場合、RAIDについては、メーカー固有のハードウエアを使わず、Linux の Software RAIDで済ませるようにしています。
SSD+Linux Software RAIDという構成がどこまで有効なのか？以下、ベンチマーク結果です。
■システム構成
- CPU Intel(R) Core(TM) i7 920 2.67GHz
- SSD Intel SLC 64G ( X25-E Extreme SATA SSD SSDSA2SH064G1 )
■ベンチマーク方法
- シーケンシャルライト dd if=/dev/zero of=test oflag=direct bs=100M count=10
- シーケンシャルリード dd if=test of=/dev/null iflag=direct bs=100M count=10
■測定結果
- RAID無し （SSD 64G ×1 = 64G)
- シーケンシャルライト 125MB/s
- シーケンシャルリード 187MB/s
- Software RAID1 （SSD 64G ×2 = 64G)
- シーケンシャルライト 121MB/s
- シーケンシャルリード 170MB/s
- Software RAID0 （SSD 64G ×2 = 128G)
- シーケンシャルライト 68.6MB/s
- シーケンシャルリード 400MB/s
リードがほとんどのシステムには有効ですが、書込みの多いシステムについては、Software RAID0は逆に遅くなるようです。
あと、当然、Software RAIDなので、マルチスレッドでCPUに負荷をかけるプログラムが稼動する場合は、影響を受ける事になります。