additional-information
ERDDAP™- 自分で設定するERDDAP™
知っておくべきこと
プロキシエラー
時々、要求へのERDDAP™プロキシエラー、HTTP 502 Bad Gateway Error、または同様のエラーを返します。 これらのエラーは、Apache または Tomcat によってスローされます。ERDDAP™それ自体。
- これらのエラーを生成するたびに、特に最初に設定するときにERDDAP™, おそらくプロキシまたは悪いゲートウェイのエラーです。, 解決策は、おそらく修正することですERDDAPプロキシ設定お問い合わせ 設立時にも問題になる可能性があります。ERDDAP™突然、すべてのリクエストに対してこれらのエラーを投げ始めます。
- それ以外の場合、"proxy" エラーは通常、Apache または Tomcat によってスローされたエラーをタイムアウトします。 比較的迅速に起こる場合でも、Apache や Tomcat からの応答がいくつかあります。ERDDAP™いくつかの他のリソースによって非常に忙 しく、メモリ制限されています。 これらの場合は、以下のアドバイスを参考にしてください。ERDDAP™ゆっくり反応するお問い合わせ
長時間にわたる要求 (>30 ポイント) グリッド化されたデータセットから、多くの場合、プロキシエラーとして表示される故障をタイムアウトする傾向があります。ERDDAP™すべてのデータを1つずつ開く。 お問い合わせERDDAP™それ以外の場合は、リクエスト中に問題が発生する可能性が高いです。 データセットのファイルが圧縮されている場合は、データセットのファイルが圧縮されているかどうかを判断するのは困難ですが、問題は起こりうる可能性があります。 ソリューションは、複数の要求を、それぞれより小さな時間範囲で行うことです。 時間範囲の小さは? 私は本当に小さいから始めることをお勧めします (~30ポイント?) , それから (お問い合わせ) リクエストが失敗するまでの時間範囲を倍増し、1つの倍増します。 それからすべての要求をします (それぞれが時間の異なるチャンクのために) すべてのデータを取得する必要があります。 ログインERDDAP™管理者は、増加することにより、この問題を軽減することができますApache のタイムアウト設定お問い合わせ
モニタリング
私たちは、すべてのデータサービスが自分の聴衆を見つけたり、広く使用されるようにしたいが、時には、ERDDAP™すべてのリクエストに対して超遅い応答を 含む問題を引き起こし、あまりにも多くの使用することができる。 問題を回避する計画は次のとおりです。
- モニターERDDAP™お問い合わせstatus.html ウェブページお問い合わせ 役に立つ情報がたくさんあります。 膨大な数のリクエストが来たり、大量のメモリが使われたり、失敗したリクエストのトンや、各メジャーなLoadDatasetが長時間かかっているか、退屈してゆっくりと反応するようなものを見たりすると、ERDDAPお問い合わせlog.txt ファイル何が起こっているかを見るために。
ステータスページが応答速度が速いことに注意するのも便利です。 ゆっくり反応すると、重要な指標であるERDDAP™とても忙しくて。
- モニターERDDAP™お問い合わせデイリーレポートメールアドレス
- 最新のデータセットを経由して見る ベースUrl /erddap/outOfDateDatasets.htmlオプションに基づくWebページtestOutOfDateグローバル属性。
外部モニター
上記の方法は、ERDDAP'監視自体の方法。 外部システムを監視したり、使用したりすることも可能です。ERDDAPお問い合わせ これを行うための一つのプロジェクトAxiomのerddap-metricsプロジェクトお問い合わせ このような外部システムにはいくつかの利点があります。
- 必要な方法で表示する、必要 な情報を提供するためにカスタマイズできます。
- それらはについての情報を含むことができますERDDAP™ということERDDAP™CPU使用、ディスク空き容量など、簡単にアクセスできません。ERDDAP™ユーザーの視点から見た応答時間、ERDDAP™アップタイム,
- アラートを提供できる (メール、電話、テキスト) 問題が閾値を超えたときに管理者に。
複数の同時同時同時 リクエスト
- 複数の同時リクエストを作るブラックリストユーザー! 一部のユーザーが複数の同時リクエストを繰り返し、継続的に行うことが明らかな場合は、IP アドレスを追加してください。ERDDAP? ? ? ?<リクエストブラックリスト> (/docs/server-admin/datasets#requestblacklist) お問い合わせdatasets.xmlファイル。 リクエストは 1 つの IP アドレスからすべてです。 時々、複数のIPアドレスからあるが、明らかに同じユーザーです。 また、不正な要求や、マインド・インセンブルな非効率的な要求のトンを作る人々をブラックリストにすることができます。
それから、彼らが作る各要求のために、ERDDAP™リターン:
HTTP ERROR 403 - Access Forbidden --
Your IP address is on this ERDDAP's request blacklist.
Did you often submit more than one request at a time?
Did you often submit identical requests in a short period of time?
Did you submit a large number of invalid requests?
If you are ready to avoid these problems, please email \[ERDDAP™ administrator's email address\] to request to be taken off of the blacklist.
うまくいけば、ユーザーはこのメッセージが表示され、問題の修正方法を見つけ、ブラックリストをオフにする方法を見つけるためにあなたに連絡します。 時々、彼らはちょうどIPアドレスを切り替え、再び試してみてください。
戦争における攻撃力と防御力のバランスが似ています。 ここでは、防御的な武器 (ERDDAP) CPU、ディスクアクセス帯域幅、ネットワーク帯域幅のコア数に制限された固定容量を持っています。 しかし、攻撃的な武器 (ユーザ、著しくスクリプト) 無制限の容量を持っています:
- 大量のタイムポイントからデータを要求する単一のリクエストは、ERDDAP膨大な数のファイルを開く (順序か部分的に複数の踏まれた) お問い合わせ 極端な場合、1つの「シンプル」要求は、簡単にRAIDを結び付けることができますERDDAP™1分間、他のリクエストの処理を効果的にブロックします。
- シングルは、メモリの大きなチャンクを消費することができます (でもERDDAP™大規模なリクエストを処理するために必要なメモリを最小限に抑えるコード化) お問い合わせ
- 並列化 ・ たくさんのスレッドを生成することで大きなタスクを並列化し、それぞれが別々のリクエストを送信します。 (大きいか小さいかもしれない) お問い合わせ この行動は、コンピュータサイエンスコミュニティが大きな問題に対処するための効率的な方法として奨励されます (そして並列化は他の状況で有効です) お問い合わせ 戦争のアナログに戻る: ユーザーは、本質的にゼロである各コストで同時リクエスト の本質的に無制限の数を作ることができますが、各要求のコストは、ERDDAP™大きく、ERDDAP's の応答機能は finite です。 明確に、ERDDAP™この戦いを失います。ERDDAP™管理者は、他のユーザーを不公平に混雑させる複数の同時リクエストを作成するユーザーをブラックリストします。
- 複数のスクリプト - 並列化されたスクリプトを実行している複数のクレバーユーザーがいるときに何が起こるかを考えてみましょう。 1人のユーザーが他のユーザがクラウドアウトしているリクエストを多く生成できる場合、そのような複数のユーザーが複数のリクエストを生成できるため、ERDDAP™圧倒されず、反応しない。 それは効果的にありますDDOS攻撃再び、唯一の防衛のためのERDDAP™他のユーザーを不公平に混雑させる複数の同時リクエストを作るブラックリストユーザーです。
- 膨らみのある期待 - 大規模なテクノロジー企業の世界 (アマゾン、Google、Facebook、...) , ユーザーは、プロバイダから本質的に無制限の能力を期待しています. これらの企業は、運用を収益化しているため、より多くのユーザーが、ITインフラを拡大するために必要な収益が増えています。 そのため、大規模なITインフラが要求を処理することができます。 そして、ユーザーは、単一のリクエストが煩わしいものではないよう、ユーザができるリクエストの種類を制限することで、ユーザからリクエストのリクエスト数とコストを制限し、理由がない (または方法) 複数の同時リクエストを作成するために。 そのため、これらの巨大な技術会社は、は るかに多くのユーザーを持っている可能性がありますERDDAP™, しかし、彼らは、大規模なリソースと各ユーザーからの要求を制限するための賢明な方法を持っています. 大手IT企業の管理可能な状況です。 (そして、彼らは豊かさを得ます!) ではなく、ERDDAP™インストール。 再び、唯一の防衛のためのERDDAP™他のユーザーを不公平に混雑させる複数の同時リクエストを作るブラックリストユーザーです。
そのため、ユーザーは複数の同時リクエストを行わないか、ブラックリスト化されます。
明らかに、サーバーに多くのコア、たくさんのメモリがある場合、それは最善です (たくさんのメモリを割り当てるERDDAP™、それ以上必要性) 、および高い帯域幅インターネット接続。 すると、メモリは制限要因ではなく、ネットワークの帯域幅はより一般的な制限要因になります。 基本的には、複数の同時リクエストが複数あるため、指定したユーザのスピードが低下します。 各ユーザーが一度に1つのリクエストを提出すれば、そのリクエストの数が自然に遅くなります。
ERDDAP™THREDDSからデータを取得する
もし、ERDDAP™サイトのTHREDDSからデータの一部を取得するには、THREDDSのデータファイルのコピーを作成するいくつかの利点があります (最も人気のあるデータセットの少なくとも) 別の RAID についてERDDAP™アクセスができるようにERDDAP™直接ファイルからデータを配信できます。 お問い合わせERD一番人気のデータセットです。
- ERDDAP™データを直接取得し、データセットをリロードするためにTHREDDSを待つ必要はありません...
- ERDDAP™すぐに新しいデータファイルを通知し、組み込むことができるので、データセットが変更されたかどうかを確認するために頻繁にTHREDDSをpesterする必要はありません。 詳しくはこちら<更新EveryNMillis> (/docs/server-admin/データセット#updateeverynmillis) お問い合わせ
- 負荷は2つのRAIDSと2つのサーバー間で分割されます。ERDDAP™そしてTHREDDS。
- 小さなTHREDDSによる誤った問題を回避 (デフォルトで) 最高サイズ。要求ERDDAP™ミスマッチを処理するシステムを持っていますが、問題を回避することはより良いです。
- 常に良い考えであるデータのバックアップコピーがあります。
いずれの場合も、THREDDS を実行しなくなり、ERDDAP™同じTomcatで。 別のサーバーで別のTomcatsでそれらを実行するか、またはより良い。
THREDDSは定期的にリクエストがハングする状態にあることがわかります。 もし、ERDDAP™THREDDSとTHREDDSからのデータを取得しています。ERDDAP™防衛を持っている (THREDDSベースのデータセットは利用できません) 、しかしそれはまだ面倒ですERDDAP™なのでERDDAP™空腹のTHREDDSからデータセットをリロードしようとするたびにタイムアウトまで待つ必要があります。 グループ (含まれるものERD) THREDDSを頻繁に再起動することでこれを回避 (例: cron ジョブで一晩) お問い合わせ
スローリー対応
- お問い合わせERDDAP™反応が遅い または特定の要求がゆっくりと応答している場合、 遅さが合理的かつ一時的であるかどうかを把握することができます (例:スクリプトからのリクエストが多いためWMSユーザー) 、または何かが明示的に間違っている場合、Tomcatをシャットダウンして再起動し、Tomcatを再起動します。ERDDAP™お問い合わせ
お問い合わせERDDAP™ゆっくりと反応し、原因を判断するために、以下のアドバイスを参照してください。これにより、問題の修正が可能になります。 特定の開始点があるかもしれません (例: リクエスト URL) または漠然とした出発点 (例:ERDDAP™遅い) お問い合わせ ユーザーが関与しているユーザーを知ることができます (e.g. 彼らはあなたに電子メールを送ったので、) またはない。 他の手がかり、またはない場合があります。 これらすべての状況と問題の可能性のある原因がまとめられているので、以下のアドバイスは、可能な開始点と低応答に関連する可能性のある問題をすべて対処しようとします。
- キューを探しますERDDAP's ログファイル ( bigParentディレクトリ /logs/log.txtの一覧) お問い合わせ
\[まれな機会に、手がかりがありますTomcatのログファイル ( トームキャット /logs/catalina.outの特長) お問い合わせ\]
エラーメッセージを探す 複数のリクエストを1つから受け取る (または数) サーバのリソースの多くを占有するユーザーとおそらく (メモリ、CPU時間、ディスクアクセス、インタ ーネットの帯域幅) お問い合わせ
トラブルが結ばれた場合 1つのユーザー , ユーザがWebサービスを介している人について、よく知っていることができます。 https://whatismyipaddress.com/ip-lookup ユーザーの IP アドレスに関連する情報を与えることができます。 (あなたが見つけることができるものERDDAPお問い合わせログインファイル) お問い合わせ
- ユーザがいるように見える場合 ボット ふるい ひどく (残念ながら、検索エンジンは、ERDDAP™エントリの値のあらゆる可能な透過性を持つフォーム) サーバが適切に設定されていることを確認してくださいロボット.txtファイル。
- ユーザがいるように見える場合 **スクリプト (ツイート) ** 複数の同時リクエストを作ることで、ユーザに連絡し、それを説明ERDDAP™限られたリソース (例:メモリ、CPU時間、ディスクアクセス、インターネット帯域幅) 他の人のユーザーを考慮して、一度に1つのリクエストをするように依頼してください。 あなたはまた、彼らが戻っていない場合、それらをブラックリストすると言及するかもしれません.
- ユーザがいるように見える場合 スクリプト 複数の時間を費やすリクエストを数多く行なうため、小さな一時停止をすることによって、他のユーザーの考慮事項をユーザーに尋ねる (2秒?) リクエスト間のスクリプト。
- WMSクライアントソフトウェア 非常に要求することができます。 1つのクライアントは、多くの場合、6つのカスタム画像を一度に依頼します 。 ユーザがいるように見える場合WMS正当な要求を下すクライアント:
- それを無視します。 (おすすめは、近日はかなり移動するので)
- サーバーのオフWMSサービスERDDAP's setup.html ファイル。 (お勧めしない)
- リクエストが見える場合 stupid、インサイン、過度、または悪意のある、 または、他の方法で問題を解決できない場合は、ユーザーのIPアドレスを一時的にまたは永久に追加してください [<リクエストでブラックリスト>datasets.xmlファイル (/docs/server-admin/datasets#requestblacklist) お問い合わせ
- 自分のコンピュータから、自分自身の問題を解決してみてください。
問題が1つのデータセットまたはすべてのデータセット、1つのユーザーまたはすべてのユーザーの場合、特定のタイプのリクエストなどの場合に問題がないかを調べます。 問題の重複ができたら、問題を絞り込みます。 問題の重複ができない場合は、問題はユーザーのコンピューター、ユーザーのインターネット接続、または機関のインターネット接続に結びつくことがあります。 - ただ、 1つのデータセット ゆっくり反応する (多分だけのために 1つのタイプの要求 1つのユーザーから) 問題は:
- ERDDAPデータセットのソースデータへのアクセス (リレーショナル・データベース、Cassandra、リモート・データ・セットから) 一時的にまたは永久に遅くなる可能性があります。 ソースの速度を独立して確認してみてくださいERDDAPお問い合わせ 遅い場合、おそらくあなたはそれを向上させることができます。
- 特定の要求や一般的なタイプの要求に関連する問題はありますか? データセットの要求されたサブセットが大きいほど、リクエストが失敗する可能性が高い。 ユーザーが大規模なリクエストをしている場合, より小さいリクエストを作るためにユーザーに尋ねる より速く、成功した応答を得る可能性が高い.
ほとんどのデータセットは、他の種類のリクエストよりも、いくつかの種類のリクエストを処理することで優れています。 たとえば、データセットが異なるファイルで異なる時間チャンクを保存している場合、膨大な数の時間ポイントからのデータのリクエストは非常に遅くなる可能性があります。 現行のリクエストが困難なタイプの場合、これらのリクエストに最適化されたデータセットのバリエーションを提供することを検討してください。 または、リクエストの種類が難しく、時間がかかっていたり、忍耐を求めるユーザーに対して説明するだけです。
-
データセットは最適に設定されていない場合があります。 データセットの変更ができるようにするdatasets.xml助けるためにチャンクERDDAP™データセットをよりよく処理します。 例えば、
- EDDGridFromNcFiles は、圧縮された nc4/hdf5 ファイルからデータにアクセスするデータセットは、地理範囲全体のデータを取得する際に遅くなります。 (例えば、世界地図) ファイル全体が解凍される必要があるため。 ファイルを非圧縮ファイルに変換できますが、ディスクスペースの要件ははるかに大きくなります。 そのようなデータセットが特定の状況で遅くなるということを受け入れるのはおそらく良いでしょう。
- [設定]<subsetVariables>> (/docs/server-admin/datasets#subsetvariable) タグには巨大な影響がありますERDDAP™EDDTable データセットを処理します。
- 増加する可能性があります。EDDTableFromDatabase の速度データセット。
- 多くのEDDTableデータセットは、データのコピーを格納するNetCDF目立たせられた配列ファイル, ,ERDDAP™すぐに読むことができます。
特定のデータセットをスピードアップするのに役立つ場合は、問題の説明とデータセットのチャンクを含むdatasets.xmlお問い合わせ追加サポートを受けるセクションお問い合わせ
- お問い合わせ すべて お問い合わせERDDAP™お問い合わせ 常に 遅くなると、問題は次のようになります。
- 実行中のコンピューターERDDAP™十分な記憶力か処理力がないかもしれません。 走るのは良いERDDAP™モダンでマルチコアなサーバー 重い使用のために、サーバーは64ビットのオペレーティング システムおよび記憶の8 GB以上あるべきです。
- 実行中のコンピューターERDDAP™システムリソースの多くを消費している他のアプリケーションを実行することもできます。 もしそうなら、専用のサーバーを専用のサーバーで取得できます。ERDDAPお問い合わせ 例えば (これは、支持ではありません) , あなたはあなたのためにメモリの8 GBでクォードコアMacミニサーバーを得ることができます ~$1100.
- お問い合わせ すべて お問い合わせERDDAP™お問い合わせ 臨時休業 遅い, 見るERDDAPお問い合わせ /erddap/status.htmlサイトマップ お使いのブラウザで
- は、ERDDAP™ステータスページは読み込みに失敗しますか? お問い合わせリセットERDDAP™お問い合わせ
- は、ERDDAP™ステータスページの読み込みが遅い (例:>5秒) お問い合わせ つまり、すべてがすべてにあるというサインです。ERDDAP™ゆっくり走っていますが、必ずしも問題ではありません。ERDDAP™本当に忙しくなるかもしれません。
- 「応答障害時間」 (最後のメジャーな LoadDataset から) ",n= は、数が多い? 最近は失敗したリクエストがたくさんあることを示します。 トラブルやトラブルの開始など、 失敗のメディアンタイムはしばしば大きい (例:210000ms) , つまり、 (お問い合わせ) アクティブスレッドの多く。 たくさんのリソースを抱いた (メモリ、オープンファイル、オープンソケット、...) , それは良いではありません。
- 「応答時間について (最後のメジャーな LoadDataset から) ",n= は、数が多い? 最近は多くの成功した要求があることを示しています。 問題ありません。 あなただけの手段ERDDAP™重い使用を得ています。
- 「非対向スレッド数」は、典型的な値が2倍? これは、原因となる重大な問題ですERDDAP™遅くなり、最終的に凍結します。 時間の経過でこの主張者なら、積極的に参加したいリセットERDDAP™お問い合わせ
- 「メモリー使用サマリー」リストの一番下では、最後の「メモリー:現在使用している」値が非常に高くなっていますか? 高利用状況を示すか、トラブルの兆候である可能性があります。
- スレッドとそのステータス のリストをご覧ください。 何か異常なことをしているのは珍しい数ですか?
- お問い合わせ 機関のインターネット接続 現在遅いですか? 「インターネット速度テスト」のインターネットを検索し、次のような無料のオンラインテストのいずれかを使用します。 https://www.speakeasy.net/speedtest/ お問い合わせ 機関のインターネット接続が遅くなったら、その間の接続ERDDAP™リモートデータソースは遅くなり、その間の接続ERDDAP™ユーザは遅くなります。 時々、不要なインターネット利用を停止することで解決できます (たとえば、ストリーミングビデオやビデオ会議の電話を見ている人) お問い合わせ
- お問い合わせ ユーザーのインターネット接続 現在遅いですか? ユーザーが「インターネット速度テスト」のインターネットを検索し、次のような無料のオンラインテストのいずれかを使用します。 https://www.speakeasy.net/speedtest/ お問い合わせ ユーザーのインターネット接続が遅い場合、アクセスが遅くなります。ERDDAPお問い合わせ 時々、彼らは彼らの機関で不要なインターネットの使用を停止することにより、これを解決することができます (たとえば、ストリーミングビデオやビデオ会議の電話を見ている人) お問い合わせ
- スタック?
お問い合わせ追加サポートを受けるセクションお問い合わせ
シャットダウン と再起動
- Tomcatをシャットダウンして再起動する方法とERDDAP™
Tomcatをシャットダウンして再起動する必要はありません。ERDDAPお問い合わせERDDAP™一時的に遅い, いくつかの既知の理由のために遅い (スクリプトからのリクエストが多いか、WMSユーザー) 変更を加えるか、またはdatasets.xmlファイル。
Tomcatをシャットダウンして再起動する必要があります。ERDDAP™setup.xml ファイルに変更を加える必要がある場合や、ERDDAP™凍結、掛け金、ロックアップ。 極端な状況では、Javaそれは完全なゴミ収集を行う間、または2分の凍結することができます, しかし、回復. ですから、分か2を待つと良いです。Java/ / / /ERDDAP™本当に凍っているか、またはそれがちょうど長いゴミ収集をやっている場合。 (ゴミ収集が一般的な問題の場合、Tomcatにより多くのメモリを割り当てるお問い合わせ)
Tomcat Web Application Managerを使用してTomcatを起動またはシャットダウンすることをお勧めしません。 完全にシャットダウンして起動しないと、Tomcat が早く、または後で PermGen メモリの問題が発生します。
Tomcat をシャットダウンして再起動し、Tomcat を再起動し、Tomcat を再起動します。ERDDAP: : :
- Linux または Mac を使用する場合:
(Tomcatを実行する特別なユーザーを作成した場合は、Tomcat は、そのユーザーとして次の手順を実行してください。)
- cdを使う トームキャット /ビン
- ps -efを使う|java/tomcatプロセスを見つけるための grep tomcat パスワード (うまくいけば、1つのプロセスがリストされます) 呼び出しする javaProcessIDの使い方 お問い合わせ
- お問い合わせERDDAP™凍結/空/ロックアップ、キル-3を使用 javaProcessIDの使い方 お問い合わせJava (Tomcatを実行している) Tomcatログファイルにスレッドダンプを行うには: トームキャット /logs/catalina.out 。 再起動すると、スレッドダンプ情報を見つけることで問題の診断ができます (上記のその他の有用な情報) お問い合わせ トームキャット /logs/catalina.out と、関連する部分を読んでERDDAP™ログアーカイブお問い合わせ ご希望の場合は、その情報を含めることができます。追加サポートを受けるセクションお問い合わせ
- ./shutdown を使う。 ログイン
- ps -efを使う|java/tomcat プロセスがリストされていないまで、繰り返し tomcat を grep します。
時々、Java/tomcatプロセスは完全にシャットダウンするために最大2分かかります。 理由は:ERDDAP™バックグラウンドスレッドにメッセージを送信して、それらを停止するように指示しますが、時には、これらのスレッドは、良好な停止場所を得るために長い時間がかかります。
- 1分後にJava/tomcatが止まらないと、
キル -9 javaProcessIDの使い方
java/tomcat プロセスを強制してすぐに停止します。 可能であれば、最後のリゾートとしてのみ使用してください。 -9スイッチは強力ですが、様々な問題を引き起こす可能性があります。 - 再起動するERDDAP™./startup.sh を使う
- ニュースERDDAP™ブラウザでは、再起動が成功したことを確認します。 (時々、あなたは30秒待って、ロードしようとする必要がありますERDDAP™再びあなたのブラウザで成功する。)
- Windows を使用する場合:
- cdを使う トームキャット /ビン
- 使用条件shutdown.bat
- Windows のタスク マネージャーを使用するようにしたい/必要 (Ctrl Alt Del 経由でアクセス可能) それを確実にするためにJava/トムキャット/ERDDAP™プロセス/アプリケーションが完全に停止しました。 時々、プロセス/アプリケーションはシャットダウンするために最大2分かかります。 理由は:ERDDAP™バックグラウンドスレッドにメッセージを送信して、それらを停止するように指示しますが、時には、これらのスレッドは、良好な停止場所を得るために長い時間がかかります。
- 再起動するERDDAP™, start.bat を使う
- ニュースERDDAP™ブラウザでは、再起動が成功したことを確認します。 (時々、あなたは30秒待って、ロードしようとする必要がありますERDDAP™再びあなたのブラウザで成功する。)
頻繁なクラッシュまたは凍結
お問い合わせERDDAP™遅くなる, クラッシュや凍結, 何かが間違っている. お問い合わせERDDAP's ログファイル原因を把握しようとする。 ご希望の場合は、詳細をご記入の上、ご確認下さい 。追加サポートを受けるセクションお問い合わせ
最も一般的な問題は、一度に複数のスクリプトを実行している面倒なユーザーであり、/または複数の不正なリクエストを行なう人です。 これが起こると、おそらくそのユーザーをブラックリストにする必要があります。 blacklisted ユーザーがリクエストをすると、レスポンスのエラーメッセージは、問題の処理を促すように促します。 それから、一度に1つのスクリプトを実行し、スクリプトの問題を解決するためにそれらを奨励することができます (例えば、タイミングアウト前に応答できないリモートデータセットからデータを要求する) お問い合わせ 詳しくはこちら<リクエストでブラックリスト>datasets.xmlファイル (/docs/server-admin/datasets#requestblacklist) お問い合わせ
極端な状況では、Javaそれは完全なゴミ収集を行う間、または2分の凍結することができます, しかし、回復. ですから、分か2を待つと良いです。Java/ / / /ERDDAP™本当に凍っているか、またはそれがちょうど長いゴミ収集をやっている場合。 (ゴミ収集が一般的な問題の場合、Tomcatにより多くのメモリを割り当てるお問い合わせ)
お問い合わせERDDAP™遅くなるか、または凍結し、問題は面倒なユーザーや長いゴミ収集ではありません、あなたは通常、問題を解決することができます再起動ERDDAP™お問い合わせ 私の経験は、ERDDAP™再起動を必要とせずに数か月間実行できます。
モニター
監視できますERDDAP's ステータスを見る/erddap/status.htmlサイトマップ特にトップセクションの統計情報。 お問い合わせERDDAP™遅くなるか、または凍結し、問題はちょうど非常に重い使用法ではないです、通常問題を解決できます再起動ERDDAP™お問い合わせ /erddap/metrics で Prometheus のインテグレーションで使用できるメトリックが追加されています。
私の経験は、ERDDAP™再起動を必要とせずに数か月間実行できます。 変更を加える場合は、再起動する必要があります。ERDDAP's setup.xml または新しいバージョンをインストールする必要がある場合ERDDAP™,Java、 Tomcat、またはオペレーティングシステム。 再起動が必要な場合ERDDAP™頻繁に、何かが間違っています。 お問い合わせERDDAP's ログファイル原因を把握しようとする。 ご希望の場合は、詳細をご記入の上、ご確認下さい。追加サポートを受けるセクションお問い合わせ 一時的なソリューションとして、使用してみてくださいログイン監視するERDDAP™必要に応じて再起動します。 または、cronジョブを再起動させることもできます。ERDDAP™ (プロアクティブ) 定期的に。 監視と再起動を自動化するためにスクリプトを書くことは少し難しいかもしれませんERDDAPお問い合わせ 役立つヒント:
- Tomcat プロセスが grep で -c スイッチを使用してまだ実行されているかどうかのテストを簡素化できます。 ps -uの トームキャット ユーザー |grep -c javaの これにより、プロセスが停止したときに、tomcat プロセスがまだ生き残っている場合、または "0" に出力を削減します。
- あなたがgawkで良いなら、あなたは結果からprocessIDを抽出することができます ps -uの トームキャット ユーザー |grep java はスクリプトの他の行で processID を使用します。
Monit または cron ジョブを設定している場合は、詳細を共有できると便利です。追加サポートを受けるセクション共有できる場所
パーマジェン
繰り返し使用すると、Tomcat マネージャーをリロード (または停止および開始) ERDDAP™,ERDDAP™起動してJava.langをスローしても失敗するかもしれません。 OutOfMemoryError: PermGen(パームゲン) ソリューションは定期的に (毎回?) tomcatをシャットダウンして再起動し、ERDDAP™、ちょうどリロードの代りERDDAPお問い合わせ
\[更新: この問題は、非常に最小化または固定されたERDDAP™バージョン 1.24.\]
ログイン
- ログイン
お問い合わせERDDAP™何かが期待どおりに機能しない場合、起動しない、または、エラーと診断メッセージを見ることは非常に便利ですERDDAP™ログファイル。 - ログファイルは bigParentディレクトリ /logs/log.txtの一覧 ( bigParentディレクトリ で指定 されるセットアップ。xml) お問い合わせ ログがない場合。 txt ファイルまたはログの場合。 txt ファイルが再起動してから更新されていないERDDAP™, 見るTomcatログファイルエラーメッセージがあるかどうかを確認します。
- ログファイル内の診断メッセージの種類:
- 何かが間違っていたときに「エラー」という言葉が使われ、手順が完了しなかった。 エラーを取得するのは迷惑ですが、エラーは問題に対処するために強制します。 私たちの考え方は、エラーを投げる方が良いことです。ERDDAP™途中で、期待していなかった方法で作業する。
- 何かが間違っていたときに「警告」という言葉が使われますが、手順は完了できました。 これらはかなりまれです。
- その他は、単なる有益なメッセージです。 どの程度の情報が記録されているかを制御することができます。 [<ログレベル> (/docs/server-admin/datasets#loglevel ディレクティブ) datasets.xmlお問い合わせ
- データセットのリロードおよびユーザー応答は>10秒をとって終わります (首尾よくまたは不成功) "" とマークされている (>10代目) お問い合わせ したがって、このフレーズのlog.txtファイルを検索して、リロードやリクエストのリクエスト数が遅くなるデータセットを見つけることができます。 その後、log.txtファイルでデータセットの問題が何であるか、またはユーザーリクエストが誰であるかを確認することができます。 これらの遅いデータセットの読み込みとユーザのリクエストは、時に課税されますERDDAPお問い合わせ そのため、これらの要求につい ての詳細は、問題を特定し、解決するのに役立ちます。
- ディスクドライブのログファイルにかなり大きなチャンクで情報を書きます。 利点は、これは非常に効率的なことです。ERDDAP™ログファイルに書き込まれる情報待ちをブロックしません。 欠点は、次のチャンクが書かれているまでログがほぼ常に部分的なメッセージで終わることです。 最新情報を受け取る (瞬時に) 閲覧することでERDDAP's ステータスウェブページ https://your.domain.org/erddap/status.html (またはhttp://お問い合わせhttps機能しない) お問い合わせ
- log.txt ファイルが 20 MB になる場合、 ファイル名が変更されます。 txt.previous と新しい log.txt ファイルが作成されます。 ログファイルは蓄積しません。
setup.xml では、MegaBytes 内のログファイルに対して異なる最大サイズを指定できます。 最小許可は1です (メガバイト) お問い合わせ 最大許容値は2000 (メガバイト) お問い合わせ デフォルトは 20 です (メガバイト) お問い合わせ 例えば:
<logMaxSizeMB>20</logMaxSizeMB>
- 再起動するたびにERDDAP™, ERDDAP™log.txt と log のアーカイブコピーを作成します。 txt.previous ファイルの名前のタイムスタンプを持つファイル。 再起動前のトラブルが発生した場合は、トラブルが発生したかのように、これらのアーカイブされたファイルをクロースに分析するのに便利です。 必要がなくなった場合はアーカイブファイルを削除できます。
log.txt をパースする
ERDDAPログイン txtファイルは解析用に設計されていません (希望する情報を抽出する正規表現を作成することができるかもしれませんが) お問い合わせ 何かが間違っているときに何が起こっているのかを人間図を助けるように設計されています。 バグや問題報告を提出する際にERDDAP™開発者は、可能な場合は、問題のあるリクエストに関連するlog.txtファイルからすべての情報を含めてください。
効率の理由のため、ERDDAP™ログに情報を書き込むだけです。 情報の大部分が蓄積された後、txt。 ログにアクセスすると エラーが発生した直後には、エラーに関連する情報は、log.txt にはまだ書かれていな い可能性があります。 log.txt から最新の情報を完全に取得するには、ERDDAPお問い合わせstatus.html ページお問い合わせ いつかERDDAP™要求するプロセスは、すべての保留情報をlog.txtにフラッシュします。
お問い合わせERDDAP™利用状況の統計は、ご利用下さい。Apache および/または Tomcat のログファイル代わりにERDDAP's log.txt. 注意:ERDDAPお問い合わせstatus.html ページ (詳しくはこちら) そして、デイリーレポート (ニュース) 多数の使用統計量をあなたのために事前に計算しました。
Tomcatログ
お問い合わせERDDAP™エラーが初期に発生したため起動しませんERDDAP's スタートアップ、エラーメッセージが Tomcat のログファイルに表示されます。 ( トームキャット /logs/catalina. /ログ/カタリナ. 今日更新 .log または トームキャット /logs/catalina.outの特長) , ないERDDAP's log.txt ファイルお問い合わせ
利用統計: ログファイルから収集したい情報の大部分 (例:利用統計) Apache および/または Tomcat のログファイルを使用してください。 整形され、その種類の情報を持っています。 それらを分析するためのツールは、例えば、AWステータス,ElasticSearchのキバナとJ メター, しかし、あなたの目的のために右のツールを見つけるためにWebを検索.
ログファイルは、IPアドレスとしてユーザーを識別するだけです。 特定のIPアドレスに関連する情報を取得するウェブサイトがあります。トピックス, しかし、あなたは通常、ユーザーの名前を見つけることができません.
また、DHCPの特長, 特定のユーザーの IP アドレスは、異なる日に異なる場合があります, または異なるユーザーは、異なる時間に同じ IP アドレスを持つことができます.
代わりに、好きなものを使用できますGoogleアナリティクスお問い合わせ しかし、注意してください: Google Analytics などの外部サービスを使用する場合、Google があなたのサイト上で自分の活動に完全にアクセスできるようにすることで、ユーザーのプライバシーを上げています。 (その他?) あらゆる目的のために永遠にそして使用し続けることができます (おそらく技術的にないが、おそらく練習) お問い合わせ あなたのユーザーはこれに同意していないし、おそらく彼らがほとんどすべてのウェブサイトで追跡されている範囲を認識していないので、あなたのウェブサイト上で追跡されることに注意してください。 最近は、Web上で行うすべての人がこれらの大企業によって監視されていることを多くのユーザーが非常に懸念しています (Google、Facebookなど) そして、政府によっ て、この不当な侵入を彼らの生活に見つけます (1984年(昭和40年)) お問い合わせ これは、このような製品をインストールする多くのユーザーを駆動しましたプライバシー・バッジトラッキングを最小限にし、代替ブラウザを使用するTorブラウザ (または従来のブラウザで追跡をオフにする) , などの代替検索エンジンを使用するダックダックゴーお問い合わせ Google Analytics などのサービスを使用する場合は、少なくともその使用と結果を変更することにより、<標準プライバシーポリシー>タグERDDAPお問い合わせ \[トームキャット\]/webapps/erddap/WEB-INF/classes/gov/noa/pfel/erddap/util/messages.xml ファイル。
Eメールログ
- メールLogYEAR-MM-DD.txt
ERDDAP™現在の日の電子メールですべての発信メールメッセージのテキストを常に書きます LogYEAR-MM-DD.txt ファイル bigParentディレクトリ /ログ ( bigParentディレクトリ で指定されるセットアップ。xml) お問い合わせ - サーバがメールメッセージを送信できない場合、または設定した場合ERDDAP™電子メールメッセージを送信したり、気に入ったら、このファイルは送信されたすべてのメールメッセージを表示する便利な方法です。
- 必要がなくなった場合は、以前の日のメールログファイルを削除できます。
デイリーレポート
デイリーレポートにはたくさんの有用な情報があります - あなたのすべての情報からERDDAPお問い合わせ/erddap/status.htmlサイトマップお問い合わせ
- それはあなたの最も完全な要約ですERDDAP's ステータス。
- 他の統計では、ロードされていないデータセットや生成された例外のリストが含まれています。
- 起動時に生成されますERDDAP™ (あとすぐERDDAP™すべてのデータセットをロードしようとする終了) 毎日午前7時以降に現地時間が発生しました。
- 生成されるたびに、ERDDAP's log.txt ファイルお問い合わせ
- 生成されるたびに、メールが送信されます。<電子メールDailyReportsTo> および<メール お知らせ (で指定されるセットアップ。xml) メールシステムの設定 (で setup.xml) お問い合わせ
ステータスページ
ステータスを表示できますERDDAP™どのブラウザからも<ベースUrl>/erddap/status.html
- このページは動的に生成されます。そのため、常に最新の統計データが作成されます。ERDDAPお問い合わせ
- リクエスト数、メモリ使用量、スレッドスタックトレース、タスクスレッドなど に関する統計が含まれます。
- ステータスページは誰からでも閲覧できるため、できるだけ多くの情報が含まれていません。デイリーレポートお問い合わせ
データセットの追加/変更
ERDDAP™通常は読み直しますdatasets.xmlすべて loadDatasetsMinutes ディレクティブ (で指定されるセットアップ。xml) お問い合わせ そのため、変更を加えることができますdatasets.xmlいつでも、ERDDAP™実行中です。 新しいデータセットは、通常、すぐに検出されます loadDatasetsMinutes ディレクティブ お問い合わせ 変更したデータセットが再読み込みされます。 リロードEveryNMinutes 古い投稿 (で指定されるdatasets.xml) お問い合わせ
ログイン
-
フラグファイルお問い合わせERDDAP™できるだけ早くデータセットをリロードしようとする
-
ERDDAP™データセットのセットアップの変更に気付くことはありませんdatasets.xmlまでERDDAP™データセットをリロードします。
-
お問い合わせERDDAP™データセットをできるだけ早くリロードする(データセットの場合)<reloadEveryNMinutes> はそれをリロードされるように引き起こします)、ファイルに置きます bigParentディレ クトリ /フラグ ( bigParentディレクトリ で指定されるセットアップ。xml) データセットと同じ名前を持つことdatasetIDお問い合わせ これは、ERDDAP™データセットASAPを再ロードしようとする。 以前のバージョンのデータセットは、新しいバージョンが利用可能であり、原子を所定の位置にスワップされるまで、ユーザーにご利用いただけます。 お問い合わせEDDGridファイルとEDDTable FromFiles では、リロードしたデータセットは、新しいファイルや変更されたファイルを探し出し、それらを読み込み、データセットに組み込むことができます。 そのため、リロードする時間は、新しいファイルや変更されたファイルの数に依存します。 データセットがactive="false" の場合、ERDDAP™データセットを削除します。
悪いファイルフラグ
-
/flagディレクトリの1つのバリアントは/badFilesFlagディレクトリです。 (追加されたERDDAP™v2.12.)
ファイルにファイルを置く場合 bigParentディレクトリ /badFilesFlag ディレクトリーdatasetIDファイル名として (ファイルの内容は問題ありません) すぐに、ERDDAP™badFiles を参照 旗ファイル,ERDDAP™予定:- BadFilesFlagファイルを削除します。
- BadFilesを削除する.ncファイル (1つある場合) , そのデータセットの悪いファイルのリストを持っています。. のようなデータセットのためEDDGridSideBySide は子データセットを持っているので、これも悪いファイルを削除します。.ncすべての子のデータセットのファイル。
- データセットASAPをリロードします。
したがって、この原因はERDDAP™以前にファイルを扱うために再び試みる (本当に?) 悪いとマークされる。
堅い旗
-
/flag ディレクトリの別の variant は /hardFlag ディレクトリです。 (追加されたERDDAP™v1.74.)
ファイルにファイルを置く場合 bigParentディレクトリ /hardFlag と adatasetIDファイル名として (ファイルの内容は問題ありません) すぐに、ERDDAP™硬いものを見る 旗ファイル,ERDDAP™予定:- hardFlagファイルを削除します。
- データセットを削除ERDDAPお問い合わせ
- 情報をすべて削除するERDDAP™このデータセットについて保存しました。 お問い合わせEDDGridファイルとEDDTable FromFiles サブクラスは、データファイルの内部データベースとその内容を削除します。 のようなデータセットのためEDDGridSideBySide は、子データセットを持つデータファイルの内部データベースと、すべての子データセットのコンテンツも削除します。
- データセットをリロードします。 お問い合わせEDDGridファイルとEDDTable FromFiles サブクラス、この原因ERDDAP™再読まれるため すべて データファイルの そのため、データセット内のデータファイルの総数に依存します。 データセットが削除されたためERDDAP™HardFlag が通知されたとき、データセットがリロードされるまでデータセットは利用できなくなります。 患者になる。 お問い合わせログイン何が起こっているかを見たい場合は、ファイル。
HardFlag バリアントは、データセットが現在ロードされていない場合でも、データセットの保存情報を削除します。ERDDAPお問い合わせ
ハード どのように変化を引き起こす何かを行うとき、フラグは非常に便利ですERDDAP™ソースデータを読み込み、解釈します。例えば、新しいバージョンをインストールしたときにERDDAP™またはデータセットの定義に変更があった場合datasets.xml
- フラグ、悪いFilesFlag、およびhardFlagファイルの内容は、関連性がありません。ERDDAP™ファイル名を見て、datasetIDお問い合わせ
- 主要なデータセットのリロード間のERDDAP™フラグ、悪いFilesFlag、およびhardFlagファイルを継続的に参照してください。
- データセットがリロードされる場合、すべてのファイル bigParentディレクトリ / / / /キャッシュ/ / / / datasetID ディレクトリは削除されます。 含まれるもの.nc普通に~15分キャッシュされるイメージファイル。
- dataset の xml が含まれている場合に注意して下さいアクティブ="false"フラグは、データセットが非アクティブにされるようにします。 (それがアクティブである場合) いかなる場合もリロードされません。
- 任意の時間ERDDAP™メジャーリロードを行うためにLoadDatasetを実行します(制御されたタイムドリロード<loadDatasetsMinutes> またはマイナーリロード (外部または内部フラグの結果として) ,ERDDAP™全てを読む<decompressedCacheMaxGB>,<decompressedCacheMaxMinutesOld>,<ユーザー><リクエストブラックリスト><スローダウンTroubleMillis>、および<サブスクリプションメールブラックリスト> タグと新しい設定に切り替えます。 そのため、取得方法としてフラグを使うことができます。ERDDAP™それらのタグを ASAP に変更することに注意してください。
データセットフラグを設定する
-
ERDDAP™URL を介してフラグを設定できるように、Web サービスがあります。
- 例えば、
https://coastwatch.pfeg.noaa.gov/erddap/setDatasetFlag.txt?datasetID=rPmelTao&flagKey=123456789
(偽のフラグ キーキー) rPmelTao データセットのフラグを設定します。 - それぞれに異なるフラッグキーがありますdatasetIDお問い合わせ
- 管理者は、すべてのデータセットのフラグ URL の一覧を、自分の下部を見ることで確認できます。デイリーレポートメールアドレス
- 管理者は、これらの URL を機密として扱う必要があります。なぜなら、誰かがデータをリセットする権利を与えられたからです。
- フラグキーがそれらを乱用している人の手に落ちていると思うなら、変更することができます<flagKey> でセットアップ。xml再起動ERDDAP強制するERDDAP™flagKey の異なるセットを生成し、使用 する。
- 変更する場合<flagKey> は、古いサブスクリプションをすべて削除します。 (デイリーレポートの一覧を見る) 新しい URL を新しい URL に送信してほしい人へ送信してください。
- 例えば、
https://coastwatch.pfeg.noaa.gov/erddap/setDatasetFlag.txt?datasetID=rPmelTao&flagKey=123456789
フラグシステムは、指示のためのより効率的なメカニズムに基づいて機能することができますERDDAP™データセットをリロードするとき。 たとえば、データセットの<reloadEveryNMinutes> 数が多い (例:10080 = 1週間) お問い合わせ 次に、データセットが変更されたことを知っているとき (おそらく、データセットのデータディレクトリにファイルを追加したからです) フラグを設定して、データセットができるだけ早くリロードされるようにします。 旗は通常すぐに見られます。 ただし、LoadDatasets スレッドが既に忙しくなれば、フラグ上で動作する機能が利用できるのはしばらく前になります。 しかし、フラグシステムは、設定よりもはるかに応答性とはるかに効率的です<reloadEveryNMinutes> を小数に。
データセットの削除
データセットが有効である場合ERDDAP™一時的にまたは永続的に無効にしたい。
- インスタグラムdatasets.xmlデータセットの場合、セットアクティブ="false"データセットタグ
- 待ち合わせERDDAP™次のメジャーリロード時にデータセットを削除するフラグを設定するデータセットについてERDDAP™変更をできるだけ早く通知します。 これを行 うと、ERDDAP™データセットについて保存した可能性のある情報を捨てず、実際のデータには何もしません。
- 次に、アクティブ="false" のデータを保存することができます。datasets.xmlまたはそれを削除します。
データセットがリロードされるとき?
RunLoadDatasets と呼ばれるスレッドは、データセットがリロードされるときに制御するマスタースレッドです。 ランロード データセットは永遠にループします:
-
RunLoadDatasets は、現在の時刻をメモします。
-
RunLoadDatasets は「majorLoad」を行うために LoadDatasets スレッドを開始します。 現在の/前のメジャーロードに関する情報を、あなたの一番上に表示することができますERDDAPお問い合わせ /erddap/status.htmlサイトマップ (例えば、ステータスページ例) お問い合わせ
- LoadDatasets はコピーを作成します。datasets.xmlお問い合わせ
- LoadDatasets はコピーを通して読みますdatasets.xmlデータセットごとに、データセットが必要となるかどうかを確認します。 (リリース) ロードまたは削除。
- お問い合わせログインファイルがこのデータセットに存在し、ファイルが削除され、アクティブ="false" または (リリース) アクティブ="true" の場合読み込み (データセットの年齢に 関係なく) お問い合わせ
- dataset の dataset.xml chunk が Active="false" を持ち、現在データセットがロードされている場合 (アクティブ) 、それは荷を下されます (削除) お問い合わせ
- データセットがactive="true" を持ち、データセットが既にロードされていない場合、ロードされます。
- データセットがactive="true" を持ち、データセットが既に読み込まれている場合は、データセットの年齢であればデータセットがリロードされます。 (最後の負荷以来の時間) それよりも大きい<リロード 毎分> (デフォルト = 10080 分) つまり、データセットは単独で残っています。
- LoadDatasets は終了します。
RunLoadDatasets スレッドは、LoadDatasets スレッドが終了するのを待ちます。 LoadDatasets が loadDatasets よりも長い場合 分光器 (setup.xml で指定された) , RunLoadDatasets は LoadDatasets スレッドを中断します。 理想的には、LoadDatasets は、中断と終了を通知します。 しかし、1分以内に割込みに気付かないと、RunLoadDatasets は loadDatasets を呼び出します。 ストップ () , 望ましくない. 3. 最後のメジャーの開始以来の時間は loadDatasets よりも少ない 分光器 (set.xml で指定されると、例えば 15 分) , RunLoadDatasets は繰り返し参照しますログインファイル内のファイル bigParentディレクトリ /flagディレクトリ。 1 つ以上のフラグファイルが見つかった場合、それらは削除され、RunLoadDatasets は「minorLoad」を行うために LoadDatasets スレッドを開始します。 (メジャーロード=false) お問い合わせ あなたのマイナーロード情報を見ることができませんERDDAPお問い合わせ/erddap/status.htmlサイトマップお問い合わせ
- LoadDatasets はコピーを作成します。datasets.xmlお問い合わせ
- LoadDatasets はコピーを通して読みますdatasets.xmlフラグファイルがある各データセットの場合:
- dataset の dataset.xml chunk が Active="false" を持ち、現在データセットがロードされている場合 (アクティブ) 、それは荷を下されます (削除) お問い合わせ
- データセットがactive="true"の場合、データセットは (リリース) 年齢を問わず、積み込み 非強化されたデータセットは無視されます。
- LoadDatasets は終了します。
- ランロード データセットはステップ1に戻ります。
注意:
-
スタートアップ 再起動するときERDDAP™, アクティブ="true" の全てのデータセットがロードされます。
-
キャッシュ データセットが (リリース) 読み込み、キャッシュ (データ応答ファイルおよび/またはイメージファイルを含む) お問い合わせ
-
大量のデータセット 大量のデータセットと/または複数のデータセットが遅い場合 (リリース) load は、loadDatasets スレッドは、ロードデータセットよりも長い期間かかることがあります。 最小限。
-
1つのLoadDatasetsの糸 LoadDatasets スレッドが一度に実行されることはありません。 LoadDatasetsが既に稼働しているときにフラグが設定されている場合、そのLoadDatasetsスレッドが実行を終了するまで、フラグは通知または動作しません。 と言うかもしれません: 「それは運命です。 データセットをロードする新しいスレッドの束を開始しないのはなぜですか? しかし、1つのリモートサーバから データを取得するデータセットが多い場合、1つのLoadDatasetsスレッドでもリモートサーバーに大きなストレスがかかっています。 1つのRAID上のファイルからデータを取得する多くのデータセットを持っている場合は、同じです。 複数の LoadDatasets スレッドを持つことから、急速に減少しています。
-
フラグ = ASAP フラグを設定すると、データセットがすべき信号だけ (リリース) できるだけ早く読み込まれる、必ずしもすぐにではありません。 LoadDatasets スレッドが現在実行されていない場合、データセットは数秒以内にリロードされます。 ただし、LoadDatasets スレッドが現在稼働している場合、そのロードデータセットスレッドが終了するまで、データセットは再ロードされません。
-
削除されたフラグ ファイル 一般的には、フラグファイルを置くと bigParentディレクトリ /erddap/flagディレクトリ (データセットのフラグにアクセスすることで そこに実際のファイルを置くか、または) 、そのフラグファイルが削除された直後に、データセットは通常非常に再読み込みされます。
-
旗versusの小さいreload 毎分 データセットがリロードされる必要がある場合と、便利な場合、データセットが常に最新であることを確認するための最良の方法は、リロードを設定することです 毎分数が多い (10080 か。) フラグを設定 (スクリプトを使って?) 再読み込みが必要な時。 つまり、そのシステムであるEDDGridFromErddap と EDDTableFromErddap は、データセットがリロードする必要があるメッセージを受信します。
-
log.txt を見る 関連する情報の多くは、 bigParentディレクトリ /logs/log.txt ファイル 期待どおりに機能しない場合は、ログを見てください。 txtを使用すると、問題の診断を正確に見つけ出すことができますERDDAP™行なった。
-
メジャーな LoadDataset スレッドの開始時に "majorLoad=true" を検索します。
-
マイナーな LoadDatasets スレッドの開始時に "majorLoad=false" を検索します。
-
特定のデータセットの検索datasetID情報について (リリース) ロードまたはクライド。
-
キャッシュされた応答
一般的には、ERDDAP™キャッシュしない (ショップ) ユーザーのリクエストに対する応答。 合理的は、ほとんどの要求が若干異なるため、キャッシュは非常に効果的ではありませんでした。 最大の例外はイメージファイルへのリクエストです (ブラウザやプログラムなどからキャッシュされるGoogle Earth多くの場合、再要求画像) リクエスト.ncファイル (彼らがオンザフライを作成できないので) お問い合わせERDDAP™各データセットのキャッシュされたファイルを別のディレクトリに保存します。 bigParentディレクトリ /キャッシュ/ datasetID 単一のキャッシュディレクトリには、アクセスが遅くなる可能性があるファイルがたくさんあります。 ファイルが3つの理由からキャッシュから削除されます。
- このキャッシュのすべてのファイルが削除されますERDDAP™再起動します。
- 定期的に、ファイル以上<cacheMinutes> 古い (で指定されるセットアップ。xml) 削除されます。 年齢に基づいてキャッシュ内のファイルを削除する (最近使用されていない) ファイルがキャッシュに長期滞在しないことを確認してください。 リクエストが常に同じ応答を返すように見えるかもしれませんが、それは本当ではありません。 例えば、tabledap&timeリクエストを含む> 詳しくはこちら タイムタイム データセットに新しいデータが到着すると変更されます。 そして含まれているgriddapの要求\[最後の投稿\]データセットに新しいデータが届くと、時間次元が変化します。
- エラー条件を示す画像はキャッシュされますが、数分間のみ (難しい状況です) お問い合わせ
- データセットがリロードされるたびに、そのデータセットのキャッシュのすべてのファイルが削除されます。 リクエストは、"last"グリッドされたデータセット内のインデックス、データセットがリロードされるとキャッシュ内のファイルが無効になる場合があります。
保存データセット情報
すべてのタイプのデータセットのため、ERDDAP™データセットがロードされ、メモリに保管されると、多くの情報を収集します。 これは、ERDDAP™データの検索、データセットの一覧のリクエスト、データセットに関する情報のリクエストに素早く対応できます。
いくつかの種類のデータセットの場合 (お知らせEDDGridコピー、EDDTableCopy、EDDGrid詳しくはこちら ログイン ファイルとEDDTableFrom ログイン ファイル) ,ERDDAP™データセットがリロードされるときに再利用されるデータセットに関する情報をディスクに保存します。 再読み込みプロセスを非常に高速化します。
- データセット情報ファイルの一部は、人間が読める.jsonファイルが保存され、 bigParentディレクトリ /データセット/ last2LettersOfデータセットID/datasetID お問い合わせ
- ERDDAP™これらのファイルを異常な状況で削除するだけです。例えば、データセットの変数を追加または削除する場合datasets.xmlチャンク。
- データセットのほとんどの変更datasets.xmlチャンク (e.g.、グローバル属性や変数属性の変更) これらのファイルを削除する必要はありません。 通常のデータセットリロードは、これらの種類の変更を処理する。 教えてくださいERDDAP™設定でデータセットASAPを再ロードするログインデータセットの場合。
- 同様に、データファイルの追加、削除、または変更が処理されます。ERDDAP™データセットをリロードします。 しかし、ERDDAP™データセットが[]を使用している場合は、このタイプの変更がすぐに自動的に通知されます。<更新EveryNMillis> (/docs/server-admin/データセット#updateeverynmillis) システム。
- これらのファイルを削除するには、必要なくありません。 あなたが強制する必要がある最も一般的な状況ERDDAP™保存された情報を削除する (最新/非正確で、自動で固定されないためERDDAP) データセットの変更を行うときdatasets.xmlどのように影響するチャンクERDDAP™ソースデータファイル内のデータを解釈します。例えば、 時間変数の形式の文字列を変更します。
- データセットの保存した情報ファイルを削除するERDDAP™実行中 (データセットが現在ロードされていない場合でも) , 設定するハード ログインそのデータセットのため。 データセットが多数のファイルの集計である場合、データセットを再読み込みするとかなりの時間がかかります。
- データセットの保存した情報ファイルを削除するERDDAP™実行しない, 実行ダスDdsデータセット (どのディレクトリに情報が配置され、手動でファイルを削除するよりも簡単です) お問い合わせ データセットが多数のファイルの集計である場合、データセットを再読み込みするとかなりの時間がかかります。
記憶状態
ERDDAP™クラッシュしたり、フリーズしたりしないでください。 それがなければ、最も可能性が高い原因の1つは不十分な記憶です。 のような行を含むstatus.htmlウェブページを見て、メモリの使用状況を監視できます。
0 gc 呼び出し、0 リクエスト shed、0 危険 過去の主要なLoadDatasets以来の MemoryEmails
(深刻なイベントが進行中)
統計表のMB inUse と gc カラムを呼び出します。 メモリストレスが発生した方法を教えてください。ERDDAP™数字を見ることで、 より高い数字は、より多くのストレスを示しています。
- MB の inUse は常に半分以下でなければなりません\-Xmxメモリ設定お問い合わせ 数字が大きいのは悪い記号です。
- gc 呼び出しは回数を表しますERDDAP™高メモリ使用量を緩和しようとするゴミ収集器と呼ばれる。 これが>100になると、深刻なトラブルの兆候です。
- shed は、ハッシュされたリクエストの数を示します。 (HTTP エラー番号 503 で、サービス利用不可) メモリ使用量が高すぎるため。 理想的には、要求は取り除くべきではないです。 少数の要求が小屋なら大丈夫ですが、多くが小屋なら深刻な悩みの印です。
- 危険性 MemoryEmail - メモリ使用が危険に高い場合、ERDDAP™記載されているメールアドレス宛に電子メールを送信<メール お知らせ (で setup.xml) アクティブなユーザーリクエストのリストで。 Eメールが言うと、これらのメールをChrisに転送してください。 ノアのヨハネ。 gov では、将来のバージョンを改善するために情報を使用できるので、ERDDAPお問い合わせ
もし、ERDDAP™メモリストレス:
- サーバのメモリの多くを割り当てることを考慮するERDDAP™Tomcatの変更により‐Xmxメモリの設定お問い合わせ
- すでに多くのメモリを割り当てられた場合ERDDAP™-Xmx 経由で, お使いのサーバーのより多くのメモリを購入検討. 記憶は安いです (新規サーバーや時間の価格と比較して) お問い合わせ すると -Xmx が増加します。
- インスタグラムdatasets.xml, セット<nGridThreads> 1セット<nTableThreads> から 1、およびセット<ipAddressMaxRequestsActive> から 1.
- log.txt のリクエストを非効率的で面倒なものにします。 (しかし、正当な) リクエスト IPアドレスを追加する<リクエストブラックリスト> お問い合わせdatasets.xmlお問い合わせ blacklist エラーメッセージには、ERDDAP™管理者のメールアドレスは、ユーザーがあなたに連絡して、それらを使用して作業できるように希望しますERDDAP™より効率的に。 それはあなたがブラックリストと理由のIPアドレスのリストを維持するのは良いです, 彼らがあなたに連絡する場合、ユーザーが操作できるように.
- 悪意のあるユーザーからのリクエストについては、log.txt のリクエストを参照してください。 IPアドレスを追加する<リクエストブラックリスト> お問い合わせdatasets.xmlお問い合わせ 同様の要求が複数の類似のIPアドレスから来ている場合は、いくつかの who-is サービスを使うことができます。 (例: https://www.whois.com/whois/ ) そのソースからIPアドレスの範囲を見つけ、範囲全体をブラックリストします。 [を見る]<ブラックリスト> ドキュメントリクエスト (/docs/server-admin/datasets#requestblacklist) お問い合わせ
OutOfメモエラー
セットアップするときERDDAP™メモリの最大量を指定するJavaで使用することができます\-Xmxの設定お問い合わせ お問い合わせERDDAP™それよりも多くのメモリが必要です。Javaをスローします。 ログイン OutOfMemoryError エラーERDDAP™十分にチェックして、そのエラーをうまく処理できるようにします (例えば、面倒なリクエストは失敗しますが、システムがその完全性を保持します。) お問い合わせ しかし、時々、エラーはシステムの完全性を損傷し、再起動する必要がありますERDDAPお問い合わせ うまくいけば、それはまれです。
OutOfMemoryError への迅速かつ簡単なソリューションは、\-Xmxの設定, しかし、サーバー内の物理メモリの80%以上に -Xmx の設定を増加させてはならない (例えば、10GBサーバーの場合は、8GB以上のXmxを設定しないでください。) お問い合わせ メモリは比較的安いので、サーバーのメモリを増加させるのに良い選択肢かもしれません。 しかし、サーバー内のメモリを最大化したり、他の理由でそれを増やすことができない場合は、OutOfMemoryError の原因を直接対処する必要があります。
あなたが見るとログインファイルの一覧ERDDAP™エラーが発生したときには、OutOfMemoryError の原因として、通常は良い手掛かりを得ることができます。 以下のような原因があります。
- 単一の巨大なデータファイルが OutOfMemoryError を引き起こします。特に、巨大な ASCII データファイルです。 これが問題であるならば、それは明らかであるべきですERDDAP™データセットをロードできません (表形式のデータセットの場合) またはそのファイルからデータを読み込む (グリッドデータセット用) お問い合わせ feasible なら、ファイルを複数のファイルに分割することです。 理想的には、ファイルを論理チャンクに分割できます。 たとえば、ファイルに20か月分のデータが含まれている場合は、1か月分のデータをそれぞれ20ファイルに分割します。 しかし、メインファイルが任意に分割されている場合でも利点があります。 このアプローチには複数の利点があります: a) データファイルを1/20に読み込むために必要なメモリを1つだけ減らします。 b) しばしば,ERDDAP™特定のリクエストのデータを見つけるために1つまたは少数のファイルを見る必要があるため、リクエストをはるかに迅速に対処できます。 c) データの収集が進行中の場合、既存の20ファイルが変更されていないままになり、データセットに次の月の値を追加するには、1つの小さな新しいファイルだけを変更する必要があります。
- 単一の巨大なリクエストは、OutOfMemoryError を引き起こす可能性があります。 特に、一部orderByオプションには、メモリ全体での応答が秒単位である (例えば、ソートを行う) お問い合わせ 応答が大きければエラーにつながることができます。 様々な方法で、大きすぎるリクエストが常にあります。 -Xmxの設定を増加させることで問題を解決できます。 あるいは、より小さいリクエストのシリーズを作ることをユーザーに奨励することができます。
- 大量のファイルがファイルの原因となるのは違います。ERDDAP™ファイルがエラーを引き起こしてしまうほど大きいように作成します。 各ファイルが300バイトを使用している場合、1,000,000ファイルは300MBしかかかりません。 しかし、膨大な数のデータファイルを持つデータセットは、他の問題を引き起こしますERDDAP当然のことながら、長い間かかりますERDDAP™ユーザーの要求に応じ、データに対するすべてのデータファイルを開きます。 この場合、データファイルが少ないため、解決策はファイルを集計する場合があります。 表形式のデータセット の場合、現在のデータセットからデータを保存する場合、多くの場合は素晴らしいです。CFシリーズ 分離されたサンプリングの幾何学 (DSGについて) 曖昧なレイジデータファイル (リクエスト.ncCFファイルからERDDAP) 新しいデータセットを作成します。 これらのファイルは、非常に効率的に処理することができますERDDAPお問い合わせEDDTableFromNcCFファイルお問い合わせ 論理的に整理されている場合 (スペースと時間のチャンクのためのデータとそれぞれ) ,ERDDAP™データを素早く抽出することができます。
- を使用する集計データセット<subsetVariables>> (/docs/server-admin/datasets#subsetvariable) 属性,ERDDAP™これらの変数の値のユニークな組み合わせの表を作成します。 巨大なデータセットまたはいつ<subsetVariables> は誤って構成されており、このテーブルは OutOfMemoryErrors を引き起こすのに十分な大きさです。 解決策は、変数をリストから削除することです。<subsetVariables> 多数の値がある場合、またはそのテーブルのサイズが妥当であるまで必要に応じて変数を削除してください。 パーツのERDDAP™それを使うsubsetVariablesシステムがうまく機能しない (e.g.、Webページは非常にゆっくりと読み込みます) そのテーブルに100,000行以上あるとき。
- 複数の同時リクエストの同時リクエストが常に可能 (本当に忙しいERDDAP) メモリトラブルを引き起こすために組み合わせることができます。 たと えば、それぞれ1GBを使用して8つのリクエストは、-Xmx=8GBのセットアップに問題を引き起こします。 しかし、それぞれのリクエストが同時に使用するメモリのピークにあることは稀です。 見やすくなるでしょう。ERDDAP™大きなリクエストで本当に忙しいです。 でも可能です。 -Xmx の設定を増やすことで、この問題に対処するのは困難です。
- 他のシナリオがあります。 見てみるとログインファイルの一覧ERDDAP™エラーが発生したとき、通常、原因として良い手掛かりを得ることができます。 ほとんどの場合、その問題を最小限に抑える方法があります (詳しくはこちら) , しかし、時には、より多くのメモリとより高い-Xmx設定が必要です.
あまりにも多くのファイルを開く
まずはERDDAP™v2.12,ERDDAP™開いたファイルの数を監視するシステムがあります (ソケットとその他のものを含むファイルだけでなく、) Linux コンピューターの Tomcat にインストールします。 ファイルが誤って閉じられない場合 (「リソースリーク」) , 開いているファイルの数は、オペレーティングシステムによって許可される最大を超え、多くの本当に悪いことが起こるまで増加する可能性があります。. 今、Linuxコンピュータで (Windowsで情報が利用できないので) : : :
- status.html の Web ページの右端にある「ファイルを開く」列で、最大ファイルの割合が開きます。 Windowsでは、「?」と表示します。