Results for category "運用"

IIS5+レガシーASPでメモリを食いつぶす

IIS5+レガシーASPが稼動しているサーバで、SQL Serverをつついて結果を返すアプリが正常に表示できない障害が発生した。
原因は未だ不明だけど、以下のASPを動かすとDLLHOSTの実メモリ、仮想メモリを食いつぶした後、inetinfoが同様にメモリを食いつぶす事象が発生した。

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
<%
On Error Resume Next
 
Dim file
Dim objFSO
Dim objTS
Dim line
 
file = "ここで存在しないファイルパスを指定する"
 
Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objTS = objFSO.OpenTextFile(file, 1 , True)
 
Do Until objTS.AtEndOfStream = True
    line = objTS.ReadLine
    Response.Write(line & "<br>")
Loop
 
objTS.Close
Set objTS = Nothing
Set objFSO = Nothing 
%>

ファイルの存在チェックを行ってループに入る前に終了させれば回避できるが、こういったASPがどっかに眠っているのだろうか。
IIS5のメモリリーク防止パッチを適用しても改善されなかった。

RoboCopyのGUI版「RichCopy」

かれこれ10年以上稼動しているWebサーバのファイルをバックアップするために、MediaKeeperというソフトを使っていた。

メモリ512MBの環境でミラーリング完了するのに17時間もかかっていたのに、MicrosoftのRobocopyにしてから10分に短縮され、全米が泣いたわけですが、そのGUI版「RichCopy」が出てた。

RoboCopyは多機能すぎてオプションが複雑だったけど、RichCopyはかなり分かりやすくてよいです。

[SEO]Mobile Link Discovery経由のリファラーを調べた

Mobile Link DiscoveryはPCサイトのHTMLでheadタグ内に以下のようなlinkタグを記述しておくと、モバイル端末からのアクセスをリダイレクトしてくれる。auの携帯からYahoo!モバイルとGoogleモバイルで動作が確認できた。

[html] [/html]

SEOの観点だと、PCサイト上にモバイルサイトの紹介ページを作っておいて、PCサイト検索でアクセスされたら実際のモバイルサイトに誘導できる。

アクセス解析で効果測定までやらないと意味がないので、リダイレクトされた場合のリファラーがどうなってるのか調べた。

Googleモバイル
http://www.google.co.jp/m/search?eosr=on&ie=Shift_JIS&mrestrict=mobile&q=(検索キーワード)

mrestrictパラメータはxhtmlとかchtmlはよく見るけどmobileってのははじめて見た。多分ここがmobileだったらMobile Link Discovery経由なんじゃないかと思う。

Yahoo!モバイル
http://search.mobile.yahoo.co.jp/onesearch?p=(検索キーワード)&fr=m_top_e

Yahoo!モバイルは特徴的なパラメータが見当たらなかった。frパラメータはm_top_i、m_top_y、m_top_eを見た事があるので、単純に3キャリアのどれからアクセスしたかの判断にしかならない。

Googleモバイルはパラメータで判断できそうだけど、Yahooモバイルはできなそうなので、Mobile Link Discovery経由のアクセス解析を行うためには、単純にリダイレクト先のURI(http://mobile.example.com/)を記述するんじゃなくて、嘘でもいいから以下のように、どこから来たか分かるようにパラメータを付与しておいた方がよさそう。

[html] [/html]

Yahoo!モバイルやGoogleモバイルでPCサイトを検索する人がどれくらいいるのかは未知数だけど、インデックスされるのはPCサイトのHTMLなので、画面サイズや1ページの容量に制限のあるモバイルサイトで、内部施策だけに頼るよりは来訪の可能性が高まるはず。

1行追加でできるのでやらないよりはマシだと思われる。

気象データ配信システムの障害原因

ITpro – 三つの障害が連続発生、気象データ配信システムのダウンの経緯が判明

この障害に巻き込まれてたのでメモ。
ふんだりけったりですね。

システムの冗長化は色々考えるべき点が多いので難しいんだけど、ポイントとしてはサーバ、ネットワーク、ディスクの冗長化なのかな。

関わっているシステムでも気象データ配信システムと同じような構成を取っているものがあるんだけど、RAID搭載とはいえ共用ディスクが1台な事とか、ネットワークが冗長化されていないなどSPOFが結構ある気がする。

NICのbondingで運用系、待機系サーバそれぞれから共用サーバに2本ずつ接続し、1本がコケてももう1本で稼動するようにして、なるべく待機系に切り替えさせないといった、解決方法はありそう。