NTT DATA と PostgreSQL が挑んだ総力戦

3. 3 Copyright © 2014 NTT DATA Corporation OSSが世の中一般に広まり、活用され始める。 NTT DATA 含め、NTTグループとして戦略的にOSSを活用していく体制を整え、OSS適用も活発化。認知・活用へ(199x - 2007頃) 年度主な出来事 1999 【コミュニティ】日本PostgreSQLユーザ会(JPUG)設立 2001 【PG】 PostgreSQL 7.1 (ログ先行書き込み(WAL)の実装) 2005 【PG】 PostgreSQL8.0 (Windows対応・PITR) 2006 【NTTG】 NTT OSSセンタ設立

4. 4 Copyright © 2014 NTT DATA Corporation OSSというだけで適用が進む時代が終わる。 NTT DATAでは全社展開のためモデル作成を実施。エンタープライズ分野での弱点をカバーすべく研究開発、新規ソリューション開拓も活発に。普及・継続的取り組みへ(2008 - 2013頃) 年度主な出来事 2008 【PG】 PostgreSQL 8.3(autovacuum 標準装備) 2011 【PG】 PostgreSQL 9.1(同期レプリケーション機能の採用) 2012 【コミュニティ】 PGECons 設立 2013 【NTTD】 GresCube 販売開始

6. 6 Copyright © 2014 NTT DATA Corporation メインサイト今回ご紹介する事例認証データシステム基幹部分災対サイト業務・集計データ小売店モバイル POS POS PC 社内外の他システムモバイル向け Web/AP 社内向け Web/AP 集配信認証盤オンライン APサーバオンライン帳票サーババッチ APサーバモバイル向け Web/認証基盤オンライン APサバオンライン帳票ーババッチ・取引 APサバ業務・集計データ非同期レプリケーション PostgreSQL 販売店舗情報など売上請求情報など PostgreSQL 世界有数のエネルギー元売会社の情報系システム販売情報等をもとに、集計等をほぼリアルタイムで行う

7. 7 Copyright © 2014 NTT DATA Corporation 特徴(2) OSSメイン & 拡張機能をフル活用 PostgreSQLの拡張機能 pg_statsinfo 性能情報監視用 pg_stat_statement 実行SQLの性能情報監視用 auto_explain スロークエリの実行計画捕捉用 pg_hint_plan 実行計画制御用 pg_dbms_stats 統計情報固定化用 pg_bigm 全文検索(2-gram)用 pg_reorg オンラインテーブル再編成メンテ用 pgfincore (試験時のみ) キャッシュヒット効率向上用ミドルウェア OS RHEL 6.2 DBMS PostgreSQL9.2 AP Tomcat およそ利用可能な拡張モジュールは全て取り入れた

11. 11 Copyright © 2014 NTT DATA Corporation 万が一に備えてそこで、外部モジュール！地味に、便利なコマンド！ pg_reorg オンラインVACUUM FULL オンラインCLUSTER 自作ツール CREATE INDEX CONCURRENTLY ALTER INDEX でスワップ！ VACUUMができなかったら？インデックスが荒れてしまったら？排他ロック要らず！

14. 14 Copyright © 2014 NTT DATA Corporation 災害対策（Disaster Recovery)を検討せよ災害時にも止められない！ →災害の被害を受けてもサービスを継続するために、遠隔地にメインサイトのコピー(災対サイトの構築)を作る！ 東日本(メインサイト) から西日本(災対サイト) DR対象は(ほぼ)システム全体課題はPostgreSQLのメイン->災対へのデータ同期・・・ DBデータ西日本 DBデータ東日本

16. 16 Copyright © 2014 NTT DATA Corporation ・・・でも本当に大丈夫か？SR データアーカイブログ WAL 圧縮して高速に転送解凍・リカバリマスタスタンバイ最大負荷量から必要な帯域をサイジング初期同期はNW経由・・でもOKそうだ・・もしレプリケーションが追いつかなくなったら？データ WAL PostgreSQLが自動でアーカイブログからの復旧に切り替え！想定時間内にキャッチアップ！

20. 20 Copyright © 2014 NTT DATA Corporation 10Mにおよぶ AP シビアな状況が我々を悩ませた… 数万の SQL 1000人規模の開発体制タイトなスケジュールポスグレ経験者少な目 SQL性能どう守る？迅速な SQL チューン?  複雑すぎるSQLを書いてしまう → SQLのメンテナンス性、可読性低下  SQLは書いたけど、多くのSQLで性能問題が発生 → 期間内にすべての性能問題を解決できない性能要件を満たさず、トラブルを引き起こすSQL(= 問題SQL)を撲滅するために、我々が用意したものは…？

22. 22 Copyright © 2014 NTT DATA Corporation 1つ目 - ＳＱＬガイドライン PJが持っていたSQLガイドラインで、SQLのメンテナンス性を担保 PostgreSQLのノウハウで、“PostgreSQL向けのSQL”に SQLガイドライン •1行当たり最大○○文字 •コメントには/*…*/を使用する •ORDER BYには列名を記載する： SQLガイドライン PostgreSQLのノウハウ •NULLと文字列を連結すると空文字になる •異なるデータ型で比較しないこと：

23. 23 Copyright © 2014 NTT DATA Corporation チェック項目結果テーブルのJOIN数チェック OK 直積使用チェック OK 同じテーブルを複数回見ているかチェック OK 中間一致使用チェック中間一致はフルスキャンになり性能問題を起こす可能性があります。 pg_bigmインデックスを利用しましょう：： 2つ目 - ＳＱＬチェックツールとはいえ、ヒューマンエラーはある(´Д｀lli) “ＳＱＬガイドラインに従ったＳＱＬ“になっているか20以上の項目を自動で判別 NGの場合は、チェック観点を表示 ■SQL静的チェック結果（イメージ図）

24. 24 Copyright © 2014 NTT DATA Corporation 3つ目 - 実行計画チェックツールサービス開始後、SQLの性能問題が起きないために、 “実行計画”をチェック <実行計画> Sort ->Nested Loop (cost = … -> Index Scan (cost = … -> Seq Scan (cost = … ： 見積もりコストは高くなりすぎていない？ インデックス使われてる？ただし！サービス開始後に生成される“リアル”な実行計画が必要！

25. 25 Copyright © 2014 NTT DATA Corporation 4つ目 - HINT句でアジリティチューニング HINT句を使い直接実行計画を制御することで、アジリティなSQLチューニングを可能に ○ HINT句を使用するメリット SQLを書き換えるよりも改修時間が短い！ •実行計画を確認して、使用するインデックスやスキャン方法を変えるだけ SQLの実行結果の内容は変わらない！ •HINTを付与するだけなので、SQLのリテスト不要 /*+ IndexScan(hoge) */ SELECT * FROM hoge WHERE id = 9999;

27. 27 Copyright © 2014 NTT DATA Corporation リアルな実行計画？PGを騙す？実行計画チェックの実現、大量SQLの性能担保にあった 2つの課題 ■ 2つの課題 1.ダミーの統計情報を生成しPostgreSQLに設定する仕組みがない → PostgreSQLを騙す仕組み 2.PostgreSQLを騙すことができても一時的な効果でしかない → PostgreSQLを騙し続ける仕組み

28. 28 Copyright © 2014 NTT DATA Corporation 「統計情報カスタマイズ機能」作りましたユーザがテーブルに“任意の統計情報”を設定することが可能 BIG!! 大規模テーブルをスキャンする実行計画実行計画作成 <統計情報> •20億件 •500GB ：空 DBA 統計情報設定統計情報カスタマイズ設定する統計情報は「業務Tmへのヒアリングで見積もる」 + 「一部は機械的に生成」

29. 29 Copyright © 2014 NTT DATA Corporation プランナ pg_dbms_stats PostgreSQL 本来の統計情報実行計画 “独自に設定された” “固定化された” 統計情報生成 pg_dbms_stats × 統計情報カスタマイズ機能統計情報カスタマイズ機能はpg_dbms_statsの追加機能として開発しました DBA ・テーブル行数・テーブルサイズ・列幅・列の固有値・列のヒストグラム、MCV など ■pg_dbms_stats × 統計情報カスタマイズ機能直接設定！

31. 31 Copyright © 2014 NTT DATA Corporation リソース使用量に異常発生！ PostgreSQLのサーバログ確認 APサーバのログ確認 DBサーバのカーネルログ確認他のリソース使用状況確認 OK OK OK OK 試験中にDBサーバに異変が(´Д｀lli) CPUのsysが高騰している(常に80%以上) →PostgreSQLに問題はなさそうなので、 Linuxの性能解析ツール(perf)で調べてみることに

32. 32 Copyright © 2014 NTT DATA Corporation カーネルサイドからのアプローチ perf topの状況を見ると、PostgreSQL以外に原因がありそう ■perf top結果(一部抜粋) 320878.00 29.0% SpinPause /usr/java/…/libjvm.so 187781.00 17.0% _spin_lock_irq [kernel.kallsyms] 143784.00 13.0% read_hpet [kernel.kallsyms] 109362.00 9.9% ParallelTaskTerminator /usr/java/…/libjvm.so 35295.00 3.2% native_write_msr_safe [kernel.kallsyms] 33563.00 3.0% intel_idle 25783.00 2.3% _spin_lock 19725.00 1.8% _spin_lock_irqsave 11848.00 1.1% find_busiest_group 2835.00 0.3% compaction_alloc [kernel.kallsyms] 2782.00 0.3% unmap_vmas [kernel.kallsyms] 2603.00 0.2% rb_next •調べてみるとRHEL6.2にあったTransparent Huge Page(THP) のバグを踏んでいたよう •THPを無効にすることによりCPUのsys高騰が解消したもしかして、 HugePage関連？ Linuxカーネル技術者

33. 33 Copyright © 2014 NTT DATA Corporation 再び異常発生！また！？試験中にDBサーバのレスポンスが急激に悪化ヽ(ヽ゜ロ゜) vmstatを見るとswapが大量発生 vmstatの結果(一部抜粋) procs -------------memory------------ --swap-- ---io--- r b swpd free buff cache si so bi 00:13:39 22 6 1446440 23304532 108560 66972348 504 1374 15280 … 00:13:44 11 6 1451608 23112444 108648 67165456 786 1281 19406 … 00:13:49 10 6 1457416 23168188 108800 67330992 125 1184 18972 … 00:13:54 14 6 1466048 22865104 108892 67517832 660 1794 22452 … 00:13:59 28 5 1471792 22766112 108980 67579072 130 1203 14629 … 00:14:04 11 3 1475952 22519940 109068 67685576 46 842 10079 … 00:14:09 27 1 1482372 22400092 109180 67703616 182 1323 6529 …

35. 35 Copyright © 2014 NTT DATA Corporation え！？あれ！？メモリが空いているにも関わらず、swapが起きている！これには別の原因がありそう！ vmstatの結果(一部抜粋) procs -------------memory------------ --swap-- ---io--- r b swpd free buff cache si so bi 00:13:39 22 6 1446440 23304532 108560 66972348 504 1374 15280 … 00:13:44 11 6 1451608 23112444 108648 67165456 786 1281 19406 … 00:13:49 10 6 1457416 23168188 108800 67330992 125 1184 18972 … 00:13:54 14 6 1466048 22865104 108892 67517832 660 1794 22452 … 00:13:59 28 5 1471792 22766112 108980 67579072 130 1203 14629 … 00:14:04 11 3 1475952 22519940 109068 67685576 46 842 10079 … 00:14:09 27 1 1482372 22400092 109180 67703616 182 1323 6529 … 最近コミュニティで、似たような事象が報告されていたような。 PostgreSQL技術者

36. 36 Copyright © 2014 NTT DATA Corporation リモートのメモリが使えない！空いているのに！メモリ (32GB) メモリ (32GB) メモリ (32GB) メモリ (32GB) メモリを確保する際、設定状況によってはリモートのメモリを使うことができず、ローカルメモリをスワップしてしまう CPU CPU CPU CPU メモリの余りがない… メモリインタリーブを有効にすることで解決！ローカルメモリリモートメモリリモートメモリリモートメモリ

40. 40 Copyright © 2014 NTT DATA Corporation リスクに立ち向かうそこはOSS ソースコードとコアダンプがある。開発元と共に原因を特定。パッチを書いて、根本対処 Program received signal SIGSEGV, Segmentation fault. pg_detoast_datum_packed (datum=0x2) at fmgr.c:2273 2273 if (VARATT_IS_COMPRESSED(datum) || VARATT_IS_EXTERNAL(datum)) (gdb) bt #0 pg_detoast_datum_packed (datum=0x2) at fmgr.c:2273 #1 0x00000000006d5c24 in bpchargt (fcinfo=0x7fffdc6b4f80) at varchar.c:801 #2 0x000000000072127f in FunctionCall2Coll (flinfo=<value optimized out>, collation=<value optimized out>, arg1=<value optimized out>, arg2=<value optimized out>) at fmgr.c:1327 #3 0x00000000006c972f in ineq_histogram_selectivity (root=0xfca988, vardata=0x7fffdc6b54a0, opproc=0x7fffdc6b5410, isgt=1 '¥001', constval=16558024, consttype=1042) at selfuncs.c:836 ・・・ (gdb) p *(Form_pg_statistic) ((char *) vardata->statsTuple->t_data + vardata->statsTuple- >t_data->t_hoff) $2 = {starelid = 900400380, staattnum = 12, stainherit = 0 '¥000', stanullfrac = 0, stawidth = 4, stadistinct = 2, stakind1 = 1, stakind2 = 3, stakind3 = 0, stakind4 = 0, stakind5 = 0, staop1 = 1752, staop2 = 1754, staop3 = 0, staop4 = 0, staop5 = 0} ・・・ hash = hash_create("dbms_stats relation statistics cache", MAX_REL_CACHE, &ctl, HASH_ELEM | HASH_CONTEXT); ・・

43. 43 Copyright © 2014 NTT DATA Corporation 限界まで使い倒した後に見えたもの「ポテンシャルを引き出すこと」 PostgreSQLの魅力の一つは豊富な拡張機能外部モジュールは最大限活用すべし「石橋を叩いて備えること」問題はどうしても発生してしまう捕捉手段と効果的な対策を持っておくことが大事「OSSであることを生かすこと」機能がなくとも、開発でカバーできる最後に求められるのは製品能力ではなく、現場能力ミッションクリティカルな環境で、強く感じた3か条

44. 44 Copyright © 2014 NTT DATA Corporation PostgreSQLとNTTデータ - この先に - パラレルクエリカラムナストア BlockRange INdex 双方向レプリケーション FDW+JOIN Pushdown パーティション機能強化監査強化権限分掌プロファイラより強固により高速により広大に進化を続ける PostgreSQL を武器にさらに高いハードルに挑んでいる

NTT DATA と PostgreSQL が挑んだ総力戦

NTT DATA OSS Professional Services

Transcript

Introducing the official SlideShare app

Stunning, full-screen experience for iPhone and Android

Text the download link to your phone

NTT DATA と PostgreSQL が挑んだ総力戦

NTT DATA OSS Professional Services

Transcript