WindowsXPのページファイルのサイズについて

先日、ページファイルを変更して安定稼働しているようなので、備忘録として掲載します。

現在のメインPCのスペックは「CPU: CeleronD 346 (3.06GHz)、MEM: 2.5GB」です。
既に型落ちしていますが、がんばってくれています。

ただ、最近WindowsXPを再インストールしたあたりから、挙動がおかしくなっていました。
私は普段タブブラウザを使って複数の画面を開いて作業します。
結果的に40以上のタブを開けていた、なんて時もあります。

そうなると当然、ブラウザが徐々に重くなるわけですが、作業中すぐにCPU占有率が上がってしまい、且つ下がりにくい状態が続いていました。
また、CPU占有率が上がっているときは例外なくHDDアクセスランプが点滅しっぱなしになります。

で、色々試したのですが、結果はページファイルのサイズ *1 が原因だったようです。

WindowsXPはデフォルトでページファイル容量を、搭載メモリ量の1.5倍を標準に、3倍をMAX値に設定します。
そのため、標準で3.8GBのページファイルが作られ、それに対してのI/Oが発生します。
このI/Oが(断片化などで)負担をかけていたようです。

WindowsXPの場合は、(大きなアプリケーションを起動しなければ)今回の搭載メモリ量である2.5GBを超えるメモリを消費しません。
そのため、とりあえず標準のページファイル容量を512MBに変更してみました。
相変わらずタブを開きすぎると重いですが、レスポンスが体感できるほどに改善しました。

メモリを多く搭載しているのに思ったよりパフォーマンスが出ないときは、ページファイルを見直してみるのもよいかもしれません。


*1:
ページファイルとは、Cドライブの直下にある「pagefile.sys」のことで、以前はよくスワップファイルなどと呼んでいたと思います。
詳細は、アットマークITの下記記事が参考になると思います。
http://www.atmarkit.co.jp/fwin2k/win2ktips/077setpgflmin_max_eq/077setpgflmin_max_eq.html
http://www.atmarkit.co.jp/fwin2k/win2ktips/076pgfilesize/076pgfilesize.html

最近、巷でBCPという言葉を聞くことが多くなりました

BCPとは事業継続計画と呼ばれ、要は「何かあってもお客様に迷惑をかけないように」する仕組み・段取りのことです。
「何かあっても」と状況を特定しないのは、災害や電力供給・パンデミックなど広範囲の状況が想定されるからです。
そして、その状況下で出来るだけ滞りなく業務を遂行することが求められます。

システム周りで見てみると、
・止まると困るシステム（許容できる時間はそれぞれですが）
・数日間止まっても問題ないシステム（人海戦術で対処可能等）
に大別されると思います。
（今回はパンデミックなどの出勤できない状況は除外しています）。

ただ、そうは言ってみても、会社・部署により仕事の進め方・慣習は色々ありますから、人海戦術でやるにしても難しかったり、システムの冗長化の予算が下りなかったりと困難が待ち受けていると思います。

私を取り巻く環境もそう違わず、出来ることをやろうと言うことになり、手持ちのリソースで冗長化していくことになりました。

そこで、まず最近実装されたPostgreSQL(以下,Postgres)のレプリケーション機能を試してみることにしました。
また、それに伴い、Apache・PHPのバージョンも上げることにしています。

・Apacheのバージョンアップにについて(1.3→2.2)
Apacheのバージョンアップについては、特に問題はありませんでした。
元々、開発環境のバージョンを上げていたため、忘れているだけで修正していたのかもしれませんが。

・PHPのバージョンアップ(4→5.1)
こちらは、一部ですが修正が必要でした。
(まだテスト中ですが)私の環境では「array_merge」まわりを修正しました。
PHP4の時は引数に配列でない(空の変数)があっても無視されるだけでエラーになりませんでしたが、PHP5だとエラーになりました。(そもそもいけないんですが・・・)

ただ幸いなことにクラスや非推奨の関数はほとんど使っていないため、それほど大きな修正をせずに移行できそうです。

・Postgresのバージョンアップ(7.4→9.0)
Postgresはバージョンアップに伴い、設定ファイル(postgresql.conf)を変更します。
これは、記述方法が異なることと、各パラメータの最適値が異なる可能性があるためです。(未調査)
また、SQLの実行計画についても変更になる可能性があるため、こちらも調査予定です。(そのままでも動くはずですが)

実際に環境を構築してパフォーマンスを計測した後で、このレプリケーション機能を使用するかどうかを決める予定です。

VMWareServer導入時の注意点

テスト環境の変更に伴い、久々にテスト用PCのセットアップを行いました。

今までは、NIC2枚刺し＆VMWareServer上のapacheでバーチャルホストしてました。
（ホストOS、ゲストOSともにCentOS4.6で構築していました）。
これについては、そのうち機会があったら備忘録として載せたいと思います。

今回は、ホストOS：WindowsXP_Home_SP3、ゲストOS:CentOS5.6で構築しました。（VMWareServerは1.0.10）
VMWareServerコンソールはリモート接続も可能なので、あまり必要ありませんが、ホストOSにはVNCを導入しています。
ちなみにVNCはサーバ側にRealVNC、ビューア側にTightVNCを使用しています。

で、注意点ですが、私はポートを開け忘れてつながらない・・・という状況によくなるので、ポート番号を備忘録として残します。

・VMWareServerでリモート接続　→　ポート：902
・VNC　→　ポート：5900（ポートを手動で設定した場合は、それを指定します）。
・リモートデスクトップ接続(ターミナルサービス)　→　ポート：3389　※WindowsXP以上のProfessionalエディション以上

PostgreSQLのデータ型によるテーブルサイズについて

今日は、データ型の話をしたいと思います。

現在、勤め先でお守りしてるDBにPostgreSQL7.4(以下、Postgres)があります。
このPostgresは総レコード数200万件でDBサイズが4GBありますが、前任者不在の状態で引き継いだため不思議仕様が結構あります。

例えば、データ型の定義の仕方。
一例を挙げると、文字データ型が全部character(一部text)だったりします。
ちなみにcharacterで定義してあるので、取得後にTrimして使ってます(．_．)。

Postgresの公開文書を見ると、character、varcharに性能の違いはないと記載されています。
(参考URL:http://www.postgresql.jp/document/current/html/datatype-character.html)

また、非常に参考になったのが"Let's Postgres"の「文字列型の使い分け」のページです。
(参考URL:http://lets.postgresql.jp/documents/technical/text-processing/1/)

このページでは、データ型ごとに消費するバイト数が異なるので、それぞれ適したものを使用しましょうと記載してあります。
当たり前のことですが、わかりやすいです。

でも考えてもピンとこなかったので、テスト環境で単純にcharacterとvarcharのサイズの違いを比べてみました。

今回テストに使用したテーブルの概要です。
・レコード数：35万件
・テーブルサイズ：315MB
・全カラム数：49
・文字データ型のカラム数：35
・文字データ型の文字数：599文字(Postgresはバイト数ではなく文字数で定義します)
※ちなみにほとんどの項目が定義した文字数の半分も消費しません

別名でテーブル(characterをvarchar(character varying)に定義して、ダンプしたデータを流し込んでみると、
・テーブルサイズが、315MB→143MBへ減少
・キーとインデックスのサイズが増加(キー：15MB→21MB、インデックス：13MB→15MB)
となりました(どちらもvacuum full、reindex実施)。

テスト結果と参考URLの記事を元に考察すると、
・セットする文字数が変動するものは、varcharの方がサイズを小さくできる(可能性有り)
・固定長のデータをvarcharで格納するとデータサイズが大きくなる可能性有り(キー、インデックスは共に固定長の項目)

非常に驚いたのは、テーブルサイズの減少です。
半分以下です。
これはパフォーマンスの向上を期待できます。
(データ量が減れば、共有メモリ(Shared buffers)を占有する容量が減るので、キャッシュヒット率が上がります)。

また、"Let's Postgres"にはcharacterの型変換による性能劣化の一例が上がっています。
ここら辺も調査して、実際にデータ型の変更を行いたいと思います。

viの文字コードを指定する

viでログファイルを見るときに、tailだと文字化けしないのにviだと文字化けするので面倒だなぁ～と思っていました。
どうもRedHatはviでEUC以外のファイルを開くと化けるらしいです。
（うちのサーバはなぜかSJIS）。

で、調べたら、文字コードを指定する方法がありました。
SJISにしたい場合は、「:e ++enc=sjis」でOKとのこと。
ちなみにその他文字コードは、
:e ++enc=utf-8
:e ++enc=euc-jp
:e ++enc=iso-2022-jp
等です。

でも、なぜか「CONVERSION ERROR」になり文字化けが直りません。
起動直後に文字コードが設定されていないときに、この「CONVERSION ERROR」になるので、その場合は、文字コードをセットしてあげます。
例):set enc=sjis

これでやっと正常表示されました。