チラシの裏に書くと捨ててしまうので

いつの間にかサーバの空き容量が20%を切っててびっくり。
調べたらpagefile.sysとhiberfil.sysだけで20GB近く食ってる。ページングファイルは別としてもハイバネーションはいらんだろ。サーバーをサスペンド状態にしておく運用ってなにさ。

コントロールパネル内にある電源オプションから変更できるのかとおもいきや、実はコマンドラインで設定する必要があるとのこと。Vista以降そうなったらしいのだけれど、そうだったかなあ。

powercfg.exe /hibernate off で無効
powercfg.exe /hibernate on で有効

いつもどおりマイクロソフトの仕様です。

Windows を実行しているコンピューター上で休止状態を無効にする方法および再度有効にする方法
http://support.microsoft.com/kb/920730/ja

1. [スタート] ボタンをクリックし、[検索の開始] ボックスに「cmd」と入力します。
2. 検索結果の一覧で、[cmd] を右クリックし、[管理者として実行] をクリックします。
3. ユーザー アカウント制御からメッセージが表示される場合は、[続行] をクリックします。
4. コマンド プロンプトで、「powercfg.exe /hibernate off」と入力します。
5. 「exit」と入力し、Enter キーを押します。

念のためサーバは再起動させました。必要なかったかもしれないけれど、念のため。

結論から言うとUNC (\\サーバ名\フォルダ名)でアクセスしなさい、という事です。

もくろんでいたのは、別システムがsambaの共有ディレクトリ上に定期的に吐きだすテキストデータを、SSISパッケージ化したタスクで取得＆データベースに取り込むというシナリオでした。その際にsambaの共有ディレクトリをQ:ドライブにマップして「Q:\hogehoge\Datafile.txt」という形式でアクセスしてやれと。

ところがSSISタスクを作成し手動で実行すると問題なく動作するのに、SQL Serverエージェントの定期ジョブに登録＆実行するとエラーで停止してしまうんです。その際に表示されるエラーはこんな感じで、なんというか、決して親切ではないですね。

開始: xx:xx:xx
エラー: 20xx-xx-xx xx:xx:xx.xx
コード: 0xC002F304
ソース: ファイル システム タスク ファイル システム タスク
説明: エラーが次のエラー メッセージで発生しました: “パスの一部が見つかりません。”。 エラー終了
DTExec: パッケージの実行から返されました DTSER_FAILURE (1)。

試行錯誤の末、ローカル上に置いたファイルであれば問題ない事が判明。ネットワーク経由でのファイルアクセスが原因だという事になり、アクセス権限やらSSISパッケージのProtectionLevelの変更やら、いろいろ試したけど全部ダメ。

結局ネットワークドライブがそもそも使えねんじゃね？という結論にたどり着きました。
Windows Server 2000の関連資料としてこんな記述を見つけましたが、Windows Server 2008でも同じ現象が起きます。

ネットワーク ドライブの削除、再利用ができない
http://support.microsoft.com/kb/417903/ja

上記資料の「原因」の欄にある「SMB (Server Message Block)セッションは、ログオンとユーザー アカウント毎に管理されます。」というのがすべてを物語っています。つまりドライブレターの割り当ては、アカウント固有というわけではなくアカウントかつそのセッション固有のものである、と。

探してみたら同じような事しようとしてハマった人を発見。
フォーラムとはいえ、回答者によって「できる」「できない」で真っ二つに分かれているのがなんとも。
今回の件でいえば「ちゃっぴ」さんが正解です。

ネットワークドライブへのバックアップ
http://social.msdn.microsoft.com/Forums/ja-JP/sqlserverja/thread/d81f3dbc-9235-45e4-9743-2f854e5647d9

結論から言えば/var/php.iniのmemory_limitの上限を引き上げれば解決します：

[変更前]
memory_limit = 16M
[変更後]
memory_limit = 64M

(変更後は 「service httpd restart」 を実行してapacheを再起動すること。念のため)

ズボラな私は基本的に自動アップデートで済ませてしまうのですが、バージョン2.9.1以降、以下のメッセージが表示されたままウンともスンとも言わないという状態が続いていました

http://ja.wordpress.org/wordpress-2.9.1-ja.zip からアップデートをダウンロードしています。

その前後でサーバの移行などしていたためエラー原因が絞りきれず、とりあえず放置しておいた(笑)んですが、2.9.2がリリースされても同様の現象が確認されたので、とりあえず/var/log/httpd配下にあったapacheのエラーログを確認したらそのものズバリなエラーが。最初から見とけよ。

[Fri Feb 26 08:20:10 2010] [error] [client 192.168.XXX.XXX] PHP Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 2804864 bytes) in /xxx/xxx/tokiwasou.com/memo/wp-includes/http.php on line 1331, referer: http://www.tokiwasou.com/memo/wp-admin/update-core.php

要はPHP実行に必要なメモリが足りんと。どうやらサーバ移行した際にPHPに割り当てるメモリサイズ(memory_limit)を、デフォルト(16M)のまま放置しておいたのが原因のようです。33MB超のメモリを割り当てようとしてコケたみたいなのでとりあえず上記のmemory_limit=64Mで回避しましたが、このあたりのさじ加減はサーバによって異なると思うので、64Mで失敗する方は128Mでも256Mでもサーバのリソースが許す限りお好きな値をどうぞ。

Microsoft SQL Server Management Studioを使ってテーブルをデザインし、いざ作成(または変更を適用)しようとすると、

「変更の保存が許可されていません。行った変更には、次のテーブルを削除して再作成することが必要になります。再作成できないテーブルに変更を行ったか、テーブルの再作成を必要とする変更を保存できないようにするオプションが有効になってます。」

と冷たくあしらわれ、キャンセルするかテキストファイルに保存するしかない状況に追い込まれます。

てっきりデータベースのセキュリティ設定に引っかかったと思い、ユーザ追加したりパーミッション変更したりと色々やってみたのですがダメ。

つまるところDB側の問題ではなく、なんとMicrosoft SQL Server Management Studioの初期状態ではテーブルの作成を必要とするような変更はできないようになっている、というオチでした。

解決策：

1. Microsoft SQL Server Management Studioの「ツール」メニューから「オプション」を選択し、ツリー表示の中から「Designers」をクリック
2. 「テーブルの再作成を必要とする変更を保存できないようにする」チェックボックスを外す
3. 「OK」を押して完了

うっかりミスを減らすためとはいえ、サーバ側でなくツール側に制限かけとくってどうなんでしょ。手間が増えるだけであんまり効果はないと思うんですけど。少なくとも僕は引っかかりました。

KB967723はセキュリティ用の更新プログラムなのですが、こいつがコケます。
しかもコケるので放置しようとすると「インストールしてください」というポップアップが定期的に表示されてイラッとします。
%SystemRoot%\SoftwareDistribution\Download以下のファイルを全て削除するとか、BITS(Background Intelligent Transfer Service)サービス再起動したりとか色々やってみたのですがうまくいかず、結局個別にパッチ落としてインストールしたら問題なくインストールできました。なんなんだ、、、

Windows Server 2008 用セキュリティ更新プログラム (KB967723)

32bit:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=35c1d5a9-a953-4fc6-90c0-d2358c7b89e6

64bit:
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=6e46822e-f79d-492d-ad01-ee680ad324f5

Service Pack2適用前後で発現しているので、ひょっとしたらこいつ絡みかも。
ちなみに当方ではSP2適用後にKB967723を個別にダウンロード＆手動インストールで上手くいきました。64bit版です念のため。

Windows Server 2008 評価版の試用期間は 60 日ですが、これは最大3 回までリセットすることができます。これにより試用期間を最大 240 日まで延長することができます。

• コマンドプロンプトを表示する 。「スタート」から「コマンド プロンプト」 をクリックするか、「スタート」から「ファイル名を指定して実行」を選択後「ｃｍｄ.exe」と入力する
• 「slmgr.vbs -rearm 」と入力する
• サーバを再起動する
• 再びコマンドプロンプトを開き「slmgr.vbs -dli」 と入力する
• 現在のライセンスの状態を示すウィンドウが表示されるので、試用期間が 60 日にリセットされていることを確認する

うーん、まさにチラシの裏。ちなみに元ネタはこちら。

http://support.microsoft.com/kb/948472/ja

データベースの一括バックアップは、当然ですがサーバの負荷も高くなるため、サーバリソースに余裕がある(あるいはデータベースが十分小さい)場合でないと躊躇してしまいます。少なくとも本番環境などではあまり現実的ではない選択肢なので、普段はmysqldumpコマンドで該当テーブルのみピンポイントでバックアップして不慮の事態に備えるようにしています。

# mysqldump -u [username] -p [password] -t [database] [table] | gzip > [filename].gz

パイプ使ってgzipに渡してあげれば、圧縮する手間も省けて便利。
ただ圧縮にはそれなりにCPUの負荷がかかりますので、ディスク容量に余裕があるなら無圧縮でダンプを吐き出すのもあり。

# mysqldump -u [username] -p [password] -t [database] [table] > [filename]

まあVMware Server とか ESXiとか使ってるのであれば、VMのスナップショット取っちゃうのが一番簡単なんですけどね。スナップショットのリストアが高負荷なのでアレですが、それに勝るお手軽さが魅力です。

ESXi 3.x以前はRPMパッケージで提供されいていたVMware Toolsですが、vSphere 4からはソース(tar.gz)しか提供されなくなったみたいです。俺が見つけられないだけという可能性はさておき、毎回tarで解凍するときのオプションなんだっけと検索するのも面倒なのでメモっておきます。

(1) vSphere Client上で対象VMを右クリック->「ゲスト」->「VMware Tools のインストール／アップグレード」を選択。ごちゃごちゃメッセージが表示されますがとりあず「OK」を押す

(2) イメージをマウント＆コピーする
# mount /mnt/cdrom /mnt
# cp /mnt/cdrom/VMwareTools-4.0.0-171294.tar.gz /root
# umount /mnt

(3) tarボールを展開してインストールプログラムを実行する
# cd /root
# tar zxf VMwareTools-4.0.0-171294.tar.gz
# cd ./vmware-tools-distrib/
# perl vmware-install.pl

(4) 全ての質問に何も考えずエンターを押し続ける

(5) おしまい

念のためvSphere Client上で対象VMの「サマリ」のタブをクリックしてVMware Toolsの項目が「OK」になっていることを確認すればなおよろし。

今気づいたですけどvSphere 4からCentOS 3.x系が「Red Hat Linux Enterprise 5」ではなく「その他の2.6x Linux」として認識されるようになってる。ソースしか提供されないのってひょっとしてこのせいアルか？

PFエラーなのでメモリ関係のトラブルだとは思うのですが、原因はまだ分かってません。

症状としては不定期に突然ホストが赤紫色？の画面を表示して落ちてしまいます。エラーメッセージはすべてPFエラーなのですが、それに続くエラーコードは毎回異なるという状態です。

最初はESXi 4.0固有の問題かと思って色々調査していたのですが、実はESXi 3.5 から ESXi 4.0 へのアップグレードと同時にメモリも増設しており、とりあえずそっちの原因を疑っている状況です。

というのも、ESXi 4.0アップグレード当時のメモリ構成が

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: UMAX 1GB (C)
Slot4: UMAX 1GB (D)

で、運用途中に突然死。
メモリ不足なのかなーと新たにメモリを追加して

Slot1: CFD 2GB (A)
Slot2: CFD 2GB (B)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

という構成で運用していたのですが、これでもタメ。
ならば(A)(B)メモリが原因かと思い、この２本を外して

Slot1: (空)
Slot2: (空)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

これだとOK。ただしこれだとメモリが足りなくて運用上支障が出るので、最初に外したUMAXの(C)(D)メモリを追加して

Slot1: UMAX 1GB (C)
Slot2: UMAX 1GB (D)
Slot3: CFD 2GB (E)
Slot4: CFD 2GB (F)

としたら数時間でアウト。(涙)
とりあえず現在は

Slot1: CFD 2GB (E)
Slot2: CFD 2GB (F)
Slot3: CFD 2GB (A)
Slot4: CFD 2GB (B)

という構成で様子を見てます。
以前試した(A)(B)(E)(F)状態と似たようなものですが、メモリセットの位置をずらしてます。これで何も起きなければ幸せになれるんですが、私の経験上そんなハッピーエンドが待っている確率は非常に低い事も理解しております。

ちなみに被疑者である(A)(B)(C)(D)メモリは、全てMemtest86+を数回走らせてチェックしてみたのですがエラーは発生しません。なんなんだ、、、

現時点で考えられる原因は、
(1) ML115本体のメモリスロット(Slot1 or Slot2)がイカれた
(2) ML115のバグ (BIOSは一応最新)
(3) ESXi 4.0のバグ

ぐらいでしょうか。とりあえず次回同様の症状がみられたら、一度ESXi 3.5に戻して様子を見たいと思います。

今朝ルーターが落ちていたのが原因で、ほぼ丸1日サイトにアクセスできない状態になっていました。ごめんなさい。

障害そのものは朝の段階で検知・対応していたのですが、DNS情報の更新スクリプトが24時間に1回しか回らない設定になっていた(というか俺がした)ので、ついさっきまで外部から接続できない状態に気がつかなかったのでした。ごめんなさいごめんなさい。

とりあえずcronによる更新頻度を3時間毎に上げたので再発はしないはず。
話をそらす目的も含め、cronを書くときにいつも参考にしているサイトを紹介させていただきます。
(お世話になってます！)

crontabの書き方