4

OK、私たちはここで私たちのロープの終わりにいます、そして私はSOコミュニティからのフィードバックに本当に感謝しています。

基本的な問題は、MOSSベースのイントラネットによるパフォーマンスの低下です--

いくつかの環境情報:

コラボレーションベースのサイト用のMOSS標準版があります。

  • sitedbは29Gbです
  • 2つのVMWareベースのフロントエンドサーバーがあります。(各2x 32ビットCPU)
  • すべてのタイムゾーンに広がる1000人未満のユーザー
  • サブサイトを含む1つの大きなサイトコレクションがあります。

一般的な症状: フロントページと「ウォームアップ」されたページの読み込みはかなり適切ですが、殴られた道から外れたページ/サイトの読み込みは非常に遅くなります。

スパイクが見られます。ページの読み込みに突然30秒かかるのに対し、通常の2

これが私たちがすでに行ったことです:

  • クロールを縮小
  • 有効なオブジェクトとBLOBのキャッシュ
  • 最適化されたVMwareセットアップ
  • MOSS Sharepointのベストプラクティス(特にリストサイズなど)に関するMicrosoftITホワイトペーパーに従った

ここで他に何をすべきかわかりません—複数のサイトコレクションに分割しますか?

64ビットのフロントエンドサーバーに切り替えますか?

同様の状況にあった他の人から話を聞くのは素晴らしいことです。

4

9 に答える 9

3

フロントエンドサーバーにどれだけのメモリがあるかはわかりません。32ビットであるとすると、ワーカープロセスあたりの最大数は約2GB以上であると想定します。

私のアドバイス?64ビットに切り替えてメモリを追加し、フロントエンドごとに1つのw3wpワーカープロセスだけを使用していないことを確認します。「Webガーデン」、つまりフロントエンドごとに複数のw3wpプロセスを構成する場所を掘り下げてください。まず、フロントエンドごとに2つのworkerprocessから始めて、それがどのように機能するかを確認します。また、リサイクルするように設定されていること、およびワーカープロセスの各ペアのリサイクルが重複しないことを確認してください。2人以上のワーカーがいるということは、アクセスを切断せずに順番にリサイクルできることを意味します。

ちょうど私の0.02。

-オシーン

于 2008-11-18T14:44:58.320 に答える
2

あなたの最初の仕事は、問題が実際にどこにあるのかを判断することだと思います-物事を変えるのに時間を無駄にしていることがわかるまで。

  • データベースサーバーは別のサーバーにありますか、それともWebサーバーの1つにありますか?

  • フロントエンドまたはdbサーバーにCPU/ディスクのボトルネックがありますか?

  • それはあなたの世界的なように聞こえます。サーバーに近いネットワークでも同じパフォーマンスの問題が発生しますか?それはWANの問題ですか?

于 2008-11-18T16:03:18.100 に答える
2

はい、キャッシュはシステムの負荷を軽減するための最良の方法です。SQLサーバーにRAMを追加するのも良いことです。(64ビットはSQLサーバーにとって本当に必須であり、WFEはそれほど重要ではありません)。

ただし、プロセスをリサイクルするかどうかはわかりません。プロセスをリサイクルすることで1つのパフォーマンスの問題が解決したように見えたが、他の問題を紹介していたという誰かとの会話を除いて、これについての証拠はありません。

キャッシングについて言及しましたか?

SQL Serverは最大100Gbのデータベースを処理する必要がありますが、そのサイズではバックアップなどの管理が困難になるため、サイトを関連するサイトコレクションに分割することは、今のところ計画する必要があるかもしれませんが、これは適切ではない可能性がありますパフォーマンスに。

于 2008-11-19T21:57:26.260 に答える
2

有益なアドバイスをありがとうございました。私が学んだことの 1 つは、私たちのオブジェクト キャッシングは基本的に何もしていないということです! これは、サイト コレクションの任意の場所を編集する権限がある場合、デフォルトでポータル全体のオブジェクト キャッシュが無効になるように見えるためです。すべてのユーザーは少なくとも何かに対する権利を持っているため、これはキャッシュが基本的に何もしていないことを意味します!

これは、キャッシュのデバッグを有効にすることで発見されました。これにより、使用されているキャッシュに関する小さなコメントが HTML に挿入されます。認証済みキャッシュ プロファイルで [書き込み者にキャッシュされたコンテンツの表示を許可する] の設定を変更した後、

これが編集者にどのような影響を与えるかを確認していますが、通常の視聴者にとっては、大きな影響を与えているという逸話的な証拠があります!

于 2008-11-18T16:36:24.850 に答える
1

ソフトウェア境界の計画(Office SharePoint Server)を確認しましたか?

一見すると、サーバーは推奨設定に適合しています。

パフォーマンスを向上させるには、以下を確認する必要があります。

  • 64ビットサーバー
  • ドキュメントリストに表示されるアイテムの数を制限する (出典:microsoft.com表示されるアイテムの数を制限する
于 2008-11-18T15:50:33.663 に答える
0

ディスク使用量を必ず確認してください。2つのVMがあり、それらが同じディスク/ SANで実行されている場合は、ビジー状態になりすぎないようにしてください。過負荷のSANはパフォーマンスを低下させます

于 2008-11-20T01:50:49.863 に答える
0

私は非常によく似たセットアップを実行していますが、3 つのサイト コレクションに 400GB 以上が分散しています。64 ビット パスに進む前に、他にもいくつか試してみることができます。

  • DB サーバーと Web フロント エンドの間にディスクまたは帯域幅の問題がないことを確認します。データベース サーバーへのネットワーク速度は重要です。
  • データベース サーバー自体を確認します。ディスクが SAN 上にある場合、SAN 上の物理ドライブに競合がある場合、パフォーマンスの問題が発生する可能性があります。RAM も重要です。メモリにキャッシュできる量が多いほど、ディスクの応答を待機する時間が短くなります。
  • クロール ジョブを通常の営業時間外に実行するようにスケジュールする
  • オブジェクト キャッシングを有効にしました。これは非常に役立ちます。圧縮も有効になっていることを確認してください。低帯域幅のユーザーの場合、sharepoint は大量の CSS 情報をユーザーに送信し、圧縮が有効になっている場合はサイズを 1/10 に圧縮します。
  • もう 1 つの大きな問題として、会社の DNS が他の場所で正しく機能していることを確認し、この問題が外部ソースに関連しているかどうかを調べます。IE では、sonicwall ファイアウォールを使用していますが、それを介して接続しているオフィスの応答時間は非常に厳しいものです。
  • Microsoft には、パフォーマンス カウンターの監視に関するホワイトペーパーがあります。これは非常に詳細で、CPU/RAM/ネットワーク/HD IO の間の問題を絞り込むのに役立ちます。

お役に立てれば!

于 2011-03-09T19:47:53.880 に答える
0

パフォーマンスの問題もあります。win 2008 64bit witch にアップグレードしたところ、多少の違いはありましたが、期待したほどではありませんでした。

bih ブーストにより、NTLM 認証から Kerberos への変更が可能になりました。これは私たちの大きな改善でした。

これが誰かに役立つことを願っています

于 2009-06-30T12:22:11.733 に答える
0

私はリングに脱帽し、64 ビットも推奨します。すぐに解決できるものではないかもしれませんが、今後は、ファーム全体の目標として 64 ビットに移行することをお勧めします。

また、Web フロント エンドでは問題にならないという Nat のコメントについて、いくつかの問題を取り上げたいと思います。ベンチマークについて議論したり、メモリのアドレス指定可能性について議論したりしません。それよりも本当に簡単です。

Microsoft は、2007 が 32 ビット サーバーで実行される SharePoint の最後のバージョンであると公言しています。今後は 64 ビットが要件となる予定です。FRAM オイル フィルター担当者が言うように、「今支払うか、後で支払うか」...

于 2009-01-20T04:21:50.510 に答える