根深かったNUMAの問題 Part 2

EnterpriseZine / 2014年10月10日 0時0分

 SQL Server 2012の時と違うのは、急激なメモリアロケーションだけで、解放処理が行われていないことです。Standby Cacheが溜まっていることから、前回と同じようにNUMAに関する問題の可能性が高いのですが、SQL Server 2012では、メモリマネージャが大きく変わっているので、これは異なる問題です。この問題を調査するには現象を再現させて、詳細を調査するしかないと思いました。

●案件の概要

 SQL Server 2012の時と違うのは、急激なメモリアロケーションだけで、解放処理が行われていないことです。Standby Cacheが溜まっていることから、前回と同じようにNUMAに関する問題の可能性が高いのですが、SQL Server 2012では、メモリマネージャが大きく変わっているので、これは異なる問題です。この問題を調査するには現象を再現させて、詳細を調査するしかないと思いました。

■バッファプール

 幸いにも、前回の問題を開発部門へ報告する時に再現環境を構築していたので、この環境を流用してSQL Server 2008でも再現を試みることにしました。数台のアプリケーションサーバーと高スペックなデータベースサーバーを用意し、お客様からアプリケーションを借りて再現環境を構築していたのです。

Standby Cacheをいっぱいにして、アプリケーションを実行するとあっさりと再現しました。SQL Serverは、暴走したかのように急激なメモリアロケーションを行います。パフォーマンスカウンターのBuffer Manager\Free pagesカウンターがぐんぐん上がっていきます。

 Standby Cacheが溜まっていない時は、アプリケーションのラッシュをかけてもSQL Serverが確保するメモリはmax server memoryに設定していた64GBには及ばず、12GB位で安定します。しかし、現象が再現すると一気にSQL Serverは64GBまで確保してしまうのです。

 しばらくデバッグして、原因が判明しました。前回と同じように、NUMAメモリのハンドリングに原因はありました。問題を説明する前に、少しSQL Server 2008のバッファプールについて、説明しておきましょう。

 SQL Server 2012以前、SQL Serverが扱うメモリの大半はバッファプールでした。バッファプールの最大サイズは、max server memoryで設定することができ、最大値に達するまでの間、バッファプールはgrowフェーズという状態にあります。Growフェーズの間、バッファプールは必要に応じて徐々にメモリ確保(grow)していきます。メモリを確保する時の条件は、バッファプールのfree pageが一定量足りていないと判断した場合です。しかし、今回の場合、free pageが大量にあるにもかかわらず、メモリ確保が必要以上に行われているわけです。

EnterpriseZine

トピックスRSS

ランキング