0

当店は、数十のクライアント インストール用にいくつかの WEB/SMS/DB ソリューションを開発しました。アプリケーションにはいくつかのリアルタイム パフォーマンス要件があり、適切に機能するには十分です。問題は、クライアント (運用サーバーの所有者) が同じサーバー/データベースをカスタマイズに使用しているため、作成およびデプロイしたアプリケーションのパフォーマンスに問題が生じていることです。

クライアントのカスタマイズの例:

  • クエリで他のデータ型にキャストされる列に多くのテキスト データ型を含む大きなテーブルを追加する
  • 主キー、インデックス、または FK 制約なし
  • スクリプトからのループでを使用する外部スクリプトを使用count(*) from table where id = xして、後で同じスクリプト内でさらにクエリを作成する方法を決定します。(プランナーが最適化できる、または単一のパスですべてを実行できる一括アクションはありません)
  • サーバー上のすべての新しいコード ファイルは、root によって作成/所有され、0777 パーミッションで作成されます。

クライアントは提案や批判をうまく受け止めません。先に進んで自分でスクリプトを移植/変更しようとすると、古いコードが戻ってきて、行った変更がすべて破壊される可能性があります! または、ユースケースに関する知識が限られているため、変更を最適化しようとして機能を壊してしまいます。

私の質問は次のとおりです。作成および展開するもの以外のクエリ/アプリケーションにリソースを制限するにはどうすればよいですか? このようなシナリオで実用的なオプションはありますか? 私たちは OSS ソリューションを持っていることを誇りに思っていましたが、それが負担になっているようです。

Linux Distos の範囲で実行されている PG 8.3 を使用します。クライアントは php を好みますが、シェル スクリプト、perl、python、および plpgsql はすべて、システム上で何らかの形で使用されています。

4

1 に答える 1

1

この問題は、最初のクライアントが最初のコンピューターへのフルアクセスを許可されてから約2分後に始まり、それ以降は解消されていません。優先順位がビジネス指向の仕事をすぐに終わらせることである誰かがいつでもそれについてだらしなくて、みんなのために物事を台無しにするでしょう。適切な設計と実装は安価なハックよりも難しいため、これがまさにその仕組みです。あなたはこの問題を解決するつもりはありません。あなたができることは、クライアントがあなたに反対するよりもあなたと一緒に仕事をしやすくする方法を見つけることだけです。あなたがそれを正しくやれば、それはしつこいというよりも優れたサービスのように見えるでしょう。

まず、データベース側です。PostgreSQLでクエリリソースを制御する方法があります。主な問題は、「nice」などのツールがCPU使用率を制御することですが、データベースがRAMに収まらない場合は、I/O使用率が原因である可能性があります。ここで問題を要約したこの開発者メッセージを参照してください。

これで、実際にクライアントが焼き尽くしているCPUである場合、その状況を改善するために2つの手法を使用できます。

  • プロセスの優先度を変更するC関数（例1、例2）をインストールし、実行するたびに最初に呼び出されることを確認します（psql構成ファイルに入れるなど、他の方法もあります）。
  • ユーザーIDによって生成されたポストマスタープロセスを探してそれらを再利用するスクリプトを作成し、cronまたはデーモンとして頻繁に実行するようにします。

問題は、実行している特定のクエリプロセスではなく、より大きな構造に対して行っている他の変更にあるようです。これに対処する唯一の方法があります。クライアントを侵入者のように扱い、コンピュータセキュリティ分野のその部分のアプローチを使用して、クライアントが問題を引き起こしたことを検出する必要があります。真剣に！サーバーにTripwireのような侵入検知システムをインストールし（より優れたツールがありますが、これは典型的な例です）、何かに触れたときに警告を発します。0777の新しいファイル？適切なIDSレポートからすぐに飛び出す必要があります。

データベース側では、データベースが変更されていることを直接検出することはできません。スキーマのpg_dumpをファイルに毎日実行する必要があります（pg_dumpall-gおよびpg_dump-s、次にそれを最後に配信したものと比較し、変更されたときに再度警告します。これをうまく管理している場合は、クライアントは「サーバー上で変更されたことに気づきました...それで何を達成しようとしているのですか？」に変わり、本当に注意を払っているように見えます。これは販売機会になり、彼らはあなたがすぐにそれを捕まえるつもりであると知っているだけで物事をいじるのをやめるかもしれません。

すぐに始めるべきもう1つのことは、各クライアントボックスにできるだけ多くのバージョン管理ソフトウェアをインストールすることです。各システムにログインし、インストールに適切なステータス/差分ツールを実行して、何が変更されたかを確認できるはずです。それも定期的に郵送してください。繰り返しになりますが、これは、スキーマをコンポーネントとして管理対象にダンプするものと組み合わせると最も効果的に機能します。データベースに存在するコードに対して、深刻なバージョン管理アプローチを使用する人は十分ではありません。

これが、ここで役立つ技術的アプローチの主要なセットです。あなたが持っているものの残りは、コンピュータの問題よりもはるかに多くの人々の問題である古典的なコンサルティングクライアント管理の問題です。元気を出してください、それはもっと悪いかもしれません-あなたが彼らにODBCアクセスを与えて、彼らがAccessまたはそのような単純な何かで彼ら自身のクエリを書くことができることを彼らが発見するならば、FSMはあなたを助けます。

于 2009-10-06T05:14:11.350 に答える