【セミナー全文文字起こし】 ＠IT DB高速化道場
DB管理者のための、ハードウエア能力最大化テクニック
技術が生み出す魔法！
最新ハードウェアとチューニングで激速データベース
ハードウェアからデータベースまで、なんでもチューニングしないと気がすまない富士通のマジシャンが、極秘テクニックを伝授！データベースを激速化する最新ハードウェア技術と活用方法を、適用事例も交えて熱く語ります。
志賀 真之 （シガ マサシ）
富士通株式会社
プラットフォーム技術本部
プロダクトソリューション技術統括部 部長
サーバ開発者としての経験を生かして、エンタープライズ系サーバの技術支援およびインフラコンサルティングを担当。
講演資料
技術が生み出す魔法！最新ハードウェアとチューニングで激速データベース (2.31 MB )（2015年9月）
CPUは活用できているか
バッチ処理のときは、CPU負荷100％に張り付かせろ！
「DBが遅いんです。」と言われると、私はまず「まず使ってください :-) 」と答えるんです。だいたいの場合、CPUをちゃんと使えていないんですね。
少し上の年代の方・・・そうですね、稟議書にハンコを押すような立場の人たちは、CPUのクロックは、いつも向上していて、サーバの性能も上がる、サーバを新しく置き変えれば速くなる。と思っている人が多いんですが・・・、彼らの目を覚まさせてあげてください。（笑）
今どきのCPUは、クロックは上がっていきません。コア数を横に広げて、増やして性能向上しているCPUばっかりなんです。そういったCPUが載っているサーバでは、プログラムも横に広がるようにしてあげないといけない。
「新しいサーバ買ったんだよ、でも速くならないんだよ」とボヤいている人を見かけますが、多くの場合、新しいサーバを上手に使えていないからなんですね。
うちのSEにも良く言うんですが・・・。
理想的なDBサーバにするためには、バッチ処理のときのCPU負荷を100％に張り付かせろ、と。
張り付かないようなDBサーバ作ってるとおかしくなる、と。
ハード屋からすると、せっかく作ったCPU、せっかく作ったメモリ帯域、もったいないからキッチリ全部使い切ってくれ！と思うんです。
そんなわけで、みなさんのサーバは大丈夫ですか？バッチ処理中にCPU負荷が100％になっていなければ、そのシステムは間違っています。どこかに性能ネックがある。
特定のCPUに負荷が偏っているとか、どこかのテーブルを何多重も並列でアクセスして、他のCPUが動けないとか。
それがひどくなると、DBのテーブルのロックの取り合いになって、どんどんsys（システムプロセスによるCPU使用率）の割合が上がっていくんですね。
sysが25％超えたら、悪いことをしている、という罪悪感を持ってください。（笑）
このテーブルがネックになってるってわかってるけど、今は手をつけられない・・・と、宿題として認識している人はまだ良いと思いますが、なんだか訳わかんないんだけど負荷が上がるんだよ、って人は、反省してください。（笑）
「CPUはあまってるのにDBが遅いんだよ」と相談に来る人のDB性能レポートを見ると、トップにDB CPUがいて、CPUをいっぱい使い切っているかのように見えるのに、CPU負荷が上がらないと言う例があります。なぜか。性能レポートのDB CPUは、DBソフトがCPUに処理をお願いしている時間を示しているだけで、CPU性能を使い切っているとは言ってません。
DB CPUの値は高いけど、CPU性能が余っていると言う時には、OSからもCPUの負荷を確認してください。
この時、sarで見てはダメですよ、sarは横に並んだすべてのCPUの平均負荷を見ているんです、だからsarで見ると、CPUがあまっているね、としか見えないんです。
「CPU余ってんのになんで速くならないんだ」って時は、mpstatで確認してください。
mpstatは、出力項目はsarと似ていますが、コアごとのCPU負荷が確認できます。そうすると、特定のコアがこのグラフみたいに、100%に張り付いてるのがわかる。あそこでつまってるアレは何なんだ、ってことなんですよ。これを解決してやらないと速くはならない。
バッチ処理でCPUが使い切れない理由
バッチ処理でCPUが使い切れない理由は、主に4つあります。
- バッチ処理でCPUが使い切れない理由1：並列処理できないDBを採用している
Oracle Databaseで、Standard Editionを使っている場合、パラレルクエリしませんから、基本的に1個のSQLに1コアのパワーで処理すると考えてください。当然、負荷がかかるCPUも1個。複数の処理が同時に来るなら多少並列化できますけどね。
でも、そのDBに、どれくらい並列でSQLが来るんですか？並列で来るSQLの数より多いCPUコアを積んでも、Standard Editionでは速くならないんです。
また、Standard Editionのライセンス形態が変わっているので、さらに難しくなります。Standard Editionを使う人は気を付けてください。
Standard Editionを使う場合には、クロックの速いCPUを積んでください。コア数が多くてもあまり意味がない、コアが少なくてクロックが高いCPU積むしかないんです。もちろん限界はあります。CPUのクロック上げるのと、I/Oのレスポンスを小さくしていくのがStandard Edition高速化のポイントです。
Standard EditionでストレージにSSDを使う、というのもアリだと思います。
Standard Editionにしてライセンスを安くした分、ストレージは少し高くてもSSDを買って速くする、というのは正しい割り切り対処の仕方だと思います。
ただ、どこまでも速くなるわけではないので・・・。自分の会社の業績の伸びに対して、サーバのライフタイムで十分カバーできる、という試算はしておいてください。あと、I/Oレイテンシが遅くなっていないか、監視をしながら使ってもらうのが良いと思います。
- バッチ処理でCPUが使い切れない理由2：並列処理を設定していない
Enterprise Editionを使っているのに、パラレルクエリがテーブルに正しく設定されていない、そんな悲しい人がいます。（笑）パラレル処理を正しく設定できていないんですね。
原因の1つとしては、Oracle Databaseのパラレルクエリのパラメータが、バージョンごとにバラバラだということ。
DBのバージョンUPしました！前のパラメータ持ってきたから、前と同じになるよね！って思ってると、パラレルクエリが外れてたりするんですよ。Enterprise Editionを使ってる人は、ちゃんとパラレルで動いてるか、確認した方が良いです。大変もったいない！
- バッチ処理でCPUが使い切れない理由3：テーブルの配置などで並列動作できない
テーブルの配置などが原因で、どうしても並列化できない、ということもあります。
これを根本解決するためには、DB全体を見直さないと対策は難しいのですが、簡単ではないですよね。そんな時は、大容量のメモリや、高速なI/Oを使って"対処"することはできます。業務で使っているDBのテーブルの配置を変えるのは結構リスキーですからね。まずは"対処"でも良いと思います。
- バッチ処理でCPUが使い切れない理由4：I/Oが遅くてCPUが動けない
これはデータをすべてメモリに載せてしまうか、高速I/Oを使うか、ですね。
SPECintでのサイジングは要注意！
SPECintでのサイジングは、大失敗しますので注意してください。
むかし、SPECintは、整数演算をシングルプロセスで測るので、バッチ処理のレスポンス性能指標になる。SPECint_rateでは、並列演算をマルチプロセスで測るので、スループット性能の指標になる。と言ったことがありました。今もそう考える人もいると思います。
ところが、最新のSPECint2006では、途中からSPECintのプログラムの並列化が許可されているんです。
SPECintがシングル性能だと信じてたでしょ？実は今は並列性能なんですよ。SPECintのページをよく見ると、Auto Parallelという項目があります。最近測定されたものは、ここがYesになっていて、コンパイラによる自動並列化をして測定した結果になっています。
なので、シングルプロセスのバッチ処理時間が速くなる、と思ってSPECintを基準にして換算しないでください。SPECintは並列化しています。シングルプロセスの性能指標ではなくなっています。
さらに最近はSPECintに困った特徴的な傾向があって、libquantum
というプログラムだけが急激に性能改善していると言う事実があります。SPECintは、12個のプログラムの処理性能なのですが、そのなかのlibquantumというプログラムは、量子計算のアプリケーションなんです。簡単に説明しますが、1世代前のプロセッサと、最新のプロセッサで比較した場合、SPECintの12個のプログラムのうち、量子計算をするlibquantumの性能値だけがドカーンと良くなってるんです。
このlibquantum、DB性能には、ほとんど関係のない値です。しかし、この数字が入ることでSPECintの性能値が上がっているんですね。
DBで量子計算はしないので、SPECintの数値で期待したようには、性能が上がらない、なんてことが起きるんですね。
サーバの移行をしようとしていたお客様で、こんなことがありました。
SPECintで比較すると、現状の10倍の速度が見込める、ということで、かなり期待をされていたのですが、実際には2倍程度にしかならなかった、というお客様がいました。SPECintでは凄まじい値が出ているのに、DBの処理時間はあまり変わらない、ってことが結構あるんですね。
DBサイジングは難しいですね。メモリやストレージで高速化できますが、動かしてみないと効果がわからない。それに、将来の負荷の増加/減少を考慮すると、無駄だとわかっていても、どうしても大きめのサーバを購入し、DBライセンスも余裕を持って購入するようになる・・・。困ったものです。
宣伝になりますが・・・。
サイジングが難しいと思ったら、UNIXサーバ SPARC M10のCPUコア アクティベーションという仕組みを使ってもらいたいです。DB稼動後でも使う分だけライセンスを追加/削減ができるんです。
たとえば、IAサーバだと、8コアのサーバを買ったら、DBライセンスも8コア分最初から買わないといけないですし、性能が足りなくなったらサーバを再構築しないといけませんよね。多すぎたとしても、コアを減らすことはできませんから、ライセンスはかかりっぱなしですね。
SPARC M10だと、導入するときは4コアぐらいで買っておいて、稼動させてから性能足りないからあと2コア足して、性能余ったから、他のサーバにコアとDBの使用権を移設して、有効活用できます。導入前に、詳細なサイジングが要らないサーバなんです。でも、稼動後に性能無駄にを余らせることもない。DBライセンスを最大限に有効活用できますね。
メモリを増やして速くする！
メモリを増やすとDBは劇的に早くなります。なぜでしょう。
従来のDBは、メモリ上にDBのIndexデータを置いて、数ギガ程度の領域を使っていたかと思います。実際のデータは主に外部ストレージのHDDなどに入っていて、メモリ上のIndexで、データがどこに入っているか探して、実データはストレージの中に、ピンポイントで探しに行くことで高速化している、と言う方法でした。データをすべて舐めるのではなく、必要なブロックだけを読みましょう、という方法ですね。
そこで、このデータを格納するストレージをフラッシュやSSDにすることで高速化させると言うのが、最近の傾向です。フラッシュストレージの価格が安くなりましたからね。
さて、メモリが増やせると、どうなるか。
まずDBのIndexが不要になります。データを直接読んでしまいます。こっちの方が格段に速い。こうなると、逆にメモリ上にIndexを置く方が遅くなります。
DBの検索にメモリ上のIndex読んで、もう1回メモリ読んで・・・、ってメモリを2回読みに行くだけですので・・・。
またこの時、ストレージは更新データの保管場所になります。オンラインではアクセスしません。ストレージの使い方が変わりますね。
258倍高速化しながら、コストは7000万円も抑制
実際にメモリを増やすと、どのくらい早くなるか、実例があります。
同じサーバとストレージなんですが、メモリを増やして、ネジ巻いてやりました。（笑）
そしたら、メモリ上にDBを置くことができたので、258倍、速くなりました。
メモリ代は1000万円ぐらいかかるんですけど、258倍にもなるなら、コア数は64コアも必要ありません。コア数は半分でも余裕です。ということは、32コア分のライセンスコストが抑制できるんですね、約8000万円ぐらい下がるということです。
7000万円分お得になって、何倍も速くもなった、という事例ですね。
なんでそんなことができるのかと言うと、富士通ではUNIXサーバを自分たちで開発していますから、これからのメモリ重点のDBを考慮して、メモリチャネルをがっちりくっつけたサーバを開発しているんです。
ベースのエンジンとなるプロセッサが、スパコンと同じSPARC64アーキテクチャなんです。スパコンはメモリをたくさん載せて、メモリ上ですべてのデータ処理を行いますから、汎用のIAサーバに比べて格段にデータ処理が速いです。
実際にメモリのコピー性能を計ると、IAサーバとUNIXサーバ SPARC M10、同じソケット数でもSPARC M10の方が1.5倍ぐらい高いんです。DBサーバに最適なことがわかりますね。
じゃ、UNIXであるSPARC M10本体は高額なのか、というと、イマドキそんなことはないんです。3.7GHz8コアのCPUに、メモリ512GBで約1000万円。同等スペックのIAサーバよりもお得に買えるんですね。
それに、UNIXサーバはメモリを沢山積んだ時に心配なメモリ故障にも強く、メモリ故障でDBの性能が落ちません。エラーになったメモリ領域をOSから切り離してKB単位でメモリをOSから見えないようにしてしまいます。アプリから見ると使ってる領域なんですけど、実は正常な他のメモリ領域に裏でデータを移動しちゃうんです。OSのメモリマッピングも変えちゃうんですよね。で、物理的に壊れているメモリ領域はアプリから2度とアクセスしないようにしちゃうんです。
なのでメモリエラーが起きた1発目だけ、気が付かないと思いますが、クッと一瞬レスポンスが下がるんです。その時にメモリの退避をして、OS側でフタをしてしまう、という処理をしています。
DB動かしててメモリ大量に積むと、メモリを積んだ分だけメモリの故障発生率って高くなりますよね、当然。それは仕方のないことなんですが、メモリが増えても性能が維持できる。というところが良い。
で、メモリにデータが入りきらない人。4TBあっても、うちは入りきらないよ、って人は、フラッシュカードを積む、というやり方もあります。（4TBでも足りない、って人はなかなかいないとは思いますが・・・笑）
フラッシュを積んでDBのキャッシュ領域として使うSmart Flash CacheがOracle DB のEnterprise Editionで提供されています。ちょっと高いんですが、Enterprise Editionを使ってる人には良いと思います。
フラッシュメモリ領域に、データをテーブル単位でキープできるので、PCIカードの上にテーブルを置いておくことができます。
だた、この方法を使う人はテーブルの更新量を注意して見てください。ストレージに比べるとPCIカードはスループットが少ないので、スマートフラッシュキャッシュ、って言いながら、スマートになってない人をたまに見かけます。
ストレージで性能改善
ストレージは、データの傾向に合わせて選んだ方が良いですね。
DBのブロック長（ブロックサイズ）は、DWHであれば1MB以上、OLTPは8～128KBぐらいのブロック長の性能を確認するのが良いでしょう。
高いIOPSを売りにしてストレージ性能が速いと言うのは良いですが、ブロックサイズがいくつの時のIOPSなのか、気をつけてください。
4KBブロックのIOPSを見て、DBのストレージ選んじゃダメですよ。
4KBというのは、どちらかというとWindowsのファイルシステムとか、VDI（仮想デスクトップ）とか、そういったところに使うサイズです。
Oracle DBのランダムアクセスは8KB以上なので、8～128KBぐらいのIOPS性能を見てください。
ストレージの性能改善方法
ストレージに要求される性能としては、DWHの時は、ファイバーチャネルのパスをどれだけ確保できるのか、ということも大切です。
そして、パスをたくさん付けたら、ストレージとサーバのブロックサイズの調整をちゃんとしておかないといけない。ストレージ側がロングブロック長を出せるのに、OS側のブロック長が小さいと、無駄な処理をさせることになりますので。
もうひとつ注意が必要なのは、一時流行ったサーバ・ストレージ間に入れるキャッシュ装置、これはDWHの時は裏目に出ることが多いです。
キャッシュサーバって、中がだいたいIAサーバで出来ていて、PCIカードのファイバーチャネルからデータをメモリに取り込んで、それを別のファーバーチャネルに書き出す、という動きになる。IAサーバの狭いメモリ帯域のところに、ストレージとのIOとサーバとのIOが同時に入ってくるので、そこがネックになってしまう。ロングブロック長には向かない製品が多いですね。
OLTPのI/O処理では、SSDやフラッシュストレージは効きます。
ただ、大容量メモリができるなら、大容量メモリの方が、もっと確実に速くなる。
サーバ1台にメモリを何TBも積めると、オンラインデータは、メモリが処理しまうので、ストレージはランダム多重性能重視ではなく、更新データを高レスポンスで書き込む性能が重視されるようになってくるでしょう。
ストレージ導入の失敗事例
以前、こんな事例がありました。
HDDで作ったDBのシーケンシャルリードよりも、その先にあるDBフラッシュキャッシュの方がレスポンスが遅い。なんじゃこりゃ～！ですね。
ストレージで一部分にフラッシュとか載せると、みなさん喜んで、そこばっかり使うんですね。そこにも性能限界はありますから、ちゃんとOSの上からレスポンスの状況を見ててください。
すべてフラッシュに置き換えて使ってる人はそんなに問題ないんですが、コストを気にして、ここはフラッシュ、ここはHDD、と部分的に使っている人は、ちゃんとI/Oレスポンスが低下していないことを、常に見てくださいね。
最後に
まとめです。
本日は、CPUを活用できてるか、メモリを増やして早くする、ストレージで性能を改善する、この3つの観点でお話しさせていただきました。
私のチームでは、これまで世界中で対応してきた顧客ベンチマークで有効だったチューニングをDB設定に反映させた型決めの製品、PRIMEFLEX for Oracle Databaseというものを作りました。
お客様のAWRレポートを見て、バランスの良いところはどこらへんか、コストダウンも実現しながら導入させていただいています。
DWH向けやOLTP向けなどのラインナップもあります。
富士通では、PRIMEFLEXという名前で、VM基盤や、クラウド基盤、SAP HANAなど各プラットフォームによってバランスよくインテグレートした製品を、サーバやストレージの開発者が集まって開発しています。ご活用ください。無償の性能アセスメントもやってます。
毎日楽しくDBをチューニングさせてもらってます。
一緒にチューニングしたい人は、ぜひ富士通の浜松町の検証センターに来て声をかけてください、
一緒に楽しくチューニングしましょう :-)
イベント概要
| 日時 | 2015年9月11日（金曜日） 13時～17時50分（受付 12時30分～） |
|---|---|
| 場所 | 富士ソフト アキバプラザ 5階 ホール （各線秋葉原駅 徒歩2分） |
| 主催 | アイティメディア株式会社 @IT編集部 |
| 参加費 | 無料 |
講演の様子
SPARC Serversに関する資料請求・お見積もり・ご相談
当社はセキュリティ保護の観点からSSL技術を使用しております。
受付時間 9時～17時30分
（土曜・日曜・祝日・当社指定の休業日を除く）
