メモリリークの怪

EnterpriseZine / 2014年10月31日 10時59分

 社内のメーリングリストに「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は必要に応じて徐々にメモリを確保します。つまり、右肩上がりに増えていきます。
SysinternalsのVMMAPというツールでは、仮想アドレス空間の内訳を見ることできます。
ぼーっとみているだけでも結構勉強になります。(クリックして拡大)

  • 前のページ
    • 1
    • 2
  • 次のページ
EnterpriseZine

この記事に関連するニュース

トピックスRSS

ランキング