社内のメーリングリストに「SQL Serverプロセスがメモリリークしていて、調査を助けてほしい。」というメールがとんできました。よく読んでみると、どうやら、過去に私が担当したことのあるお客様の環境のようです。
案件の概要
社内のメーリングリストに「SQL Serverプロセスがメモリリークしていて、調査を助けてほしい。」というメールがとんできました。よく読んでみると、どうやら、過去に私が担当したことのあるお客様の環境のようです。私がお手伝いしたのはSQL Server 2000からSQL Server 2005へのアップグレードプロジェクトでしたが、つい数カ月前にその環境をSQL Server 2012へアップグレードしたとのこと。そして、最近になってSQL Serverプロセスのメモリ - private bytes - が右肩上がりに増えていることに気がついたらしいのです。
private bytesが右肩上がりに増えるということは…
さて、SQL Server プロセスのprivate bytesが右肩上がりに増えると、なぜSQL Serverがリークしているということになるのでしょう?お客様は、SQL Serverのサービスアカウントにlock pages in memory特権を与えて、AWEモデル*1を使用していましたが、working setを見てもAWEのようなnonpageable memoryはカウントされないからでしょうか?でも、working setとprivate bytesは別物です。
*1 SQL Serverのメモリモデルは、Conventional (既定), AWE, Large Pageの3つがあります。
実は、「private bytesが右肩上がりに増える」という情報だけでは、リークしているかどうかはわかりません。Windows Server 2012以降、AWEのメモリはprivate bytesとして確認できるようになっていますし、private bytesとしてカウントされるメモリは、スレッドスタックやプログラムコードなども含まれるからです。例えば、SQL Serverのスレッドは必要に応じて作成されますし、Large Pageモデルでない限りSQL Serverは必要に応じて徐々にメモリを確保します。つまり、右肩上がりに増えていきます。

ぼーっとみているだけでも結構勉強になります。(クリックして拡大)
というわけで、SQL Serverがメモリリークしているかどうかは、どれくらいの割合でメモリが増えているのか?とか、OSはどのバージョンを使用しているのか?とか、これだけではないですけど、いろいろな情報を総合的に考えてメモリリークしていそうだな、という結論に至ります。
少し話がずれましたが、担当者からのヘルプメールには、お客様はWindows Server 2008 R2を使用していて、private bytesが数か月にわたって30GBにも膨れ上がっていることが記載されており、「こりゃリークしとるな。」と思える状況だということがわかりました。
この記事は参考になりましたか?
- マイクロソフト古賀啓一郎の「今月のケースファイル」連載記事一覧
-
- 「今月のケースファイル」あとがきにかえて
- メモリリークの怪
- 根深かったNUMAの問題 Part 2
- この記事の著者
-
古賀 啓一郎(コガ ケイイチロウ)
日本マイクロソフト株式会社勤務。きままなエンジニア。
謎があると解決せずにはいられない性格。
週末は家事に従事。※プロフィールは、執筆時点、または直近の記事の寄稿時点での内容です
この記事は参考になりましたか?
この記事をシェア