DB高速化道場DB管理者のための、ハードウエア能力最大化テクニック技術が生み出す魔法!最新ハードウェアとチューニングで激速データベースハードウェアからデータベースまで、なんでもチューニングしないと気がすまない富士通のマジシャンが、極秘テクニックを伝授!データベースを激速化する最新ハードウェア技術と活用方法を、適用事例も交えて熱く語ります。)(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がいて、CPUをいっぱい使い切っているかのように見えるのに、CPU負荷が上がらないと言う例があります。CPUは、DBソフトがCPUに処理をお願いしている時間を示しているだけで、CPU性能を使い切っているとは言ってません。CPUの値は高いけど、CPU性能が余っていると言う時には、OSからもCPUの負荷を確認してください。この時、sarで見てはダメですよ、sarは横に並んだすべてのCPUの平均負荷を見ているんです、だからsarで見ると、CPUがあまっているね、としか見えないんです。「CPU余ってんのになんで速くならないんだ」って時は、mpstatで確認してください。mpstatは、出力項目はsarと似ていますが、コアごとのCPU負荷が確認できます。すると、特定のコアがこのグラフみたいに、100%に張り付いてるのがわかる。あそこでつまってるアレは何なんだ、ってことなんですよ。これを解決してやらないと速くはならない。バッチ処理でCPUが使い切れない理由バッチ処理でCPUが使い切れない理由は、主に4つあります。Editionを使っている場合、パラレルクエリしませんから、基本的に1個のSQLに1コアのパワーで処理すると考えてください。負荷がかかるCPUも1個。複数の処理が同時に来るなら多少並列化できますけどね。Editionでは速くならないんです。Editionのライセンス形態が変わっているので、さらに難しくなります。Editionを使う人は気を付けてください。Editionを使う場合には、クロックの速いCPUを積んでください。コア数が多くてもあまり意味がない、コアが少なくてクロックが高いCPU積むしかないんです。Edition高速化のポイントです。EditionでストレージにSSDを使う、というのもアリだと思います。Editionにしてライセンスを安くした分、ストレージは少し高くてもSSDを買って速くする、というのは正しい割り切り対処の仕方だと思います。どこまでも速くなるわけではないので・・・。自分の会社の業績の伸びに対して、サーバのライフタイムで十分カバーできる、という試算はしておいてください。あと、I/Oレイテンシが遅くなっていないか、監視をしながら使ってもらうのが良いと思います。Editionを使っているのに、パラレルクエリがテーブルに正しく設定されていない、そんな悲しい人がいます。(笑)パラレル処理を正しく設定できていないんですね。Databaseのパラレルクエリのパラメータが、バージョンごとにバラバラだということ。DBのバージョンUPしました!前のパラメータ持ってきたから、前と同じになるよね!って思ってると、パラレルクエリが外れてたりするんですよ。Editionを使ってる人は、ちゃんとパラレルで動いてるか、確認した方が良いです。もったいない!バッチ処理でCPUが使い切れない理由3:テーブルの配置などで並列動作できないテーブルの配置などが原因で、どうしても並列化できない、ということもあります。これを根本解決するためには、DB全体を見直さないと対策は難しいのですが、簡単ではないですよね。そんな時は、大容量のメモリや、高速なI/Oを使って"対処"することはできます。業務で使っているDBのテーブルの配置を変えるのは結構リスキーですからね。"対処"でも良いと思います。バッチ処理でCPUが使い切れない理由4:I/Oが遅くてCPUが動けないこれはデータをすべてメモリに載せてしまうか、高速I/Oを使うか、ですね。SPECintでのサイジングは要注意!SPECintでのサイジングは、大失敗しますので注意してください。むかし、SPECintは、整数演算をシングルプロセスで測るので、バッチ処理のレスポンス性能指標になる。SPECint_rateでは、並列演算をマルチプロセスで測るので、スループット性能の指標になる。言ったことがありました。今もそう考える人もいると思います。ところが、最新のSPECint2006では、途中からSPECintのプログラムの並列化が許可されているんです。SPECintがシングル性能だと信じてたでしょ?実は今は並列性能なんですよ。Parallelという項目があります。最近測定されたものは、ここがYesになっていて、コンパイラによる自動並列化をして測定した結果になっています。シングルプロセスのバッチ処理時間が速くなる、と思ってSPECintを基準にして換算しないでください。SPECintは並列化しています。シングルプロセスの性能指標ではなくなっています。いうプログラムだけが急激に性能改善していると言う事実があります。SPECintは、12個のプログラムの処理性能なのですが、そのなかのlibquantumというプログラムは、量子計算のアプリケーションなんです。簡単に説明しますが、1世代前のプロセッサと、最新のプロセッサで比較した場合、SPECintの12個のプログラムのうち、量子計算をするlibquantumの性能値だけがドカーンと良くなってるんです。このlibquantum、DB性能には、ほとんど関係のない値です。この数字が入ることでSPECintの性能値が上がっているんですね。DBで量子計算はしないので、SPECintの数値で期待したようには、性能が上がらない、なんてことが起きるんですね。サーバの移行をしようとしていたお客様で、こんなことがありました。SPECintで比較すると、現状の10倍の速度が見込める、ということで、かなり期待をされていたのですが、実際には2倍程度にしかならなかった、というお客様がいました。SPECintでは凄まじい値が出ているのに、DBの処理時間はあまり変わらない、ってことが結構あるんですね。DBサイジングは難しいですね。メモリやストレージで高速化できますが、動かしてみないと効果がわからない。それに、将来の負荷の増加/減少を考慮すると、無駄だとわかっていても、どうしても大きめのサーバを購入し、DBライセンスも余裕を持って購入するようになる・・・。宣伝になりますが・・・。アクティベーションという仕組みを使ってもらいたいです。DB稼動後でも使う分だけライセンスを追加/削減ができるんです。IAサーバだと、8コアのサーバを買ったら、DBライセンスも8コア分最初から買わないといけないですし、性能が足りなくなったらサーバを再構築しないといけませんよね。多すぎたとしても、コアを減らすことはできませんから、ライセンスはかかりっぱなしですね。M10だと、導入するときは4コアぐらいで買っておいて、稼動させてから性能足りないからあと2コア足して、性能余ったから、他のサーバにコアとDBの使用権を移設して、有効活用できます。導入前に、詳細なサイジングが要らないサーバなんです。稼動後に性能無駄にを余らせることもない。DBライセンスを最大限に有効活用できますね。メモリを増やして速くする!メモリを増やすとDBは劇的に早くなります。従来のDBは、メモリ上にDBのIndexデータを置いて、数ギガ程度の領域を使っていたかと思います。実際のデータは主に外部ストレージのHDDなどに入っていて、メモリ上のIndexで、データがどこに入っているか探して、実データはストレージの中に、ピンポイントで探しに行くことで高速化している、と言う方法でした。データをすべて舐めるのではなく、必要なブロックだけを読みましょう、という方法ですね。そこで、このデータを格納するストレージをフラッシュやSSDにすることで高速化させると言うのが、最近の傾向です。フラッシュストレージの価格が安くなりましたからね。メモリが増やせると、どうなるか。DBのIndexが不要になります。データを直接読んでしまいます。こっちの方が格段に速い。なると、逆にメモリ上にIndexを置く方が遅くなります。DBの検索にメモリ上のIndex読んで、もう1回メモリ読んで・・・、ってメモリを2回読みに行くだけですので・・・。この時、ストレージは更新データの保管場所になります。オンラインではアクセスしません。ストレージの使い方が変わりますね。実際にメモリを増やすと、どのくらい早くなるか、実例があります。同じサーバとストレージなんですが、メモリを増やして、ネジ巻いてやりました。(笑)そしたら、メモリ上にDBを置くことができたので、258倍、速くなりました。メモリ代は1000万円ぐらいかかるんですけど、258倍にもなるなら、コア数は64コアも必要ありません。コア数は半分でも余裕です。いうことは、32コア分のライセンスコストが抑制できるんですね、約8000万円ぐらい下がるということです。7000万円分お得になって、何倍も速くもなった、という事例ですね。なんでそんなことができるのかと言うと、富士通ではUNIXサーバを自分たちで開発していますから、これからのメモリ重点のDBを考慮して、メモリチャネルをがっちりくっつけたサーバを開発しているんです。ベースのエンジンとなるプロセッサが、スパコンと同じSPARC64アーキテクチャなんです。スパコンはメモリをたくさん載せて、メモリ上ですべてのデータ処理を行いますから、汎用のIAサーバに比べて格段にデータ処理が速いです。M10の方が1.5倍ぐらい高いんです。DBサーバに最適なことがわかりますね。M10本体は高額なのか、というと、イマドキそんなことはないんです。3.7GHz8コアのCPUに、メモリ512GBで約1000万円。同等スペックのIAサーバよりもお得に買えるんですね。それに、UNIXサーバはメモリを沢山積んだ時に心配なメモリ故障にも強く、メモリ故障でDBの性能が落ちません。エラーになったメモリ領域をOSから切り離してKB単位でメモリをOSから見えないようにしてしまいます。アプリから見ると使ってる領域なんですけど、実は正常な他のメモリ領域に裏でデータを移動しちゃうんです。OSのメモリマッピングも変えちゃうんですよね。物理的に壊れているメモリ領域はアプリから2度とアクセスしないようにしちゃうんです。メモリエラーが起きた1発目だけ、気が付かないと思いますが、クッと一瞬レスポンスが下がるんです。その時にメモリの退避をして、OS側でフタをしてしまう、という処理をしています。DB動かしててメモリ大量に積むと、メモリを積んだ分だけメモリの故障発生率って高くなりますよね、当然。それは仕方のないことなんですが、メモリが増えても性能が維持できる。メモリにデータが入りきらない人。4TBあっても、うちは入りきらないよ、って人は、フラッシュカードを積む、というやり方もあります。Editionで提供されています。Editionを使ってる人には良いと思います。フラッシュメモリ領域に、データをテーブル単位でキープできるので、PCIカードの上にテーブルを置いておくことができます。この方法を使う人はテーブルの更新量を注意して見てください。ストレージに比べるとPCIカードはスループットが少ないので、スマートフラッシュキャッシュ、って言いながら、スマートになってない人をたまに見かけます。ストレージで性能改善ストレージは、データの傾向に合わせて選んだ方が良いですね。DBのブロック長(ブロックサイズ)は、DWHであれば1MB以上、OLTPは8~128KBぐらいのブロック長の性能を確認するのが良いでしょう。高いIOPSを売りにしてストレージ性能が速いと言うのは良いですが、ブロックサイズがいくつの時のIOPSなのか、気をつけてください。4KBブロックのIOPSを見て、DBのストレージ選んじゃダメですよ。4KBというのは、どちらかというとWindowsのファイルシステムとか、VDI(仮想デスクトップ)とか、そういったところに使うサイズです。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つの観点でお話しさせていただきました。Databaseというものを作りました。お客様のAWRレポートを見て、バランスの良いところはどこらへんか、コストダウンも実現しながら導入させていただいています。DWH向けやOLTP向けなどのラインナップもあります。HANAなど各プラットフォームによってバランスよくインテグレートした製品を、サーバやストレージの開発者が集まって開発しています。無償の性能アセスメントもやってます。毎日楽しくDBをチューニングさせてもらってます。当社はセキュリティ保護の観点からSSL技術を使用しております。