スポンサーサイト

--年--月--日 --:--

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。

8.0.2

2008年11月13日 01:38

今日はちょっと疲れているのもあるので、息抜きっぽい話題にします。。。

サポートセンターでもだいぶ8.xの問い合わせが増えてきました。
WindowsとかでもSP1が出てから急に利用者が増える、て言いますがやはりNotes/Dominoも8.0.1が出てから検討を始める、と言う方が多いのでしょうか。今日はこんな記事から何か書いてみようと思います。

第3回 クライアントのパフォーマンスが大幅に向上する Lotus Notes 8.0.2

こんな事が書いてあります。
・ コールド・スタートアップ: 8.0に比べて52%改善
・ ウォーム・スタートアップ: 8.0に比べて73%改善
・ メモリー消費量: 8.0に比べて21%改善
・ 応答速度: 15%改善


あくまで1つの計測値ですが、8.0.2の起動スピードに有意な違いがあることは伝わるのではないかと思います。実際私のX31はスタンダードクライアントを使うにはかなり厳しいスペックですが、8.0.2にしてから起動時間が10秒ほど早くなっているのではないかと思います。

これはJVMのアップデートや種々のパフォーマンス関連の修正を行った結果なのですが、
「でも結局Standardクライアントは重いし、結局あまり変わらない気がする・・・」と思う方も多いのではないでしょうか。そんな疑い深い方のために8.0.2の起動時間が早くなったと思えるもう1つの理由を紹介します。

一度起動してもらえれば分かるのですが、8.0.2のStandard版はスプラッシュスクリーンが表示されるとNotesのWindowが出てくるより早くすぐにパスワード入力ウィンドウだけ出てきます。
 下らない変更だと思う方も多いかもしれませんが、これが意外と大きいのです。裏でNotesの起動処理をしている間にパスワードを入力している事になるので、パスワードの入力時間だけ早くなったように感じます。パスワードの入力に3-4秒かけている人にとって見れば、たとえ今までと実質的な起動時間同じであったとしても3-4秒の改善はしていることになります。

 だからワークスペースを表示するまでの時間は8.0.2は改善している、と言うのはかなりのユーザーで体感できる可能性が高いのです。
環境によって差異が大きそうな内部処理の最適化よりもこういう変更の方が分かりやすいのではないかな・・・て思います。 

 残念ながらこのパスワード入力ダイアログのタイミング変更はStandard版のみで、Basic版では今まで同じ通りNotesのウィンドウを表示した後に出てきます。

記事では、この他にも8.0.2の新機能の話が出てくるので是非ご一読下さい。

注: パスワード入力中に進行される処理は限定されているようです。
入力せずに放置しても起動処理は止まっているようなので・・・
スポンサーサイト

大きなデータベースはどのくらいのパフォーマンスに影響を与えるか?

2009年01月19日 00:50

 普段業務で使用しているノーツデータベースで、サイズの大きなものはどのくらいのサイズになっているでしょうか?

 よくお問い合わせでも何MB(GB)まで大丈夫なのか、と言うようなご質問も受けるのですが、こればっかりは何とも言えません。非常にハードウェア環境がよいお客様ではデータベースの最大サイズ(64GB)に近いサイズのデータベースを運用されているお客様もおられますし、数百MBのデータベースでも設計やエージェントが複雑だったりするために応答が遅くなってしまうようなものもあります。
 これは複数処理の自動化やリアルタイム性などデータベースの要件や重視するものによってはこのようになってしまうこともあるでしょう。

メールデータベースでもユーザー数を絞ればある程度大きなデータベースを運用する事も出来ますが、1つの問題点としては大きなメールサイズを抱えるメールサーバーはサイジングが難しくなる、と言う事だけは言えると思います。

今日はこのようなデータベースサイズについて可能な限り定量的な見解を出そうとした以下の文書を紹介します。経験のあるノーツ技術者の方は経験的にアドバイスできる事も多いと思いますが、そのような方でも参考になる分析がなされています。

How large databases uniquely affect IBM Lotus Domino server performance

バッファプールなどの増加がそれほど効果が無い事は昨今よく言われるようになっていたのですが、個人的に興味深かったのはトランザクションログに関する考察ですね。

- 通常サイズのデータベースではトランザクションログの効果は小さい
  (これは異なるトランザクションが同時に実行されるような負荷でないとトランザクションログの効果が出ないため、Server.Loadのような負荷テストでは効果が測定しづらかったようです)
- 大きなデータベースやビューを持つ環境では、トランザクションログを持つ方がパフォーマンスが落ちる場合があったが、トランザクションログをRAMDISKなど早いディスクに置くと劇的にパフォーマンスが向上した。(Fig. 5 では一番よいスコアを出しています。)

以下のようにまとめられています。

- 大きなビューの利用はトランザクションログに使用しているデバイスやビューの再構築用のディレクトリ等に関連したリソースを多く必要とするようになる。
- トランザクションログに使用するディスクのスピードは、重いビューやフォルダオペレーションが行われる環境ではより重要になる。
- 重いビューを持つデータベースは、View_Rebuild_dirなどで早いディスクを使用したディレクトリを指定することによってパフォーマンスを向上させることが出来る。

急いで訳したような文章なので、是非原文をじっくり読んで見る事をお勧めします。


Notes 文書の種類って何種類あると思いますか?

2009年01月20日 00:46

Notes データベースで、設計要素なども文書の一種だ、と言うのを聞いたことがある人は多いのではないかと思います。ACLや複製の設定なども文書です。 でもこれってきっと通常のメールのような文書とはきっと違うものだ、て事は何となく分かります。 だとするとNotesの文書って全部で何種類あるのでしょうか?

1. 設計要素の種類 + 通常の文書
2. 設計要素と通常の文書の2種類だけ!
3. 設計要素とACLも何か違う気がするから3種類!
4. その他


答えは 4. です。文書の種類は全部で12種類です。
Notesの文書は色々な設計要素とかありますが、すべてこの12個の文書クラスのいずれかに属しています。

1. 文書 (document note)
2. このデータベースについて文書のようなもの (notefile info)
3. フォーム文書 (form note)
4. ビュー文書 (view note)
5. アイコン文書 (icon note)
6. design note collection
7. ACL文書 (acl note)
8. ヘルプインデックス文書(Notes product help index note)
9.. ヘルプ文書 (designer's help note)
10. フィルター文書 (filter note エージェントなど。)
11. フィールド文書 (field note)
12. 複製式 (replication formula)

C API Toolkit などを使用している人なら、nsfnotes.h を見るとこの一覧を知ることが出来ます。
このように文書を12種類に分けたのは、この文書クラスと言うのが12種類あることに基づいています。
サポートではNSDなどを見るときにこの文書クラスなどを少し意識したりします。
これも機会があれば紹介できるといいな、と思います。

スマートアップグレードの帯域分散機能

2009年01月25日 00:20

 サーバーとクライアントのアップグレードでどちらが大変かと問われれば、クライアントのほうが大変だ、と思われる方は多いのではないでしょうか。

 アプリケーション互換性テスト、費用や工数の問題、様々な点を検討すると思いますが、お客様と話していると帯域が障害になってネットワーク経由のアップグレードが行えず、CD-ROMベースになるため簡単には行えない、と言う声も聞きます。 特に7.0.2 → 7.0.3 くらいのMRレベルでの更新ならそれほどアプリケーション互換も問題にならないので、こっちのほうが問題になるのかもしれません。

 さて、優秀なソフトウェア管理ツールなら常識かもしれないのですが、ノーツのスマートアップグレードが簡易な帯域分散機能は持っていることはご存知でしょうか。あまりこういう切り口で紹介されたものがなかったので、参考にしていただけたらいいな、と思います。

スマートアップグレードで帯域分散を考えるときには以下のようなアプローチがあります。
どれもよく考えてみたら当たり前かも・・・?と思得るようなものなのですが、バージョンアップ検討時などには意外とこういう機能があることを見落としてしまう方も多いのではないかと思うのでここで紹介させて頂きます。
(UI やフィールド名などはバージョン間で結構変わっているのでその点はご容赦ください)

1. 複数のスマートアップグレードデータベースによるホームサーバー毎の振り分け
 スマートアップグレードデータベースの指定はサーバー設定文書の「クライアントのアップグレード」タブにある「Smart Upgrade データベースリンク」フィールド(これはバージョン7以前では基本タブに「Smart Upgrade データベースリンク」フィールドがあります)で行います。
 これは何を意味するのか?と言うとスマートアップグレードデータベースはサーバー毎に異なるものを指定することが出来ます。
 つまり、添付ファイルからダウンロードするのであればサーバー毎に異なるものを用意することにすれば、添付ファイルのダウンロードは各ホームサーバー毎に異なるものを指定することが出来ます。
 ファイルサーバーを指定しているのであればホームサーバー毎に異なるファイルサーバーを指定することも出来るのです。
 よくよく考えてみると当たり前なのですが、サーバー毎の簡易な帯域分散機能と言ってよいのではないかと思います。

2. Smart Upgrade の同時ダウンロード数の制限
(この機能を使用するには、サーバー・クライアント共に6.0.5/6.5.4以上である必要があります)
これはSmartupgrade Governor 等と呼ばれることもありますが、サーバー設定文書で「Smart Upgrade の同時ダウンロード数の制限」を有効にしていれば使用可能です。
 一度にアップグレードされると帯域が占拠されて業務に支障が出ることが懸念される場合、ここで同時ダウンロード数を制御することによって帯域を一定量に押さえることが出来ます。
 帯域分散機能とは少し違うかも知れないですが。。。

3. 複数のスマートアップグレードキット文書
特定のグループのユーザーに対して異なるファイルサーバーを指定する場合、Smart Upgrade キット文書の「使用可能なユーザーとサーバー」フィールドを指定して、そのユーザー用のSmart Upgrade キット文書を作成するのが便利です。
 このフィールドはちょうど読者フィールドのように機能するので、使用可能なユーザーに対して冗長なキット文書が表示されることが無いように注意してください。


スマートアップグレード機能では、それでも時間帯を指定して強制的に行う、と言う類のアップグレードは出来ないのですが、工夫して設定することでそれほど奇怪なトリックを使わなくても帯域の利用率を分散したり、複数のファイルサーバーからバージョンアップを行うことが出来るのは分かっていただけたのではないでしょうか。
 分散させるために大量のデータベースや文書を作るのは管理上大変になってしまうこともあるので、お客様環境の帯域やユーザー数などに合わせてご検討ください。


実は以下の文書に添付されているPDFファイルの8ページくらいで取り上げられている「Distributed Deployment」と言うのがこの記事で取り上げているスマートアップグレードの帯域分散機能についてです。
Lotus Education On Demand: Lotus Domino/Notes 6 SmartUpgrade Tutorial

スマートアップグレードについての詳細は以下の文書も参考にしてみてください。
トラブルシューティングガイド:スマートアップグレードの問題 (文書番号 730994)

LMBCS

2009年02月03日 00:50

 NotesがLMBCS (Lotus Multi-Byte Character Set)を使っている、と言うことをご存知な方は多いと思いますが、なかなか詳細には公開されていない部分もあるのでブラックボックスに見える方は多いのではないかと思います。
 
 このブログでその全容を書くことまでは出来ないのですが、簡単にLMBCSの概要を説明することが出来たらな、と思います。

■ LMBCSとは?
 LMBCSはおよそ20年ほど前にLotus 1-2-3ファイルとNotesデータベースで複数言語を扱うためのキャラクターセットとして使用するために考えられました。

一般的に、LMBCSは1-3バイトからなる文字列です。
[グループバイト G] データバイト D1 [データバイト D2]

つまり、少なくとも1バイトのデータバイト(D1)は含みますが、グループバイトやデータバイト D2 は含まない場合もあります。

■ 1バイト文字
0x20-0x7FのASCII文字の領域は、LMBCS でも1バイト文字として扱います。
この意味で、LMBCSはASCII文字のスーパーセットであるといえます。

0x01-0x1F はグループバイトを表す文字として使用されます。
ただし、以下の文字は例外です。
0x09 : 水平タブ
0x0A : Line Feed
0x0D : Carriage Return
0x19 : (1-2-3用)

0x80 以上の文字を1バイト文字として解釈する必要があるときは Codepage 850(Extended Ascii)として解釈します。


■ グループコード
1バイト目が、グループコードの範囲であったとき、(上で定義した特殊文字を除く0x01-0x1Fの範囲の文字)その文字はマルチバイト文字と判断されます。 このとき1バイト目(グループコード)国をあらわします。国を表す、と言うと分かりにくいのですがNative Charactersetのような意味だと思ってください。日本語ならShift-JISになります。
以下が代表的な例です。

0x08 トルコ語
0x0B タイ語
0x10 日本語
0x11 韓国語
0x12 中国語(繁体字)
0x13 中国語(簡体字)

Notes.iniファイルなどに日本語が入っているときに0x10 と言う文字が入っているのを見た事がある方は多いと思います。(ノートパッドでは黒い四角のように見えていると思います)これはLMBCSのグループコードが入っているわけです。そのあとの字が正しく表示されているのは日本語の場合Shift-JISだからなのです。


■ 1バイトしか使用しないダブルバイト文字の場合
たとえば日本語の場合、半角カナのように1バイトしか使用しないケースがあります。
このような場合は、グループコードを繰り返すことによって表記します。

たとえば、 半角かなの ァ(0xA7)と言う文字を表すのであれば
0x10 0x10 0xA7
のようにグループコードを繰り返して表記します。



あんまり詳細まで入れませんが、LMBCSと言っても日本語を扱う限りにおいては、Shift-JISに0x10とか余計なバイトが紛れ込むだけでそれほど訳の分からない文字でもないことが分かってもらえるのではないかと思います。


バッファプールは大きくするべきか?

2009年02月23日 00:17

 このような文書が発行されていることをご存知でしょうか。

(参考)NSF_BUFFER_POOL_SIZE_MB パラメータ設定の推奨 (文書番号 731369)

ドミノサーバーはプロセス間通信などを容易にするために、他のアプリケーションと比べて共有メモリの使用量が多いと言われます。 NSF BUFFER POOL はその中核を占めるものでありますし、Notesの NSF関連のI/O をメモリに格納してくれるものであるならある程度の物理メモリを搭載している場合には出来るだけ大きな値を指定した方がよい・・・と言う理解の下にチューニングを行う際に大きな値を設定しているケースが大きく見受けられます。RDBなどで、バッファプールをチューニングする際にはそのように考えるのではないかと思います。

元々搭載物理メモリがそれほど大きくない時代には「搭載物理メモリの3/8程度」としてこれでもよかったのですが、昨今は4GB以上の物理メモリを搭載しているサーバー機も増えており、大きければよい、と言うよりも大きすぎる共有メモリが色々な問題を起こす、と言うケースも増えてきました。
上記の文書はこのような背景の下に発行されました。

この文書では4GBの物理メモリだと多すぎるのでたとえばWindowsだとユーザー空間は2GB使えるので、その3/8 くらい、750MB程度を限界にして下さい、という話は昔からサポートでも案内していました。
 しかし、最近では大きな値を設定しても本来の目的であるパフォーマンスメリットも得られず、共有メモリを圧迫するだけなので512MB程度を最大値にすれば十分であることが分かってきました。

実際に 公開されている Dominoのベンチマークをした際の設定を見てみても、バッファプールは小さく設定されていることが多いのではないかと思います。

チューニング目的で大きな値を設定された場合には特に、小さく設定変更をすることには難色を示されるケースも多いのですが、サーバーがクラッシュしてから初めてこの話を耳にするお客様も多いので、もし設定変更の機会があったら一度検討してみてください。

HTTP アクティブスレッド数

2009年02月27日 00:15

バッファプールの話を書いてたらこの話も浮かんできたので。。

(参考)Lotus Domino HTTP アクティブスレッド数の推奨 (#731489)

HTTPのアクティブスレッド数は最大でも80程度で、と言う内容の文書なのですが、バッファプールの話と比べるとこちらはもう少し話が複雑に思えます。

HTTPアクティブスレッド数の上限を少なくするのもやはりパフォーマンス上デメリットがあるから、と言うよりこれより大きな値を設定するとリスクが大きくなる、と言う意味合いも大きいのではないかと思っています。
 スレッド数を増やすと、Process Heapの使用量は増えてしまうのでノーツの文書情報のようなプロセス間で共有される可能性のある情報がヒープを圧迫してしまったりする恐れがあるのです。なのでうちの環境では増やしたほうがパフォーマンスがよかった、と言う声も度々聞かれるのですがやはり問い合わせでは大きな値は可能な限り、戻してもらう事を検討して頂けないかをお願いさせて頂いたりしています。

比較的処理時間の長い WebQueryOpen/WebQuerySave エージェントが、頻繁に実行されるようなケースではアクティブスレッド数は意外と足りなくなりやすいのですが、そのようなケースでもアクティブスレッド数を増やすよりは、別のサーバーに振り分けるようなことを考えたほうがよいのではないかと思います。逆にあまり計算が走らないようなWebアプリでは80スレッドでもかなりの同時ユーザー数をカバーできたりします。


Technoteでは、パフォーマンスの評価をする際にも、単純に消費されたスレッド数だけでなく、リクエストの平均処理時間などを考慮したうえで決める、と言った原理的な話も出てくるので是非ご一読頂ければと思います。

Lotus Domino 8.5 performance for IBM Lotus Notes users

2009年03月17日 00:05

こんな文書が出ていますね。

IBM Lotus Domino 8.5 performance for IBM Lotus Notes users

もちろん8.5が8.0より悪い結果が出ていたらこんなベンチマークを公開する意味はなくなってしまうので、当然8.5のほうがよいパフォーマンスを示した、と言う内容に決まっているので、少し詳細をみてみましょう。

プラットフォーム毎に結果が並んでいますが、マシンスペックなども同じでないのでプラットフォーム毎の比較はあまり重要ではありません。ここでの記事は全てのプラットフォームで有意な効果があった、と言う風にに読んでおけばいいのではないかと思います。

 今回のレポートでのパフォーマンス改善のキーは、どれも劇的なDisk I/Oの低減が確認出来た、ということに尽きるのではないかと思います。「xx% レスポンス向上」と言うのは環境によってはそれほどの数値効果が得られないかもしれないのですが、I/O低減はどんなマシンスペックでも効果が得られるものなので非常にポジティブな結果なのではないかと思います。

この結果を注意深く見ると、テスト条件として8.5では以下の設定が加えられています。

・ Compress document data
・ Use Lotus Domino attachment and object service
・ Debug_NSF_Compress_All_Notes=1

つまり、I/O低減のため、文書の圧縮と、添付ファイルに対してはDAOSを有効にしていることがポイントなのではないかと思います。
 DAOSに関しては、Server.loadのN85Mail workload とかを使っている限りではそれほど重複した添付ファイルが出ない気がするので、DAOSの効果よりも文書圧縮の効果が大きく出たのではないかと思います。(ちなみに、文書の圧縮はODS 48が必須ですが、8.0.1 から使用可能です。)
 HTTPのGZIP圧縮とかでもよく懸念される事ですが、「データを圧縮したり解凍するとCPU 負荷が高そう」と思ってしまうのですが、ほとんどの場合ドミノではディスクがボトルネックになっている事が多いので、圧縮してデータのサイズを小さくしてI/Oを減らす効果は圧縮や解凍処理のペナルティより効果が高いようです。

もちろん、文書圧縮の効果だけでなく、Lotus Domino 8.5 では Routerタスクのパフォーマンス向上で各種最適化が行われた、とも聞いているのでI/O低減はその効果もあるんだと思いますので何もかもこの設定のおかげだ、と言う訳では無いと思います。

興味がある方はベンチマークレポートもじっくり見てみてください。

クライアントをサーバー上で動かしたい

2009年03月24日 00:07

特にR4.x からご利用のお客様では簡易なシステム管理作業は、サーバー上でクライアントを動かして、ローカルのアクセス権で処理してしまいたい、と思う方は多いのではないでしょうか。

これは非常に便利な方法だったと思うのですが、残念ながらこの方法は現在ではサポートされません。 特に6.x以降のDominoサーバーでは、nlnotes.exeを無理やり起動するだけでエラーメッセージが出るのが分かると思います。以下の文書にある通りです。

Running the Notes client on the same machine as a Domino server (#1094021)

しかし、この文書を読むと、「別のディレクトリにプログラムディレクトリとデータディレクトリを入れればサポートされる」と読めるのでこの点については違和感を感じてしまう方もいるかもしれません。
 これは、「Where it makes sense」と言うフレーズにも代表されるとおり、アーキテクチャ上の話について言及したもので、実際にはサーバーとクライアントが両方サポートしているOSはR6.x 以降は無いので、結局はサポートされません。 この文書が想定しているのはAPI プログラムをスタンドアロンプログラムとして動かす場合には、このようにクライアントをサーバー筐体にインストールして利用する事も考えられるからです。APIが主に使うnnotes.dll はサーバー・クライアント共に同じものなのでディレクトリさえ分けてもらえれば、あまり影響が無いためです。

なので、サポート的にはこのようなアクセス方法の代替機能として、フルアクセスアドミニストレータを利用する必要があるわけですが、やはり何でもかんでもフルアクセスアドミニストレータで作業するわけにも行かないので、運用上厳密にどのような場合に使うのか、と言うのは規定しておいたほうがよいのではないかと思います。

同じディレクトリからサーバーとクライアントを起動すると何が問題なのでしょうか?
このような実行方法を示すのに分かりやすい例として、サーバーコンソールから「load nlnotes」を実行して動作を見てみてください。
 このとき、ノーツを終了するとサーバーのシャットダウン処理がスタートします。
これは、ノーツ内で終了処理が入ると、メモリを共有しているサーバーもシャットダウン状態に入ってしまうためなのですが、このようにクライアントとサーバーで考え方の違うメモリ管理をしているために正しく処理されない場合が発生するからです。

とは言え、簡易にサーバー上でクライアントを使えたら便利だなあ・・・・と思うときは確かにあるのですが・・・・

Nagle algorithm

2009年03月26日 00:19

拍手があると励みになる、と言う事を記事に書いたら思ったよりたくさんの反応があってうれしかったです。そもそもワークスペースの操作、についてはツールが欲しかった方も多かったのかもしれません。

さて、今日はネットワークの絡むお話をしてみようと思います。
Notes の問い合わせで、Nagle algorithm とか出て来たらちょっととっつきにくいですよね。
残念ながらこの話は、NotesNetworkの問題では度々出てきます。

# 実はどう読むか悩んでいたのですが、ナグルアルゴリズムと言うカナが振られているサイトをよく見ますが、John Nagleとかが提唱者なようで、英語的に考えるとどう考えてもネーグルなんじゃないかと思いますが実際のところどうなのでしょう。。。(ちなみにアルクで検索したらネーグルとなっていました。。)

この文書の7.5のところを読んでみて見ると、Nagle アルゴリズムを無効にしてみるような内容の記事があります。
トラブルシューティング:クライアントとサーバー間の接続の問題 (#731795)

Nagle Algorithm は、NotesNetworkパフォーマンスに悪い影響を与える事が分かってきて、8.5 からデフォルトで無効になっています。このような背景もあり、7.x 及び 8.0.x の環境においても無効にすることを推奨しています。

「DEBUG_PD_NAGLE_OFF & EnableNagle: the Nagle algorithm should be disabled」(Domino Wiki)

Notes側でどんな症状が出るのか?と言うと、サーバー接続やDBを開く際にはそれほど大きな遅延が無いのですが、複製や添付ファイルのダウンロードのように大きなストリームデータを扱う際にパフォーマンスが大きく遅延します。別に止まったりするわけではないので気が付きにくいので、ネットワークのスループットなどにかなり自信がある環境でないと気が付きにくいかもしれません。

このアルゴリズムはNotesだけが使っている怪しいアルゴリズムではありません。
RFC896 などで規定されているもので、小さなネットワークパケットが頻繁にネットワーク上を飛び交うの抑えるためのものです。
 送信データのサイズがMSSを超えない場合に、全ての送信パケットにAckが帰ってくるまで送信バッファを遅延させるのですが、Windowsではこのタイムアウトがデフォルトで200msになっているのでうまく帰ってこないときはパケットが200msほど遅延してから送信されます。小さな遅延に思うかもしれないですが、パケット単位で周期的にこの遅延が起こると結構な影響を受けてしまいます。

 更に悪い事にこれは遅延Ack(Delayed ACK)を相手側が有効にしていると、受け手はAckをバッファリングするので更に応答遅延してしまったりもするし、色々な場面でヒットします。

と言うわけで、Notesでヒットする事は度々あるのですが、ネットワーク関連の話になると話が分かりにくく感じてしまう部分もあるかと思うので、関連症状に当たったらちょっとこの可能性は無いかな?と思い出してもらえるといいかな、と思います。




最新記事


上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。