パフォーマンスタグは、ソフトウェアのパフォーマンスの問題と、パフォーマンスの問題を解決および監視するためのベストプラクティスに関する投稿をグループ化します。
これは InterSystems FAQ サイトの記事です。
データベースキャッシュおよびルーチンキャッシュをモニターし、最適値を調べる方法をご紹介します。
(1) データベースキャッシュ
現状の設定値で問題ないかは、^GLOSTAT ユーティリティ のCache Efficency値(キャッシュ効率)でモニターします。
Cache Efficiency 値は大きければ大きいほど良いですが、目安として100 以上であれば、設定サイズは問題ありません。
実行例)
これは InterSystems FAQ サイトの記事です。
システムのパフォーマンスが低下した場合、OSやインターシステムズ製品の様々なツールを使用して情報収集を行い
”通常時と比較して、どこがどの程度変わっているか”
を確認することで、問題のある箇所を特定できます。
（逆に、通常時の状況が不明な場合、パフォーマンス問題点の切り分けが非常に困難となる場合もあります。）
いざ という時に備え、通常時のパフォーマンスを確認することは、大変重要な情報となります。
収集情報詳細は、以下のドキュメントをご参照ください。
ガイド内でご紹介しているサンプルは、https://github.com/Intersystems-jp/performance-sample からダウンロードいただけます。
パフォーマンス低下時の情報収集ツールについては、以下の関連FAQトピックをご参照ください。
HealthShare の理想的な Apache HTTPD Web サーバー構成に関するお問い合わせをよくいただいています。 この記事では、真っ先に推奨される HealthShare 製品の Web サーバー構成について概要を説明します。
何よりもまず第一に、Apache HTTPD バージョン 2.4.x（64ビット）を使用することをお勧めします。 2.2.x のような旧バージョンも使用できますが、HealthShare のパフォーマンスとスケーラビリティを確保するにはバージョン 2.2 はお勧めできません。
これはInterSystems FAQ サイトの記事です。
選択性（または Selectivity）の数値とは、カラムに対するユニークデータの割合を示す数値です。
例） Person テーブルの個別値である PID カラム、住所のうち都道府県名が入る Pref カラム
Pref カラムの選択性 = 約 2%
PID カラム（ユニーク属性のカラム）の選択性 = 1
InterSystems製品のクエリオプティマイザは、クエリ実行経路（プラン）とインデックスの選択を決定するため、エクステントサイズ（テーブル内のレコード数）と選択性の数値を使用します。
詳細は下記ドキュメントページをご参照ください。
なお、選択性の数値は、テーブル単位に計算するまで設定されていません。
計算方法については関連トピックをご参照ください。
【関連情報】（コミュニティ／FAQトピックをリンクしています）
優れた執筆者は、題名で読者を引き込み、答えを記事のどこかに隠すべきだと考えられています。 だとすると、私は出来の悪い執筆者ということになってしまいます。私の自尊心は見知らぬインターネットユーザーの皆さんのご意見にかかっていますので、お手柔らかにお願いします。
これまでさまざまなストレージ技術とそのパフォーマンス特性の例を紹介してきましたが、今回は新しい HPE Cloudline 3150 Gen10（AMD プロセッサベースのシングルソケットサーバーで 3.2TB の Samsung PM1725a NVMe ドライブを 2 台搭載）など、内部コモディティベースのサーバーストレージの活用が増加傾向にあることを確認しました。
SQL パフォーマンスリソース
SQL のパフォーマンスについて語るとき、最も重要なトピックとして取り上げられるのが「Indices」、「TuneTable」、「Show Plan」の 3 つです。 添付の PDF にはこれらのトピックに関する過去のプレゼン資料が含まれていますので、それぞれの基礎を一度に確認していただけます。 当社のドキュメンテーションでは、これらのトピックの詳細に加え、SQL パフォーマンスの他のトピックについてもカバーしておりますので、下のリンクからお読みください。 eラーニングをご利用いただくと、これらのトピックをもっと深く理解していただけます。 また、開発者コミュニティによる記事の中にも SQL パフォーマンスについて書かれたものが複数ありますので、関連するリンクを下に記載しております。
下に記載する情報には同じ内容が多く含まれています。 SQL パフォーマンスにおける最も重要な要素を以下に紹介します。
これはInterSystems FAQ サイトの記事です。
コンソールログ(message.log/cconsole.log)に、以下のようなログが出力される場合があります。
このメッセージは、コントロールプロセスが出力しています。
このプロセスは、ライトデーモン(WriteDaemon)等の主要なシステムプロセスを監視しています。
この監視にて、ディスクI/O 負荷が上がったことなどにより、ライトデーモンの書き込み処理が一定期間(xxx秒間)進んでいない場合、データベースキャッシュ上にダーティなバッファが増えるのを抑制する為に、ユーザプロセスのデータベースへの書き込みアクセスをサスペンドします。
このメッセージ出力後、ライトデーモンの活動が復帰するまでユーザプロセスの書き込みアクセスは待ち状態になります(ハング状態になります)。
Caché 2017以降のSQLエンジンには新しい統計一式が含まれています。 これらの統計は、クエリの実行回数とその実行所要時間を記録します。
これは、多くのSQLステートメントを含むアプリケーションのパフォーマンスを監視する人や最適化を試みる人にとっては宝物のような機能ですが、一部の人々が望むほどデータにアクセスするのは簡単ではありません。
この記事と関連するサンプルコードでは、このような情報の使用方法と、日次統計の概要を定期的に抽出してアプリケーションのSQLパフォーマンス履歴記録を保持する方法について説明します。
※詳細については、下記ドキュメントページもご参考になさってください。
https://docs.intersystems.com/iris20201/csp/docbook/DocBook.UI.Page.cls?KEY=GSQLOPT_sqlstmts
記録内容
SQLステートメントが実行されるたびに、所要時間が記録されます。 この処理は非常に軽量であり、オフにすることはできません。 コストを最小限に抑えるため、統計はメモリに保持されてから定期的にディスクに書き込まれます。 このデータには当日にクエリが実行された回数と、その平均所要時間と合計所要時間が含まれます。
データはすぐにはディスクに書き込まれません。
皆さん、こんにちは。
InterSystems System Alerting and Monitoring (SAM)をご存知でしょうか。InterSystems IRIS 2020.1以降に対応し、IRISやそのアプリケーションの監視を行うソリューションです。といってもシステム監視を行うPrometheus、アラートを管理するAlertManager、ダッシュボードとしてグラフ等を表示させるGrafanaなどを組み合わせたものですが、IRISの利用者に合わせて設定しやすくなっています。
なお、これらのコンポーネントはDockerコンテナを使用しますので、Docker(19.3.098以降)ならびにDocker compose(1.25以降)をインストールいただく必要があります。
IRISの監視APIについてはこちらをご覧ください。
アプリケーション自体はDockerコンテナにて提供されますので、DockerComposeのファイルやシェルスクリプトを以下のGitHubリポジトリからダウンロードします。
https://github.com/intersystems-community/sam
以下のgzipファイルをダウンロードし、展開します。
sam-1.0.0.XXX-unix.tar.gz
$ tar zpxvf sam-1.0.0.本稿では、InterSystems IRISを使用してSQLベースのベンチマークを行う際に、実施していただきたい項目をご紹介します。 Linuxを念頭においていますが、Windowsでも考慮すべき点は同じです。
パフォーマンスに直結する、データベースバッファサイズの自動設定はデフォルトで有効になっています。自動設定は、実メモリの搭載量にかかわらず、データベースバッファを最大で1GBしか確保しません。
更新: 2020年11月20日 バージョン2020.3から、確保を試みるデータベースバッファが実メモリの25%に変更されました。
搭載実メモリ64GB未満の場合は実メモリの50%程度、搭載実メモリ64GB以上の場合は実メモリの70%を目途に、明示的に設定を行ってください。
設定するにはiris停止状態で、iris.cpfファイル(IRISインストール先\mgr\iris.cpf)を変更します。下記はブロックサイズ8KB用(既定値です)のデータベースバッファサイズの自動構成を4096(MB)に変更する例です。
修正前
[config]
globals=0,0,0,0,0,0
修正後
[config]
globals=0,0,4096,0,0,0
詳細はこちらです。
また、Linuxの場合、ヒュージ・ページ有効化の設定を行ってください。
ここ数年の間、ハイパーコンバージドインフラストラクチャ（HCI）ソリューションが勢いを増しており、導入件数が急速に増加しています。 IT部門の意思決定者は、VMware上ですでに仮想化されているアプリケーションなどに対し、新規導入やハードウェアの更新を検討する際にHCIを考慮に入れています。 HCIを選択する理由は、単一ベンダーと取引できること、すべてのハードウェアおよびソフトウェアコンポーネント間の相互運用性が検証済みであること、IO面を中心とした高いパフォーマンス、単純にホストを追加するだけで拡張できること、導入や管理の手順が単純であることが挙げられます。
この記事はHCIソリューションの一般的な機能を取り上げ、HCIを初めて使用する読者に紹介するために執筆しました。 その後はデータベースアプリケーションの具体的な例を使用し、InterSystems データプラットフォーム上に構築されたアプリケーションを配置する際の、キャパシティプランニングとパフォーマンスに関する構成の選択肢と推奨事項を確認します。 HCIソリューションはパフォーマンスを向上させるためにフラッシュストレージを利用しているため、選択されたフラッシュストレージオプションの特性と使用例に関するセクションも含めています。
前回の記事では、pButtonsを使って履歴パフォーマンスメトリックを収集する方法を説明しました。 すべてのデータプラットフォームインスタンス（Ensemble、Cachéなど）にはpButtonsがインストールされていることがわかっているため、私はpButtonsを使用する傾向にありますが、 Cachéパフォーマンスメトリックをリアルタイムで収集、処理、表示する方法はほかにもあり、単純な監視や、それよりもさらに重要な、より高度な運用分析とキャパシティプランニングに使用することができます。 データ収集の最も一般的な方法の1つは、SNMP（簡易ネットワーク管理プロトコル）を使用することです。
SNMPは、Cachéが管理・監視情報をさまざまな管理ツールに提供するための標準的な方法です。 Cachéのオンラインドキュメンテーションには、CachéとSNMP間のインターフェースに関する詳細が説明されています。 SNMPはCachéと「単純に連携」するはずですが、構成にはいくつかの技と罠があります。 私自身、はじめに何度も過ちを繰り返し、InterSystemsの同僚から助けを得ながらCachéをオペレーティングシステムのSNMPマスターエージェントにやっと接続できた経験から、皆さんが同じような困難を避けられるようにこの記事を書くことにしました。
この記事では、InterSystemsデータプラットフォームで実行するデータベースアプリケーションにおけるグローバルバッファ、ルーチンバッファ、gmheap、locksizeなどの共有メモリ要件のサイジングアプローチを説明し、サーバー構成時およびCachéアプリケーションの仮想化時に検討すべきパフォーマンスのヒントをいくつか紹介します。 これまでと同じように、Cachéについて話すときは、すべてのデータプラットフォーム（Ensemble、HealthShare、iKnow、Caché）を指しています。
最初にCachéを使い始めたころ、ほとんどの顧客オペレーティングシステムは32ビットで、Cachéアプリケーションのメモリは少なく、高価なものでした。 一般的に展開されていたIntelサーバーにはコアが数個しかなく、スケールアップするには、大型のサーバーを使用するか、ECPを使って水平方向にスケールアウトするしかありませんでした。 今では、基本製品グレードのサーバーでさえも、マルチプロセッサ、数10個のコア、TBにまで増設できる可能性も備わった128GBまたは256GBの最低メモリが搭載されています。
今週は、ハードウェアの主な”食品群” (^_^) の1つであるCPUに注目します。お客様から、次のようなシナリオについてのアドバイスを求められました。お客様の本番サーバーはサポート終了に近づいており、ハードウェアを交換する時期が来ています。 また、仮想化によってサーバーを一元的に管理できるようにし、ベアメタルか仮想化によりキャパシティを適正化したいとも考えています。 今日はCPUに焦点を当てますが、後日の記事では、メモリやIOといったほかの主要食品群を適正化するアプローチについて説明したいと思います。
では、質問を整理しましょう。
2017年6月追記:
VMware CPUに関する考慮事項と計画の詳細、および一般的な質問と問題の詳細については、「大規模データベースの仮想化 - VMware CPUのキャパシティ計画」の記事も参照してください。
前回の投稿では、pButtonsを使用してパフォーマンスメトリックを24時間収集する処理をスケジュールしました。 この投稿では、収集対象の主なメトリックのいくつかと、それらの土台となるシステムハードウェアがどのように関連しているかを見ていきます。 また、Caché（または任意のInterSystemsデータプラットフォーム）メトリックとシステムメトリックの関係についても調べます。 さらに、これらのメトリックを使用してシステムの毎日の健全性を把握し、パフォーマンスの問題を診断する方法もご紹介します。
2016年10月に編集...
pButtonsデータを .csv ファイルに抽出するスクリプトの例はこちらで確認できます。
2018年3月に編集...
画像が消えていましたが、元に戻しました。
この連載を読み進めていくと、パフォーマンスに影響を与えるサーバーコンポーネントを次のように分類できることが分かってきます。
- CPU
- メモリ
- ストレージIO
- ネットワークIO
これらのコンポーネントのいずれかに負荷がかかっている場合、システムのパフォーマンスとユーザーエクスペリエンスが低下する可能性があ
アプリケーションがデプロイされ、すべてが問題なく動作しています。 素晴らしいですね！ しかし、その後突然電話が鳴り止まなくなりました。アプリケーションが時々「遅くなる」というユーザーからの苦情の電話です。 これは一体どういうことなのでしょうか？ なぜ時々遅くなるのでしょうか？ このような速度低下を検出し、解決するにはどのようなツールと統計情報に注目すべきなのでしょうか？ お使いのシステムのインフラはユーザーの負荷に対応できていますか？ 本番環境を調べる前に、どのようなインフラ設計上の問題を問うべきなのでしょうか？ 新しいハードウェアのキャパシティプランニングを、必要以上の設備投資を行うことなく自信を持って行うにはどうすればよいのでしょうか？ どうすれば電話がかかってこなくなるのでしょうか？ そもそも電話がかかってこないようにするには、どうすればよかったのでしょうか？
これは、システムパフォーマンスの監視、確認、トラブルシューティングに使用できるツールとメトリック、およびパフォーマンスに影響を与えるシステムとアーキテクチャの設計上の考慮事項について説明する連載の最初の投稿です。
前のパート（1、2）では、ツリーとしてのグローバルを話題に取り上げました。 この記事では、それらを疎な配列と見なします。
疎な配列は、ほとんどの値が同一であると想定される配列の種類です。
疎な配列は実際には非常に大きいため、同一の要素でメモリを占有することには意味がありません。 したがって、疎な配列を整理し、重複した値の格納にメモリが浪費されないようにすることには意味があります。
疎な配列は、J、MATLABなど一部のプログラミング言語では言語の一部になっています。 他の言語では、疎な配列を使用できるようにする特別なライブラリが存在します。 C++の場合は、Eigenなどがあります。
次の理由により、グローバルは疎な配列を実装するのに適した候補であると言えます。
Set ^a(1, 2, 3)=5
Write ^a(1, 2, 3)
最初の記事については、パート1を参照してください。
順序付きツリーなどの構造には、さまざまな特殊ケースがあります。 グローバルを使用する上で実用的な価値があるものを見てみましょう。
グローバルは配列のようにも、通常の変数のようにも使用できます。 例えば、カウンターを作成する場合を考えてみましょう。
Set ^counter = 0 ; カウンターの設定
Set id=$Increment(^counter) ; アトミックなインクリメント操作
また、グローバルには値に加えて枝を持たせることができます。 一方が他方を除外することはありません。
実際、これは典型的なキー・バリューベースのデータ構造です。 また、値の代わりに値のタプルを保存すると、主キーを持つ通常のテーブルが得られます。
グローバルに基づくテーブルを実装するには、カラムの値から文字列を作成し、主キー別にそれをグローバルに保存する必要があります。 読み取りの時に文字列をカラムに分割できるようにするため、以下のいずれかを使用することができます。
次の手順で、/api/monitor サービスから利用可能なメトリックのサンプル一覧を表示することができます。
前回の投稿では、IRISのメトリックをPrometheus形式で公開するサービスの概要を説明しました。 この投稿では、コンテナにIRISプレビューリリース2019.4 をセットアップして実行し、メトリックを一覧表示する方法をお伝えします。
この投稿は、Dockerがインストールされた環境があることを前提としています。 そうでない場合は、今すぐお使いのプラットフォームにインストールしてください :)
「プレビューの配布」のダウンロード手順に従い、プレビューライセンスキーとIRISのDockerイメージをダウンロードします。 この例では、InterSystems IRIS for Health 2019.4を選択しています。
「機能紹介：Dockerコンテナ内のInterSystems製品について」の指示に従ってください。 すでにコンテナに精通している場合は、「InterSystems IRISのDockerイメージをダウンロードする」というタイトルのセクションに進んでください。
次のターミナル出力は、私がDockerイメージの読み込みに使用している手順を示しています。
私や他のテクノロジアーキテクトは、Caché IOの要件と、Cachéアプリケーションがストレージシステムを使用する方法を顧客とベンダーに説明しなければならないことがよくあります。以下の表は、一般的なCaché IOプロファイルと、トランザクションデータベースアプリケーションの要件を顧客やベンダーに説明するときに役立ちます。 オリジナルの表は、マーク・ボリンスキーが作成しました。
今後の投稿ではストレージIOについて詳しく説明する予定なので、今後の記事の参考資料として、今回これらの表も公開します。
予測可能なディスクIOパフォーマンスを提供し、高可用性機能をサポートし、アプリケーションにストレージの冗長性、スケーラビリティ、および信頼性を提供するには、ストレージアレイなど、ストレージを適切に設定することが不可欠です。
選択したストレージアレイテクノロジーによっては、物理層のディスクストレージがプールまたはディスクグループに分離される場合があります。 可能であれば、可用性とパフォーマンスのために、予想されるIOプロファイルに基づいてストレージをパーティション化する必要があります。 たとえば、データとジャーナル（トランザクションログ）は別々の物理ディスクグループに存在する必要があります。
データを格納するための魔法の剣であるグローバルは、かなり前から存在しています。しかしながら、これを効率的に使いこなせる人や、この素晴らしい道具の全貌を知る人はそう多くありません。 グローバルを本当に効果を発揮できるタスクに使用すると、パフォーマンスの向上やソリューション全体の劇的な単純化といった素晴らしい結果を得ることができます（1、2）。
グローバルは、SQLテーブルとはまったく異なる特別なデータの格納・処理方法を提供します。 グローバルは1966年にM（UMPS）プログラミング言語で初めて導入され、医療データベースで使用されていました。 また、現在も同じように使用されていますが、金融取引など信頼性と高いパフォーマンスが最優先事項である他のいくつかの業界でも採用されています。
M（UMPS）は後にCaché ObjectScript（COS）に進化しました。 COSはInterSystemsによってMの上位互換として開発されました。 元の言語は現在も開発者コミュニティに受け入れられており、いくつかの実装で生き残っています。 ウェブ上では、MUMPS Googleグループ、Mumpsユーザーグループ、ISO規格といった複数の活動が見られます。
最新のグローバルベースのDBMSは、トランザクション、ジャーナリング、レプリケーション、パーティショニングをサポートしています。