C# MVCのSessionが使うメモリ量を可視化する調査手順

C# MVCアプリで何気なく使っている Session.Add()。

しかしその裏では、Sessionのモード設定によって「保存場所」「消費されるリソース」「障害の出方」が大きく変わります。特に InProc の場合、Sessionは IIS のワーカープロセス（w3wp.exe）のメモリに直結し、気づかないうちにプロセス肥大やリサイクル原因になることも珍しくありません。

この記事では、

Session.Add の正体
モード別（InProc / StateServer / SQLServer）の保存先
実務でよくある具体例
メモリ・運用面での注意点

を順に整理します。

C# MVCの Session.Add とは何をしているのか
Sessionの保存先を決めるのは sessionState mode
InProc：Session.Add = w3wp.exe のメモリに保存される
StateServer：Session.Add = aspnet_state.exe のメモリに保存
SQLServer：Session.Add = DBテーブルに保存
まとめ：Session.Add の保存先と実務的な判断基準

C# MVCの Session.Add とは何をしているのか

まず前提として、Session.Add は 「どこかに保存するAPI」ではありません。

実体は 現在の SessionState に対してキーとオブジェクトを関連付ける操作です。

Session.Add("UserName","tanaka");

この1行で行われていることは、概念的には次のようなものです。

SessionID（CookieやURLで識別）に紐づく
セッション用のKey-Valueストアに
"UserName" → "tanaka" を格納

👉 「どこに保存されるか」は、SessionStateのモード設定次第になります。

Sessionの保存先を決めるのは sessionState mode

Sessionの保存場所は、web.config（またはIIS設定）の以下で決まります。

<sessionStatemode="InProc" />

主なモードは次の3つです。

InProc
StateServer
SQLServer

ここからは 「Session.Addした瞬間、実体はどこへ行くのか」をモード別に見ていきます。

InProc：Session.Add = w3wp.exe のメモリに保存される

InProc（デフォルト）の場合、Sessionは IISワーカープロセス（w3wp.exe）のメモリ上に保持されます。

<sessionStatemode="InProc" />

具体的な保存先

プロセス：w3wp.exe
メモリ領域：.NET マネージドヒープ（主に Gen2）
ライフサイクル：
- アプリ再起動
- IISリサイクル
- AppPool停止
  → 全Session消失

具体例①：軽いデータの場合

Session.Add("LoginUserId",12345);
Session.Add("UserRole","Admin");

int / string 程度
メモリ影響は小
セッション数 × 数十バイト程度

👉 問題になりにくい

具体例②：危険な例（よくある）

Session.Add("SearchResult", dataTable);

DataTable（数千〜数万行）
各ユーザーごとにコピー
Gen2に長期間滞留

👉 w3wp.exe の Private Bytes が右肩上がり

実務で起きること

Session Active が増える
w3wp.exe のメモリが減らない
IISリサイクル → 全ユーザー強制ログアウト

👉 「Sessionに入れすぎ問題」の主犯

StateServer：Session.Add = aspnet_state.exe のメモリに保存

StateServerモードでは、Sessionは 別プロセスである

aspnet_state.exe に保存されます。

<sessionState
mode="StateServer"
stateConnectionString="tcpip=127.0.0.1:42424" />

保存先の実体

プロセス：aspnet_state.exe
保存形式：シリアライズされたオブジェクト
w3wp.exe には保持されない

具体例

Session.Add("Cart", cartObject);

cartObject はバイナリシリアライズ
ネットワーク経由で State Service に送信
メモリ消費は aspnet_state.exe 側

注意点

[Serializable] 必須
サイズが大きいと 通信＋シリアライズコスト増
StateServer再起動で Session消失

👉 「w3wpのメモリは守れるが万能ではない」

SQLServer：Session.Add = DBテーブルに保存

SQLServerモードでは、Sessionは SQL Server のテーブルに保存されます。

<sessionState
mode="SQLServer"
sqlConnectionString="Data Source=DB01;Initial Catalog=ASPState;" />

保存の仕組み

テーブル：ASPStateTempSessions など
カラム：SessionItemShort / SessionItemLong
保存形式：バイナリ（varbinary）

具体例

Session.Add("UserProfile", profileDto);

DTO全体がバイナリ化
DB容量増加
IO・ロック・クリーンアップが課題

実務での影響

w3wp.exe は軽い
DBサイズが膨張
セッション削除JOB不調で肥大化

👉 「メモリ問題は消えるが、DB運用問題に変わる」

まとめ：Session.Add の保存先と実務的な判断基準

Session.Add の行き先まとめ

モード	保存先	主な影響
InProc	w3wp.exe メモリ	メモリ肥大・IISリサイクル
StateServer	aspnet_state.exe	シリアライズ負荷
SQLServer	DBテーブル	DB容量・IO

実務での判断指針

小さな値（ID・フラグ） → InProc OK
DTOや一覧データ → Session非推奨
共有・再取得可能 → DB / キャッシュ
一時的・軽量 → Session

よくある改善例

検索結果 → IDだけSessionに保持
カート → DB or 分散キャッシュ
画面状態 → 署名付きCookie