MOSS


 

ここ最近、Citrix XenAppやらWin2008,Hyper-V、SystemCenter関連と戯れており、MOSSは全く触っていません。。。と、言う事で新ネタがありません(笑)

ですので、過去の経験を思い出しペースで更新しようかと。。。

 

64bit化・・・・SharePointも次期バージョンは64bitのようですが、ご存知のようにWindows Server 2008 R2も64Bitのみのリリースです。昨日、DLが可能になりました。

http://itpro.nikkeibp.co.jp/article/NEWS/20090815/335514/

MS社さん、64Bit化への移行を即す動きが止まりませんね(笑)

 

■32bit環境でのSharepoint

ASP.NET Web アプリケーション は、32Bit環境ではw3wp.exeのメモリ使用量が増加すると、場合によってはCPUの高負荷が発生します。

http://support.microsoft.com/default.aspx/kb/954830/ja

http://support.microsoft.com/kb/954828/ja

勿論、SharePointはASP.NET Web アプリですので、この状況が当てはまります。

 

また、SPDisposeCheck v1.3.1でも書いた通り、Dispose処理の無いWebパーツがあるとw3wp.exeのメモリ使用量が増加し、システム不安定やCPU高負荷が引き起こる可能性があります。

http://msdn.microsoft.com/ja-jp/library/bb687949.aspx

しかし、64Bit環境ではメモリの使い方が異なるので、64Bit環境の方が安心。ってところでしょうか?

 

■SharePoint次期バージョンが64Bitの理由?

経験上、MOSS2007は何かとw3p.exeのメモリ使用量は高くなります。

個人的な想定ですが、SharePointは

 

・ビジネス受けが良い多機能

・ブラウザ操作だけでサイトを作れる

 

などの”ウリ”が、裏ではw3wp.exeメモリ使用量増加の温床になっている気がしています。

多機能にすればするほど、プログラムは複雑化し、ASP.NET アプリとして無理・無茶がメモリ使用量増加に繋がっているような気がします。この動きはMOSS2007でも顕在化しており、今現在、MOSS2007は64bit環境での構築が推奨されています。

MOSS2007は32bitもサポートされていますが、次期バージョンは64bitのみ。

と、言うことは

 

「SharePoint次期バージョンは、更に新機能&機能拡張が多くなります。w3wp.exeのメモリ使用量の軽減は出来ないので、64Bitにしてね。32bitという、過去の器、アーキテクトではシステムを保てませんので。」

 

と、いうMS社さんの意思、方向性を感じてしまいます。

広告

 

新年明けましておめでとうございます。

私は1月3日から働いていますので、年明けという感じがしませんが。。。(笑)

 

新年一発目は、MS社技術文書から小ネタを紹介します。

既に、国内外のブログで紹介されている事例ですが、検索結果の背景色を追加する方法です。

例えば、標準では以下のようになります。

image

 

で、ちょっと手を加えると

image

の、ように文字背景色が追加出来ます。

Outlook2007っぽいですね。私は好きです。

このカスタマイズは、SharePoint Designer2007などのツールは必要無く、ブラウザ上の操作のみで実装が可能です。

 

■手順

http://technet.microsoft.com/ja-jp/office/sharepointserver/cc952469.aspx

上記サイトから、「Microsoft Office SharePoint Server 2007 自習書 検索サービスの運用手順 」をダウンロードします。

P91の”1.5.2. XSLTを変更する”に、この手順が紹介されています。

その他、このドキュメトには検索関連で重要な情報が多数、紹介されてるので必見です。

 

う~ん、MS社さんの日本語技術文書が充実して来ましたね。かなり嬉しいです。

2007年初頭は、ほとんど英語資料しかなく「MOSSは何が出来て、何が出来ないのか?」という事の実機検証が大変でした。

それで、お客さんからの機能要望に対して即答出来ず、社内外からひんしゅくを買いまくりました。

しかし、実機での技術検証をしないまま適当に「出来る、出来ない」と断言すると、後になってトラブルになる事は多々ありますので。。。SharePointはExchangeのように分かり易い製品では無いのです。

それに気づいていない人が、今だに多いのが現実のようですが。。。

 

■海外事例

やはり、検索結果画面のカスタマイズ事例は海外サイトに多数存在します。

日本版のMOSSで[主要な検索結果]Webパーツは、英語版では”search core results webpart”のようです。

で、”search core results webpart”をキーワードで検索すると色々と出てきます。

そんな中から、気になるブログをご紹介。まだ、ちゃんと読んでませんが非常に気になります。

http://www.zimmergren.net/archive/tags/XSLT/default.aspx

 

 

■その他、忘れちゃいけないMSDN

http://msdn.microsoft.com/ja-jp/library/ms584121.aspx

 

言わずもがなですが、Cドライブにインデックスファイルを溜め込むのは宜しくありませんね。

サーバOSとインデックスファイルが、同じドライブに存在する事は品性(笑)が許しません。

インデックスファイルが生成されるパスの変更手順については、MOSSの場合は簡単ですが、SharePoint Services3.0の場合は。。。

あ、知らない。。。。

 

って事で調べたので、備忘的にPOST

やっぱり、同じ事をしようとしている人は、世界のどこかにいます。↓

http://www.chandima.net/Blog/archive/2008/04/10/moving-sharepoint-search-index-location.aspx

 

 

■現在、設定されているインデックスファイルのパスを確認する。

以下のコマンドを投入
stsadm -o spsearch -action list

 

上記のコマンドを投入すると、以下のように現状の設定状況が表示されます。

ファームのサービス アカウント: ***********\**************
ファームのコンテンツ アクセス アカウント: ***********\***********
ファームのパフォーマンス レベル: *******************

*(サーバ名):
  状態: Online
  既定のインデックスの場所: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\Data\Applications
  インデックスの場所: C:\Program Files\Common Files\Microsoft Shared\Web ServerExtensions\12\Data\Applications
  検索データベース サーバー: ***********************
  検索データベース名: *********************
  SQL 認証データベース ユーザー:****************
  分音記号を区別する検索: オフ

 

上記の例では、C:\Program Files\Common Files\Microsoft Shared\Web ServerExtensions\12\Data\Applicationsの下に
インデックスファイルが生成されています。

 

 

■インデックスファイルのパスを変更する。

①D:\indexフォルダへパスを変更したい場合、以下のコマンドを投入します。

stsadm -o spsearch -indexlocation D:\Index

 

②正常終了すると、画面に「操作は正常に完了しました」と表示されます。
 設定変更が適用された事を確認する為、以下のコマンドを再度、投入します。

stsadm -o spsearch -action list

 

ファームのサービス アカウント: ***********\**************
ファームのコンテンツ アクセス アカウント: ***********\***********
ファームのパフォーマンス レベル: *******************

*(サーバ名):
  状態: Online
  既定のインデックスの場所: d:¥Index

  インデックスの場所: d:¥Index
  検索データベース サーバー: ***********************
  検索データベース名: *********************
  SQL 認証データベース ユーザー:****************
  分音記号を区別する検索: オフ

 

■フルクロールを実施する場合

パスの変更後、フルクロールを行いたい衝動にかられたので、以下のコマンドを投入

Stsadm -o spsearch -action fullcrawlstart

 

■STSADM.EXEのリファレンス該当箇所↓

http://technet.microsoft.com/ja-jp/library/cc288507.aspx

 

MOSSサーバのハードウェア設計を行う際、構成事例やベンチマークテスト結果などの資料が欲しくなりますね。

 

そんな時に参考となりそうな資料を紹介します。

 

 

■HP社の参考資料

HP社のハードウェアを使ったテスト結果など、サイジングする際に参考となりそうな資料です。

日本語版が無いのが非常に残念ですが、一読の価値はあると思います。

http://h71019.www7.hp.com/ActiveAnswers/cache/70677-0-0-0-121.html#270

 

■Microsoft Office SharePoint Server 2007 パフォーマンス検証 ホワイトペーパー

マイクロソフト社による検証結果があります。日本人が書いた、日本語の技術資料は嬉しいですね。もっと増やしてもらいたいですが。。。

http://www.microsoft.com/downloads/details.aspx?FamilyId=3DE4D6D4-C6BA-44DB-90C4-F7C2366B9BB9&displaylang=ja

 

■Technet

拠り所、設計根拠として必要ですね。

http://technet.microsoft.com/ja-jp/library/cc261716.aspx

 

 

MOSSの場合、ハードウェアを高スペック、増強してもサイト構成やパーツ構成起因でレスポンスが悪化する場合もありますので、要注意ですね。

 

それについはMOSSのレスポンス低下要因で紹介した情報が役立てば。。。

 

(2008/10/19追記)

Microsoft System Center Capacity Planner 2007でのハードウェア構成のシミュレーション手順書が出ました。

http://www.microsoft.com/japan/technet/prodtechnol/office/sharepoint/2007/selfstudy.mspx

「Microsoft Office SharePoint Server 2007 自習書 キャパシティー プランニング ツールの操作手順」

 

MOSSでサイト設計などを行う場合、

 

「サブサイトは無尽蔵に増やせそうだけど、上限数は?」

「リストパーツへ登録可能なアイテム数の上限数は?」

「1ページに配置出来る、Webパーツの上限数は?」

 

などの疑問や不安が発生します。

 

 

で、参考となりそうな指針がありました↓

http://technet.microsoft.com/ja-jp/library/cc262787.aspx

 

上記を見ると、いくらハードウェアを増強してもMOSSのアプリ的限界により

レスポンス低下が発生する検証結果が記載されています。

 

・サイトコレクション内のサブサイトが増えると比例してレスポンスが低下する。

・簡易的なWebパーツでも、1ページに最大で50個以上は配置しない。

・大量のアイテムを格納するライブラリは、フラット表示では無くフォルダ分けした方が良さそう。

 

などなど、指針を考える上での良い参考情報となりそうです。