Oracleのパフォーマンスの問題
非常に強力なOracle11Gマシンを使用しています。冗長ストレージなどがあります。それは私が言われたことからの獣です。
このDBは、私が最初に小屋としてやってきたときに20人が使用していたツール用に入手したばかりで、現在は150人以上になっています。私はそれに取り組んでいる唯一の人です:(
現在、データセンター全体にPerlスクリプトを配布するシステムがあり、本質的に一種の「グリッド」コンピューティング能力を提供しています。
Perlスクリプトは一種のシミュレーションを実行し、結果をデータベースに報告します。彼らは選択/挿入します。スクリプトごとの負荷はそれほど高くありませんが、20〜50のシステムで同時に発生する可能性があります。
次に、複数のデータセンターとユーザーがすべてこの同じアプローチで同じデータベースにアクセスします。
これに関する私たちの主な問題は、データベースが接続で過負荷になり、一部を削除しなければならないことです。 500以上の接続がある場合があります。これらは古いPerlスクリプトであり、これをうまく処理しません。本質的にそれらは失敗し、結果は失われます。これらはあまり書かれておらず、見るのも頭痛の種なので、私はむしろこれらの多くを書き直す必要を避けたいと思います。
データベース自体は過負荷ではなく、接続のオーバーヘッドが高すぎるだけです。接続を開き、簡単なクエリを実行してから、接続を削除します。非常に短い接続ですが、それらの多く。データベースチームは基本的に、接続数を減らす必要があると言っています。そうしないと、接続数を無視してしまいます。
これはファーム全体に分散しているため、永続的な接続を実装することはできません。私はこれをウェブサーバーで行います。しかし、それは固定システム上にあります。他のものは、配布ツールによって開閉されるPerlスクリプトであり、したがって常に実行されていません。
この問題を解決するための最善のアプローチは何でしょうか？スクリプト自体は、接続が開かれるのを待つことができます。彼らはすぐに行動する必要はありません。ある種のキューイングシステム？
「SQLリレー」と呼ばれるツールのインスタンスをいくつか設定するように提案されました。多分各データセンターに1つ。このツールの信頼性はどれくらいですか？このアプローチはどれくらい良いですか？それは私たちが必要とするもののために働くでしょうか？
データセンターごとに1つ作成し、それを介してメインデータベースにリクエストを中継し、開いている永続的な接続のパイプラインを維持することができますか？これは意味がありますか？
他に何か提案はありますか？何か案は？どんな助けでも大歓迎です。
悲しいことに、私は非常に大きな会社で働いている生協の学生であり、どういうわけかこれらすべてが私の肩にかかっています（文字通り助けを求める人は誰もいません;そのハードウェア会社、誰もがハードウェアエンジニアであり、データベースチームは役に立たないとインドで）そして私は最善のアプローチが何であるかとしてかなり迷っていますか？
私は非常に過労であり、この問題は進行中の進行を妨げており、基本的にできるだけ早く解決する必要があります。できれば、システム全体を書き直したり、ハードウェアを購入したり（発生しない）、自分の足を撃ったりせずに。
助けて笑！
「接続を開き、簡単なクエリを実行してから接続を切断します。接続は非常に短いですが、多くの場合です。」
共有サーバー接続を試してみます。 UNIXボックスで実行されているOracleは、セッションによって要求された「作業」を実行するためにUNIXプロセスを必要とします。従来、専用接続では、セッションが接続されると新しいUNIXプロセスをフォークし、セッションが切断されるとプロセスを強制終了します。
共有サーバーでは、DBAが接続の最小数と最大数（たとえば100と250）を定義します。起動時に、データベースは100のプロセスをフォークし、接続を待機します。 150のリクエストを受け取ると、必要な追加の50のプロセスが起動します。 300のリクエストを受け取った場合、250（最大）プロセスの1つが使用可能になるまで、そのうちの50がハングします。
重要なのは、プロセスがセッションの存続期間中は特定のセッションに関連付けられているのではなく、特定の呼び出し（たとえば、個々の挿入または更新）に対してのみ関連付けられていることです。これは、メモリ使用量にいくらかの影響を及ぼします。呼び出し間で保持されるものはすべて、プロセスメモリ（PGA）ではなく共有メモリ（SGA）にある必要があります。ただし、11g未満では、データベースはSGAとPGAの間でメモリを移動できるため、以前ほど大きな問題にはなりません。
続きを読む ここ
Oracleへの接続/切断は非常にコストがかかり、リソースの使用状況は通常のOracle統計ビューでは追跡されません。 v $ system_timeモデルでは、接続時間の下である程度それを見ることができますが、これが4倍ずれている場合もあります。野球場の図を完全に理解するために、1秒間に2、3の接続があると、完全なコアを100％で簡単に燃やすことができます。
書き込み可能なCPUがある場合は、レイテンシーを導入することを除いて、通常は問題ありません。解決策は、セッションプーリングを使用することです。つまり、データベースへの接続のセットを作成し、これらの接続を使用するユーザーを管理するコードのレイヤーを用意します。
オラクルのマルチスレッドサーバーは、オラクルのハックソリューションですが、名前とマーケティングから期待されるものよりも少ないものを提供します。
接続数を増やした場合、システムの負荷テストを行いましたか？これをテストするための別の環境がある場合、それは良いことです。
短期的には、スクリプトがいつ実行されるかを制御できる場合は、スクリプトを管理できる可能性があるため、いつでも接続をペグする必要はありません。代わりに、時間をかけてドラッグできる場合があります。スクリプトは接続を待つことができるとあなたは言います、私はそれが始めるのに最適な場所のようだと思います。
実行に最も時間がかかるクエリを見つけることで、パフォーマンスの向上を見つけることも可能だと思います。インデックスが作成されていない可能性のあるテーブルにインデックスを追加することで、改善点を見つけることができる場合があります。
それを理解するには、いくつかのデータが必要です。 Oracle Enterprise Managerを利用できますか？それはしばしばあなたが何をする必要があるかを正確に教えてくれます。それがないと、スクリプトが受け取るエラーメッセージと、アラートログに同時に表示されるすべてのものを含める必要があります。 Oracleの世界では500接続はそれほど多くありませんが、増やす必要のある構成パラメーターがあります。