最適化の問題ではなく、生産性を10〜20％向上させる必要がある場合、生産性の低下の原因を見つけて排除することです。 同意します、これらはいくつかの異なるものです。 インターネットでは、多くの記事が生産性の向上に関するものであり、1cサーバーのセットアップやデータベースサーバーのセットアップによってのみ制限されています。 しかし、特にいくつかの理由があり、これらの理由が異なるレベルにある場合、生産性の低いケースを扱った記事を見たことはありません。
通常、管理者は急いで監視結果を監視します。 私が遭遇したケースでは、プロセッサ負荷がほとんどゼロであり、空きRAMが存在し、ネットワークインターフェイスにキューが存在せず、ディスクへのキューのみがすべてが正常であるとは限りませんでした。 私は完全なプログラムに従ってチェックを手配しなければなりませんでしたが、これにはもちろん時間がかかり、ワークフローからサーバーを除外する必要がありますが、結果は得られます。 おそらく、このアプローチは受け入れられない人もいるでしょうし、さらに、これは非専門的なアプローチであると考える人もいますが、私は何も手伝いません。
ハードウェアレベル
それは陳腐なように聞こえますが、開始する価値があるのは鉄の健康状態のチェックです。 実際、オペレーティングシステムのレベルを見ると、機器の問題についてしか推測できないということです。 私の場合、ディスクアレイ内のディスクの1つが機能しませんでした。 奇妙なことに、ハードドライブは動作していることが判明しました。ハードドライブを所定の場所に配置した後、動作しましたが、すべてのデータが同期されるまでしばらく待たなければなりませんでした（かなり前にオフになっています） このすべてが終了した場合、この記事はありませんでした。 念のため、サーバーでハードウェアテスト（ストレステスト、メモリテスト、ディスクとコントローラーの物理的チェック）を実施しましたが、問題は明らかになりませんでした。
オペレーティングシステムレベル
プログラムの2番目のポイントは、オペレーティングシステムの確認と調整でした。その本質は次のとおりです。
- ファイルシステムを整理します。
- 不要なサービスを無効にし、不要な、そして最も重要なのは悪意のあるプログラムを削除します。
- オペレーティングシステム設定の最適性を確認してください。
ファイルシステムを整理するということは、奇妙に見えるが、多くの管理者がサーバーオペレーティングシステムに適用できないと考えている最も明白な操作を意味します。 それは約です：
- ディスクの論理構造を確認します。
- 一時ファイルと不要なファイルを削除します。
- ファイルシステムの最適化。
公平に言うと、SSDディスクのデフラグは実際には何も与えず、書き込みサイクルの数を増やすだけです。 私の場合、ファイルシステムを整頓した後、サーバーは少し動き始めましたが、それでもまだ十分ではありませんでした。
ウイルス対策スキャンや未使用のサービスの無効化が必要な理由を説明する必要はないと思いますが、これを無視するべきではありません。 おそらく、このサーバーには不要になったプログラムがインストールされた可能性があります。 さて、システムとプログラムを更新してください。
オペレーティングシステムの設定の最適性に関しては、私の場合、経済的な電力モードが設定されていました。 最大パフォーマンスモードを有効にした後、Gilevテストは満足のいく結果を示しましたが、その特定のサーバーはより良い結果を示しているはずです。
理由を見つけるために、リソースの使用状況の監視が行われましたが、最初から、ディスクサブシステムの多くを占めるプロセスを検索する必要があることは明らかでした。 私の場合、最良の指標は「ディスクへのキューの長さ」でした。 残りのインジケータは通常のものであり、もちろん元のインジケータと比べてわずかに変化しましたが、一般的には、インジケータはディスクへのキューの長さのままです。 監視結果は明らかでした。1Cサーバーとデータベースサーバーのプロセスは「リソース泥棒」であることが判明しました。
サービスレベル
私の場合、サーバー1cはMS SQLデータベースサーバーと同じマシンに配置されていましたが、サーバーのハードウェア構成により共同操作が完全に保証されましたが、これら2つのサービスの設定はまったく最適ではありませんでした。 この設定など、多くの記事がこれらの設定に当てられています。ここでは、ハードディスクの購入など、追加の投資を必要としない設定のみに焦点を当てます。
各データベースのMS SQLサーバーでは、1Cデータベースが急速に成長しているため、データベース自動拡張パラメーターの値が500 MBに増加しました。 また、データベースダンプの作成に加えて、統計が更新され、手続き型キャッシュがクリアされ、インデックスの最適化が追加された、毎日の保守計画も設定されました。 私の場合、これにより書き込み操作の数が著しく減少しました。 追加の手段として、データベースを最適化し、インデックスを毎週再編成することをお勧めします。
1Cサーバーの場合、作業サーバーのパラメーター「プロセスごとのISの数」と「プロセスごとの接続の数」が変更され、最初の値は1、2番目の値は25になりました。 検討中のケースでは、これらのパラメーターの変更により、サーバーでの読み取り/書き込み操作が大幅に減少し、予期されたモードで機能しました。 Gilevテストでは、生産性の向上も確認されました。
基本レベル
ワークロードの下で測定を行った後、ユーザーが去った後、私は奇妙な結果に遭遇しました-負荷の下で、Gilevテストは単純なものよりも良い結果を示しました！ テストベースで実行される膨大な数のバックグラウンドタスクも確認されました。 テストベースは、さまざまなテストタスクのためにシステム管理者によって使用されました。 私はそれらを削除するように頼みました-そして、すべてが適所に落ちました。 実稼働サーバーにテストデータベースを保持するかどうかを決定するのはユーザー次第ですが、たとえばファイルバージョンを使用するなど、このための他のソリューションを見つけることをお勧めします。
一方のデータベースはトランザクションログを削減できませんでしたが、もう一方のデータベースはインデックスを再作成しませんでした。 どちらの場合も、シンプルで効果的なソリューションが1つあります。 説明する前に、異なるオブジェクトに同じ名前があることを明確にする必要があります。1CベースとMS SQLベース。前者はMS SQLベースではなく、たとえば、PostgreSQLベースです。 また、後者は必ずしも1Cのベースになるとは限りません。 これに基づいて、1Cデータベース（dtファイル）のバックアップコピーを他のDBMSにデプロイできますが、同じコピーからMS SQLをデプロイすることを禁止するものはありません。 1Cを使用して1Cデータベースのバックアップコピーを削除し、1Cサーバーから1Cデータベースを削除してから再度作成し、dtファイルの内容を入力します。
すべてのデータベースを整理したので、文句を言う必要はありませんでした。サーバーがスムーズに実行され、ディスクサブシステムが正常に動作しており、ユーザーは1秒での高速作業に満足していました。
おわりに
1つのレベルのみを使用して生産性の低い原因を検索する場合、他のレベルにある理由、つまり結果が達成されない理由を無視できます。 与えられた例は、いくつかの理由があることを明確に示しており、それぞれが独自のレベルにある可能性があります。 この資料が、パフォーマンスの低い1Cサーバーの問題を克服するのに役立つことを願っています。