ユーザーアプリケーションとwindowsについて

Question

以前、MicroSoftコミュニティで投稿した内容になるのですが、Windowsアプリケーションベースでカメラ4台から画像の同期取込を行い、ファイル保存(bmpファイル)する処理を40msec周期でオンライン処理で行おうしています。

ソフト開発時はファイル保存を800枚/カメラ4台で行いましたが、所望の枚数(6000枚/カメラ4台)の保存を行うとプアプリケーションの動作が不安定となり、フリーズしてしまいました。(bmpファイルの大きさ:3.58MB/1枚)
画像の200枚保存は出来ていたため、保存処理のCコードには問題がないと予測しており、原因として

・Windows特有の制約
・ディスク書き込み

に問題があると予測しています。
わかる方がいましたら、対策等ご教授の程宜しくお願い致します。

PC及びカメラスペックは以下の通りです。
OS：Microsoft Windows7 Professional 64bit
CPU：Core i7-4770S BOX 3.1GHz、M/B：Intel Z87 Expressチップ
メモリ：32GB(8GB×4)、HDD：250GB(SSD)

開発環境：Microsoft Visual Studio2010 Professional SP1
使用言語：Microsoft Visual C++ 10.0(MFCダイアログベース)

カメラ：IMPERX ICL-B1310C-SC

Answer 1

画像の200枚保存は出来ていたため、保存処理のCコードには問題がないと予測しており

その自信はどこからくるのでしょうか？ 200枚程度の信頼性しかないコードだと判断すべきです。質問者さんの過去スレッド（1、2）からも不安定なコードという印象がします。

「フリーズ」がどのような状況なのかにもよりますが、フリーズしたプロセスをデバッグし原因を探るのが直接的で最も早い解決策だと思います。

# 3.5MB/枚で200枚なら700MB。メモリ不足で落ちそうな辺りの値という見方もできます。

Answer 2

＞佐祐理さん

ありがとうございます。

おっしゃる通り、不安定なコードで200枚程度なら誤魔化せていたのかもしれません。
現段階では、画像集録とファイル保存を分けております。
画像集録に関しては、6000枚分の画素データを格納できるバッファを動的確保し
集録後にファイル保存を行う仕組みにし対応しています。
問題解決のため他の方の意見を聞きたく投稿致しました。

メモリ不足で落ちそうな辺りとは具体的にどういう事でしょうか。

Answer 3

切り分けとして、たとえば、ファイルにWriteしている部分だけコメントアウトした場合、
6000個の(0バイトの)ファイルは安定して作成できるんですか？

---

jzkey

Answer 4

>jzkeyさん

安定して作成できているようで、取り込みだけですとタスクマネージャを見てもCPU使用率、メモリに異常はみられませんでした。

Answer 5

200枚で700MB、仮に保存作業で内部的に１回コピーが行われていた場合に２倍のメモリを使用していれば1.4GB。これは32bitアプリケーションで動的に確保できるメモリ量の限界に近い値ではあります。

フリーズしたプログラムをデバッグしたりはしないのでしょうか？

Answer 6

＞佐祐理さん

ご回答ありがとうございます。

32bitでなく64bitアプリケーションで作成しております。

そこを追究するのは本筋ではなかったため集録と保存は切り離して再実装した次第です。

デバックに関しては、画像取込/保存処理を行っている際、デバイスマネージャを起動し、メモリの動きを確認しました。

その結果、40msecで安定して画像取込/保存できている間はメモリの値が上昇しており

不安定になるとメモリの値が飽和してしまう現象を確認しています。

メモリは32GB搭載していますが、集録開始時の約2GBから上昇していき約4GBで飽和してしまう状況です。

200枚と記載したのはメモリの値が上昇中に保存している枚数になります。

ユーザーアプリ側からの書き込み速度に対してファイル生成を行う速度が遅く、連続的に保存させるとメモリ関連で不具合が生じている

のではないか予測しています。

Answer 7

> ユーザーアプリ側からの書き込み速度に対してファイル生成を行う速度が遅く、
> 連続的に保存させるとメモリ関連で不具合が生じているのではないか予測しています。
あなたの開発されたアプリの処理速度が速く、ファイル I/O がそれに追いついていなくて、今回の問題が起きている。。。という認識なのでしょうか？
（つまり、星の数ほど存在する他の Windows アプリは処理速度が遅いので、「あなたの開発されたアプリ」以外では、ファイル I/O の速度は問題にならない。。。という認識ですか？）

> デバックに関しては、画像取込/保存処理を行っている際、デバイスマネージャを起動し、メモリの動きを確認しました。
それは "デバッグ" ではないと思います。（単なる確認では？）
以前にも提案しましたが、ライブ デバッグが出来ないのであれば、アプリがフリーズしたタイミングでの「プロセス ダンプ」（あるいは「完全メモリ ダンプ」）を採取し、それを解析できる人にお願いした方が早いと思います。
（あるいはこのフォーラムでダンプ ファイルを公開してみるとか。）

Answer 8

＞お馬鹿さん

ありがとうございます。

>あなたの開発されたアプリの処理速度が速く、ファイル I/O がそれに追いついていなくて、今回の問題が起きている。。。という認識なのでしょうか？

一般的にWindows上で書き込み処理を行う場合
①Windowsからの書き込み要求
②画像データをいったん一時バッファ(メモリの一部)へコピー
③HDDへファイル生成

※この時、処理速度は①＞②

という流れで行われていると解釈しています。(見当違いなことを言ったらすみません)

カメラからの画像取り込みは随時実行されているので、ファイル生成が終わる前に次の書き込み要求が来てしまい
結果的に、一時バッファ(メモリの一部)が一杯となり指定周期で処理が回らなくなると認識しております。

ダンプ に関しても取り組んでみたいと思います。

Answer 9

デバイスマネージャ（タスクマネージャの誤字？）の2GBとか4GBとか、数値だけ出されても何を計測した値なのかも併せなければ意味がありません。プロセスのメモリ使用量ですか？ それともシステム全体の使用量ですか？ 32GBの方はシステム全体なわけですが。

付け加えるなら「フリーズ」も「不安定」も質問者さんの主観的な表現でしかないため、他者とコミュニケーションすることはできません。もっと客観的な情報を出すべきです。

回答者によって異なる意見がある点は申し訳ないとは思いますが、お馬鹿さんの勧めるダンプには取得するだけでもスキルを要します。ただ、一般的にはもっと手軽な問題であり、それに対するデバッグ方法としてはその名の通りデバッガーで調査します。アプリケーションレベルでの「フリーズ」であればOSやデバッガーは動作を継続することができ、フリーズしたアプリケーションの問題行を提示することができます。

Answer 10

> 一般的にWindows上で書き込み処理を行う場合
> ①Windowsからの書き込み要求
> ②画像データをいったん一時バッファ(メモリの一部)へコピー
> ③HDDへファイル生成
> ※この時、処理速度は①＞②
> という流れで行われていると解釈しています。(見当違いなことを言ったらすみません)

↑ものすごく大雑把な解釈だと思いますが。。。
②はファイルシステム キャッシュのことを言っているのだと思いますが、一般的にファイル I/O はファイルシステム キャッシュに対して行われます。
（もちろん、アプリ側の実装次第で、ファイルシステム キャッシュを使わないこともできますが、あなたがファイルシステム キャッシュを意識していないことを考慮すると、今回の場合はファイルシステム キャッシュ経由のファイル I/O であると考えられます。）
ファイルシステム キャッシュ経由でのファイル I/O の場合、HDD などストレージへの実際の書き込みは、アプリからの Write I/O とは非同期 (Lazy Write) で行われます。
つまりほとんどのファイル I/O は、ストレージ デバイスのアクセス スピード能力の直接的な影響は受けないはず。。。というのが私の理解です。
実際、Windows OS は常にファイル I/O を行っていますし、あなたの主張される推測が仮に実際に起こっているならば、おそらくほとんどすべてのアプリで大問題となっているはずです。
（もしあなたの推測が正しいならば、物理メモリの使用率は 100% に近い状態となっているはずで、システム自体がハング寸前の状態になると思います。）

あなたのこれまでの投稿を読むと、常に「自分以外の他者に問題の原因がある」という前提の基で解決策を見出そうとしている感じを受けます。
ですが私からみると（私「だけ」ではないと思いますが）、今回投稿されてる問題は、あなたのアプリ側の実装に起因して起きている現象としか思えません。
（なぜ、「推測」に基づいて解決策を得ようとするのか、私には理解できませんでした。）
ソフトウェア開発者なら、問題現象に直面した際にすぐに解決策を求めるのではなく、きちんと原因究明を行ったうえで対応策を検討すべきだと思います。
現状把握なしに、適切な対応策などあり得ない。。。というのが私の信条です。

ちなみに、ダンプ ファイルですが。。。
今回の問題が Local Procedure Call 関連で起きている場合、「プロセス ダンプ」ではなく「完全メモリ ダンプ」の採取/解析が必要になると思います。