年が明けて風邪をひいた重たい頭でメールを確認していたところ、
先のお客様のosCommerceからさらに複数のメールが届き始めた。
間違いなくお客様のosCommerceを利用して大量にスパムメールが送信されている。
風邪で起きていられないのでLet’snoteを布団の中で手に持って検索してみると、
英語版のosCommerceのあるバージョンだけにバグがあり、そこから登録会員宛に
スパムメールを大量に送信していたことがわかった。
日本語版を使用している場合は問題ないことがわかりひと安心。

先ほども、はじめての方（海外）から相談のメールが届いた。
被害は世界中に広がっているようだ。

ところが 、最近、動画を見ると妙に熱くなるようになった。触れないくらい熱い。
そうなると、いきなりシステムがダウンして、再起動、さらにダウンして再起動を繰り返す。
Windowsを起動するまえに再起動するのできっと熱が原因だということはわかるが、
どうすればいいのかわからず、不自由しながら使っていた。

動画を連続して見ていると30分程度でダウンしてしまう。
CPUのあたりが触れないくらいに熱くなっている。
CPUファンがダメになったのかもしれない。交換は面倒だし、新しいものを購入することもできないので、  きょうは、裏蓋を開けて確認してみた。
すぐに目に付いたのが、CPUファンの汚れ。
ほこりで白っぽいのでエアダスターで吹き飛ばした。
ファンがエアダスターの風を受けて回転し始めるとさらにほこりが飛び出してくる。
ファンからほこりが出なくなったら、熱を逃がす排気口に向かって風をぶつけると、一瞬だが、まるで小麦粉に息を吹きかけたようにほこりが飛び出した。これを2回繰り返すと、まったくほこりがでなくなった。そこでフタを元に戻して、電源を入れてみた。

なんと、まったく熱くならない。

試しに動画をいくつか同時に見てみてもまったく熱が気にならなくなった。

{nd:数字}と{md:数字}が付いている場合
{nd:数字}が付いている場合
商品型番のみまたは商品型番に{md:数字}が付いている場合

のように３パターンにして、文字列から商品型番を抜き出して、同じ商品の場合は数量を加算することで、うまく在庫を確認することができた。

これでうまく動作すると思ったが、注文側で、商品番号が勝手に変わっていることがわかった。osCommerceのオプションは本当に面倒だ。

今回の作業は簡単な方だった。別のお客様だが、コンテンツを全部削除してしまい、何とかして欲しいといわれたことがある。このときは、データベースとトップページののデザイン画面が残っていたので、画像を切り出してトップページを作り、残ったデータベースの内容からosCommerceのバージョンを推測して翌日にはすべて復旧した。
コンテンツの消失は、Zen Cartでも一度あり、このときもバラバラに保存されていたデータをかき集め、もとどおりにした。
緊急の案件は大変だけど、お客様に喜んでいただけるのでやりがいがある。

お困りのことがあればinfo@ynagata.com宛ご連絡ください。
ただし、緊急の作業は高くなりますので、
日頃から、ファイルやデータをバックアップしておくと安心です。

ページキャッシュは、カテゴリメニューなどに使用され、データベースの負荷を下げる機能がある。たとえば、トップページのカテゴリメニューは画面が表示されるたびにデータベースから値を取得して、PHPで整形してHTMLとして正しい形式にして出力される。

他のページを見て、再度、トップページを表示させても同じ処理が実行される。この部分だけでもアクセスが多いサイトだと負荷がかかる。このカテゴリメニューの部分だけをはじめの処理のときにファイルに保存して、2度目にこのページを表示するときはデータベース処理やPHPでの整形処理は省いてファイルから直接読み出して、処理を速くする機能がページキャッシュだ。

osCommerceでは、ページ全体をキャッシュせず、負荷が予想される部分にキャッシュ機能が適用されている。
設定するには、基本設定の「ページキャッシュ」画面を表示させて、「キャッシュを使用」を「true」にする。
注意が必要なのが「キャッシュ・ディレクトリ」に設定するパスだ。

お客様から依頼を受けて調べてみるとまったくページキャッシュが使用されていないことが多い。動作しない理由の大半がパスが適切ではないためだ。この部分が適切に設定されていないとページキャッシュは動作しない。
ここにはページキャッシュ用のファイルを格納するディレクトリ名を設定する。Webから見たパスではなくて、OSのファイルシステムから見たフルパスを設定する。設定したパスはプログラム側から書き込めるように書き込み権限を追加しておく。
正常に動作すると、ブラウザでページを閲覧することで、キャッシュ用ファイルがディレクトリ内に作成されていく。ファイルが生成されていれば設定は成功だ。

これから先は、PHPのプログラミングがわからないと難しいが、トップページの状況に応じてページキャッシュの範囲を広げるとさらに効果的だ。
osCommerceには、処理時間を計測する機能があるので、これでページごとの処理時間がわかる。

最近の私の経験では、トップページの表示に2秒かかっていたがインデックスの追加で0.241秒になり、ページキャッシュを拡張して対応することで、0.063秒になった。

実は、MySQLにはこのような状況に対応するためのMERGEテーブルというものがある。データが多くなったらMERGEテーブルとUNIONで既存のテーブルと新規のテーブルを1つのテーブルとして扱うようにすればいい。検索を実行するときは新旧テーブル全体を対象にして、データを登録するときは新しいテーブルを対象にできるなど、非常に都合がいい。テーブルの作り方を工夫すると連番も前のテーブルを自動的に引き継ぐのでさらに安心だ。

お客様のサーバで複数のテーブルを分割したが、osCommerceを稼働させたまま瞬時に作業を終わることができた。
ただし、準備に時間はかかった。

http://dev.mysql.com/doc/refman/4.1/ja/merge.html

詳細は以下のＵＲＬで確認してください。

http://dev.mysql.com/doc/refman/4.1/ja/mysql-indexes.html

http://dev.mysql.com/doc/refman/4.1/ja/multiple-column-indexes.html

さて、Aspire 5720Gは、ひとつひとつ不具合を解消していくことでフリーズしない時間が長くなってきた。しかし、まだ、フリーズする。
ノートPCなので当然のように作業を終わるとスリープにしていたが、スリープから復帰後にフリーズするようだ。何度か試してみたが復帰後にフリーズ。
以前は検索しても情報が数件程度しかなかったが、今は、似た例をいくつも見つけることができる。どうも、スリープでフリーズすることがあるらしい。
スリープではなく休止状態にして、何度か試してみると、フリーズしなくなった。

今度こそ大丈夫かな。
長時間動画を表示させても熱で止まることもないしAspire 5720G自体は良いマシンなのかもしれないが、正常に動作するまで手間がかかりすぎた。

すぐに、思い出した。
いつも問題なく動作するようにフリーのソフトを使い、
不要なファイルの削除と不要なレジストリのゴミを取り、
レジストリのデフラグとハードディスクのデフラグを動作させていた。
快適に動作するようにと思ってやったことが裏目にでたらしい。
この中で原因になりそうなのがレジストリ クリーナーだ。
レジストリのゴミをとるといっても適切に分析して削除していないのかもしれない。
復元機能を使って数時間前の状態に戻したら、あっさりと復活。
両方のノートPCが正常に動作した。
レジストリはあまりいじらないほうが良さそうだ。

最近、PC用の地デジチューナを購入したが、Let’snoteではパワー不足で快適に表示できない。仕方なくAspire 5720Gで見ているが、どこがわるいのかわからないくらいにフリーズするし、シャットダウンするようになった。

先日、Let’snoteの調子を見るときに使ったProcess ExplorerをAspire 5720Gにもインストールして調子をみることにした。フリーズするときの状況を確認できれば直せるような気がした。

全部外したはずだったのにまだAcer独自のアプリが動作していたことに気付いた。msconfigを使って起動しないようにした。
フリーズ直後に起動するとこのアプリが起動していたので気になっていた。
外部液晶用のソフトも邪魔だったので削除。削除したら、ブルーバックでエラーメッセージまでるようになった。
再度、Acerのサポートページでドライバをダウンロードした。
動画を見ているときによくフリーズするのでビデオ関連のドライバを更新するつもりだった。
以前は、ヨーロッパのサイトに接続して非常にわかりにくい一覧からダウンロードしなければならなかったが、今回はとてもわかりやすいインターフェースになっていた。BIOSのバージョンも上がっていたので、すべてのドライバをダウロードしてBIOSもふくめ全体をアップデートした。

アップデート後、動画を流して朝までそのままにしてみた。朝起きてこわごわ見てみると、地デジが表示されたままだった。フリーズしなくなった。Aspire 5720Gも修正できたようだ。

いま、考えてみると、公開されていたドライバにもバグがあったのかもしれない。