Windows メモリ管理の不思議

Windows上でシステム開発を行っていると「メモリの食いすぎ？」なんて話が出てくる。

そんな関係で調べていたらおもしろい事を発見した。

タスクマネージャでメモリ使用量をチェックすることになるが、見ていると不思議な現象が起こる。

最初にアプリケーションを起動して最初の画面が出たときのメモリ使用量は 約16M となっている。
しかし、そのアプリを最小化すると、なんと、744KB にまで極端に減った。
もう一度通常サイズに戻すと、約3M のメモリ使用量となった。

アプリを最小化するだけでメモリの開放が起こったようだ。

ほんまに？

別のテストをやってみた。
C++ で 約400M のメモリを確保するプログラムを作って動かしててみた。

	メモリ使用量(KB)
起動直後 最小化 元に戻す 400M確保 最小化 元に戻す メモリ開放 最小化 元に戻す	2,944 16,636 748K 3,072 64,608 1,064 3,344 4,328 684 2,944

赤字にしている部分が不思議。
400M 確保しているのに 64M しか増えていない。

あれれ？

もう一度動かしてみた。
今度は仮想メモリサイズも確認した。

	メモリ使用量(KB)	仮想メモリKB)
起動直後 最小化 元に戻す 400M確保 最小化 元に戻す メモリ開放 最小化 元に戻す	2,944 16,636 748K 3,072 64,608 1,064 3,344 4,328 684 2,944	9,928 9,940 10,004 401,016 401,016 401,016 10,016 10,016 10,016

仮想メモリのところに 400M を確保している。
なるほど、つまり、Windows200/XP はメモリ管理で実メモリと仮想メモリを一つのプロセスでも使い分けているということ。
そういえば、「メモリ使用量＝ワーキングセット」とWindowsヘルプには書いてある。
つまり、その時点で使ってる実メモリ内の使用量だけが表示されている。
「仮想メモリサイズ＝アドレス空間の総量」とあるから、いわゆる「本当に使ってるメモリ量」は「仮想メモリサイズ」ということだ。

タスクマネージャで、プロセス単位のメモリ使用量の合計と、仮想メモリサイズの合計を出してみたところ、「仮想メモリサイズ合計＋カーネルメモリ」が、タスクマネージャのパフォーマンス・タグに出てくる「メモリ使用量」に近いことが分かった。

それにしても、GC（ガベージコレクション）を調べても、実際のメモリの開放タイミングが読み取ることが出来なかったが、意外なところで開放されるのが発見できた。

やっぱり、タスクマネージャのデフォルト表示が、プロセス単位の「メモリ使用量」だけになってるんで勘違いしがちなんだと思う。
「仮想メモリサイズ」もデフォルトに入れてほしいものだ。

ポートを誰かが使ってる

サーバで動くべきサービスが起動しなくなった。
調べると、必要なポートが塞がってるという。

てことで、そのポートを誰が使ってるかを確認する。

Windows2003Server
1.「コマンドプロンプト」を開く。
2.[netstat -o]コマンドを実行。
3.対象ポートの[PID]を確認。
4.「タスクマネージャ」を開く。
5.「表示(V)」→「列の選択(S)」→[PID]にチェックをつける。
6.[PID]が表示されるので、それを確認。

WindosXP、Windows2003Server以降でしか使えない。

System.OutOfMemoryException の例外がスローされました。

今のプロジェクトで「System.OutOfMemoryException の例外がスローされました。」なんてエラーが出ました。
あきらかにメモリ不足です。

あれ、しかし、メモリは潤沢にあったんではないか？
と思い調べれば実メモリ２Ｇもあり、仮想も足せば４Ｇもあります。
それでもメモリ不足とは、これいかに？

簡単な話でした。
Oracle のテーブルに数万件のデータがあり、それを全て取り込もうとしていたようです。
しかも、VisualBasic.NET の DataSet に。
実行したらあっという間に全てのメモリを使い切ります。

画面表示に使うような、多くて数十件くらいまでなら問題なくても、数万件てのはなしでしょう、って感じです。

PL/SQL ではやりたくないとの事で、VisualBasic.NET からの解決策を考えました。

CREATE OR REPLACE PACKAGE PAC_TEST AS
　TYPE refcur IS REF CURSOR;
　PROCEDURE refCursor(p_cur OUT refcur) ;
END PAC_TEST;
/
CREATE OR REPLACE PACKAGE BODY PAC_TEST AS
　PROCEDURE refCursor(p_cur OUT refcur)
　IS
　BEGIN
　　OPEN p_cur FOR
　　　select * from OracleTable;
　END refCursol;
END PAC_TEST;
/

これを VisualBaseic.NET で ODP.NET を使って動かします。

Dim DBconn As OracleConnection = Nothing
Dim DBcomm As OracleCommand = Nothing
Dim DBreader As OracleDataReader
DBconn = New OracleConnection
DBconn.ConnectionString = " User Id=oraU;Password=oraP;Data source=oraH;"
DBconn.Open()
DBcomm = New OracleCommand
DBcomm.Connection = DBconn
DBcomm.CommandType = CommandType.StoredProcedure
DBcomm.CommandText = "PAC_TEST.refCursor"
DBreader = Dbcomm.ExecuteReader
Do While (DBreader.Read())
　　Console.WriteLine("{0}:{1}", DBreader.GetValue(0), DBreader.GetValue(1))
Loop

これで解決。

VB TextBoxのTextのOverrides

VB.NET での TextBoxにおいて、入力値を編集して返したい場合

[例：入力スペースをRTRIMして返す]
Public Overrides Property Text() As String
　Get
　　Return Rtrim(MyBase.Text)
　End Get
　Set(ByVal Value As String)
　　MyBase.Text = Value
　End Set
End Property

DLL (OraOps10.DLL) を読み込めません

久々に面倒なエラーが出ました。
「DLL (OraOps10.DLL) を読み込めません。」です。

これはネットではあんまり載ってません。
勿論、日本語のページしか分かりませんが・・・

OracleCliantをインストールした後、ODP.NETを使うアプリを実行したときに出ることがあります。
また、昨日まで動いてたのが急に動かなくなることもあります。
そうなると、インストールに失敗したとか、作ったプログラムが悪いとかの騒ぎになります。

しかし、多分、悪者はMicrosoftです。

解決方法は
①OraOps10.DLLに、[Everyone:フルコントロール]の権限を与えます。
②ODP.NETを使うアプリを実行します。正常に動くはずです。
③OraOps10.DLLの[Everyone:フルコントロール]の権限を削除します。

これでエラーが出なくなります。

詳しい原因は別として、今のプロジェクトではこれで治りました。

Oracleのゴミ箱

新しい「Oracle 10g」を使っている。
いつものごとく、マニュアルなんか見ないで動かしている。
まだまだ本番ではないし、工程も詳細の手前やから細かい設定も使ってから。

そんなとこで、プロトタイプを開発するので、テーブルも作って見た。
で、普通に
DROP TABLE ***********;
それから
SELECT * FRPM TAB;
とテーブル一覧を表示してみたら、
X$BINASDLKFE********
X$&3;LKA8VDF********
とか、見た事のない変なテーブル名が一覧に出てくる。

何じゃこりゃ・・・
ひとまず「Oracle 10g」のSQLリファレンスマニュアルを開いて見た。

DROP TABLE ********** PURGE;

えっ、[PURGE]て何や、初めて見る変なキーワードが書かれてる。

首をかしげながら「Oracle 9i」のSQLリファレンスマニュアルを見た。

DROP TABLE ***********;

やっぱり[PURGE]なんて書いてないから、新しい機能のよう。

調べて見ると、[DROP TABLE]するとこれまでは表定義が無くなってたのが、Windowsなんかのゴミ箱みたいに、一旦変な名前で残されるらしい。

ふ～んって感じで、一瞬便利なように感じたけど、やっぱり疑問。
「操作を間違えるようなユーザが[DROP TABLE]なんて使うのかな？」
どう考えてもユーザー用じゃないな。
そう考えると、もしかして、我々SE用に作られたのかな。

やっぱり、保守する人間とかが操作ミスしたりするから、それ対策やな、絶対。

まとまらないプロジェクト、進む工程

今日もPMから「ちょっと五分だけ」と言われて会議に呼ばれた。
たいがい、こんな時は五分で終わるはずはない。
きっちりと一時間はつぶれた。
最後にはPM一号とサブシステムのリーダーが言い合いになる始末。

それにしても今回のプロジェクトはまとまりがない。
私は相変わらず一匹狼で自社から一人で出稼ぎに来ている。
自分がいるチームは一匹狼ばかりだ。
他の多くのチームは会社単位にまとまっている。
逆に書けば、サブシステム単位で別の会社である。

最近は珍しくもない。
必要な人材を必要な人数集めようとしたら仕方ないこと。
だからこそ、一歩間違えると、まとまりに欠けることになってしまう。
誰もが我が身がかわいいから、必要なこと以外はやらない。

そんな時に大事なのは不透明な要件を無くすことだ。
全ての事に責任の所在を明確にすることだ。
そのためにはPMが各サブシステム（各社）のリーダーなり担当者とこまめにヒアリングをする必要がある。
今のプロジェクトの一番の問題はそこだ。
我がチームからも気になってPMには様々に進言をするが、なかなか上手くまとまらない。

それでも工程は進んでいく。
行き先は天国か地獄か。
そんな事は考える前から決まっている。

プロジェクトルーム

先月のこと、手狭なプロジェクトルールから広い部屋に引っ越した。
20人そこそこで満杯の部屋から３倍近くの広さがある部屋に移転。
当初はかなり余裕があって、ゆったりと仕事が出来そうで喜んでいた。
しかしそれは甘かった。
もう60人が入って満席状態。
しかも、まだ机を入れて人が増えるという。
まぁ、座れるから人が増えてもいいんやけど、問題は空調。
見るからに古いビルで、安いのを探したとよくわかる。
なにしろ高度成長期に出来てるから。
新しいめのビルは普通、各部屋の各空調機単位で冷房/暖房の切り換えが出来る。
古いビルはそれが全館で統一されている。
３月にも暑い日があったが冷房には変更出来なかった。
しかも私の周りには開発中に面倒を見るサーバが十数台稼働している。
ビルに問い合わせても切り換えは４月終わりにという。
冷風扇でも持って来るか…
とか考えてたら、昨日の月曜日から冷房が使える。
建物は古くても状況に合わせて迅速な対応。
プチ感動した。

知り合いのブログ発見

gooやなくてYahoo!でなんやけど、知り合いがブログやってると聞いて検索したらすぐに見つけた。
やっぱり主婦だけあって内容も共感する人もここよりはるかに多くて、コメントなんか毎日書かれてる。

オヤジSEでなんか、他人に共感させられそうな事てあるんかな？

男親から見た子育てでも書くか？
でも、子供はもう上は中学入るし、育児なんて感じやないしな。

SEとして業界の事でも書くかな？
なんか、愚痴こぼしそうで、自分がイヤになるやろな。
愚痴こぼすの大嫌いやし。

まあ、そのうち個性も出てくるやろ。
なんか、素の自分として書いてる感じちゃうのが自分で思うし。

それにしても、知り合いのブログ読むのは、なんか変な感じするな。
なんて言うか、友人宅に行って偶然日記を見つけてしもたみたいな。
しかも友人がトイレ行ってる隙に盗み見したみたいな。

気にし過ぎかな？

さすが、goo開発者

朝になってチェックしたら、きちっと夕べの投稿が反映されてる。
どんだけ時間かかって反映されたんかな？

わかった事は、BLOBサーバにキュー待ちさせてるのか、時間かかっても大丈夫なこと。
それと、昔と変わらず、日本の22時くらいはネットにつなげる人が多いって事。

ニフティサーブなんかが全盛期だったインターネットの前の時代も同じ時間帯が混んでた。
ダイアルアップの回線はつながりにくいし、2400bpsという今では考えられないスピードでも、更に遅くなっていた。
まぁ、つなげる先がいっこやから混んだら遅くなるのは仕方ないと、いつも夜中につなげてたな。

インターネットが始まったころも、ADSLなんてなかったから、ダイアルアップで、やっぱり夜の決まった時間には遅かった。
この時はダイアルアップを受けるプロバイダの口が混んでた。
今ではその先、つなげるサイト側のサーバの負荷に起因するようになってきた。

そう考えてくると、次はサーバの増強やけど、Yahoo!とかは昔は遅い時もあったけど、今はあんまり感じひんから、かなり増強されてるんやろね。

gooの頑張りに期待やな。

投稿できない！

もう半時間前になるかな、新しい内容を書き込んで投稿ボタンを押した。
そしたら何事も無く編集メニューが出てきた。
で、「あなたのBLOBを見る」ボタンを押してみると、なんと、投稿が反映されていない。
サーバが混んでるのかと半時間ほど待ってみたが、未だに表示される気配が無い。

まぁ、何にせよ、バグがあるのは確かだね。
サーバ負荷が高いときに、処理的には投稿処理がタイムアウトしたのかな。
こういうタイムアウトは、人気のあるサイトだったらよくある事だけど、問題は、そのままデータが消されてしまうこと。

普通の技術者なら、タイムアウトの場合はリトライをさせて、データを無にするような仕様にはしない。
勿論、私が作るシステムでもそうして来た。

確かにサーバ負荷によるタイムアウトの動作テストなんてのは、確かにその環境を作りにくい。
テスト段階で数千件とかのアクセスをさせられないけど、擬似的にはテストするもんだ。
そもそも、机上で仕様チェックするときに見つかりそうなバグ。

がんばれ、goo開発者。
それより、俺の原稿を返せ！

週末非ネット族

平日は仕事場でインターネットにはつなげ放題で、仕事には不可欠なネット環境。
勿論、仕事中に仕事に関係のないサイトを見ることはない、と言うのは真っ赤な嘘で、適度な気分転換しながら仕事をしている。
だからか週末に家であまりネットにつなげない。

別に家にネット環境がないわけではない。
DHCPサーバも立ち上げ、Proxyも動かし、100Mの16ポートHUBも備え、家庭内LANを構築している。
子供達もそれぞれ、その環境からネットにつなげている。

先週末もネットにつなげなかった。よく考えたら、PCの電源も入れていない事に気が付いた。

週末起業という言葉をよく聞く。
友人からは、SEなんて業界の人やから簡単に出来るんちゃうの？
なんて言われたりもする。
しかし、この状況じゃあ出来そうにあらへんね。

何故やらへんのかなと、昨夜から考えて出た答えは２つ。

１つ目は、単に、週末が忙しいこと。
これは今に始まった事やないし、これからも続くやろうと思う。

もう１つは単に家では、ぼ～っとしたいと思うこと。
週末でも色んな予定や約束、イベントとかあって、結果として家にいる時間が平日と変わらなかったりするし、尚更ゆっくり休みたいなと思うからやな。

まだまだぼ～っとする時はTVで、ネットではないよね。
FUJI+SoftbankかLibedoorかわからんけど、まだまだ未来は先のことやなと思う。

VB.NETで文字化けする

久々に VisualBasic を触っている。
これまで様々な言語で開発をしてきたけど、向いているのか、結構何でも直ぐに出来るようになる。
そういう所もこの仕事を続けてる理由かな。

そんな話はさておき、ＶＢも .NET になってこれまでとは変わってるみたい。
たぶん、これまでのＶＢばっかりの人はとっつきにくいのかな。
なにしろオブジェクト化されて、Classとか使わなあかんし。
C#とかJavaとかやってたら困らないやろうね。

さて、久々で困ったのがファイル出力。
他のツールのテスト用にDBからデータをCSVファイルに書き出す簡単なプログラムを書く事にした。
普通にファイルを作って、開いて、データを書き込んで閉じるだけのプログラムやけど、簡単すぎて動かしてから問題が発生した。
なんと、普通にファイルを開いただけではエンコードが Unicode(UTF-8)になって、日本語が普通では文字化けしてしまう。
勿論、Unicodeに対応しているエディタ（秀丸とか）だと普通に見れるけど、Shift-JISでないと困るから、さてどないするか。
こんな時に頼りになるのはNet、検索をかけてみたが、どういうわけか今回は空振りが続く。
よっぽど基本的なことなんかな、と思ったけど、空振りの答えも似たレベルが多い。
エンコードの設定から調べなおすとすぐにわかった。

【当初】
Dim sw As StreamWriter = New StreamWriter(filename)

【変更後】
Dim sw As StreamWriter = New StreamWriter(filename,False,System.Text.Encoding.Default)

よく見てもらえれば分かると思うけど、引数を省略したらデフォルト値になる思ってたら、わざわざデフォルト値を引数に入れなあかんかったんです。
正直なところ、OSなり.NETframworkを見るなりして、システムのデフォルト値に合わせられへんのかな？
そんな難しい事やとは思わんねんけど、Microsoftも手抜きしすぎやない？

いよいよ始めてみるかな

自社の会議待ちで作ってみた。
仕事柄こういう流行ものも色々とチェックはしてたけど、これまでは作ってみようなんて考えもしなかった。
なんで作る気になったんかな？
自分でもわからんな…