私たちのプロジェクトが1時間半続いた経緯と、理由を見つけた経験を共有したいと思います。
ある時点で、サイトの一部が15分の遅延でロードされ、他の部分が単に機能せず、504エラーが発生することを理解しています。
注意！ 人々は頭が良く、読むのが好きではないので、ここに書いています。 投稿の目的は、緊急事態から抜け出す方法を提案することです。他のすべては単なる歌詞であり、何らかの理由で誰もが注目を集めています。
私はCouchDBをデータベースとして使用するプロジェクトに従事しています。 イベントを追加できる「ポスター」セクションがあります。特に、期間の開始日と終了日を設定して定期的なイベントを追加できます。
イベントを追加すると、データベースにイベントドキュメントが作成され、期間の各日ごとに個別のフィールドに時間間隔が追加されます。 これらの間隔で、サイトでの出力用に選択が行われます。 実際、選択はすべてのドキュメントから時間間隔を選択するだけです。
したがって、7日間のイベントを追加すると、期間フィールドに7つのレコードがあり、7つのレコードが表示されるドキュメントが取得されます。
失敗する
イベントの最大期間のサーバーでのチェックはありませんでした。 何らかの理由で、彼らはこれを提供しませんでした。おそらく、有料アカウントを持つユーザーのみがイベントを追加し、意識する必要があることを望んでいます。汚れたユーザー
ユーザーは有料アカウントで表示され、甘やかすために、イベントを追加し、イベントの終了日が2100であることを示します。Php-fpmはサーバー上で強力に動作し始め、365 * 100イベントの追加を開始します。 彼は何かを追加しましたが、ユーザーは追加の成功に関するメッセージを待たず、おそらく何かがバグであるかインターネットが落ちたと判断し、イベントの追加を再度クリックして、イベントの時間を少し変更しました。 プロセスは2回目に開始されました。 php-fpmが深刻な負荷を与えたわけではありませんが、サーバーのtopコマンドには通常より多くのphp-fpmプロセスがあり、混乱を招き、しばらくの間間違った方向に考えました。
その結果、データベースにはそれぞれ365 * 100の時間間隔で2つのドキュメントがあります。 CouchDBは、提供していない外観の更新を開始します。
サーバーログには、次のようなものがあります。
[<0.738.0>] Exit from linked
pid: {<0.742.0>,
{timeout,
{gen_server,call,
[couch_query_servers,
{get_proc,<<"javascript">>}]}}}
Futonにデータベースを入力しようとすると、os_process_errorエラーが表示されます。 Futonの[ステータス]セクションには、イベントデータベースにあることを記した消えない碑文があります（1行目を参照）。
何かがバグであるか、データベースが破損しているという考えがありましたが、サービスcouchdbの再起動は役に立たず、サーバー上のデータベースを別のサーバー上のレプリケーションからの最新のコピーに置き換えました。
グーグル検索後、CouchDBメーリングリストアーカイブで解決策が見つかりました-データベースはos_process_timeout = 5000（5秒）の更新を検出しました。 ビューには、割り当てられた時間内にドキュメントを処理する時間がありませんでした。 configの値を15秒に増やすことで、最終的に変更の適用を達成でき、サイトは正常に機能し始めました。
サイトが単にロードされなかった理由に対処し、504エラーを出してデータベースを整理した後、スクリプトが最終的に復元され、これが再び発生しないように対策が講じられました。
ちなみに、データベースに作成された2つのドキュメントを、すぐに記述されたスクリプトを使用して削除する必要がありました。 ブラウザーは単にドキュメントを布団で開くことを拒否し、しっかりとフリーズし、明らかに時間間隔で配列を処理しようとしました。
一連の出来事は、私の物語とほぼ逆の順序で復元されました。 私は個人的にこれに最初に対処しなければなりませんでした（逃げ出せず、緊急にサイトを見つけて上げる必要があり、静かに問題に対処することを静かに許可した当局に敬意を表さなければなりません）。
説明に基づいて、いくつかの結論はそれ自体を示唆しています
- 特に選択に関与する配列の場合、1つのドキュメントに大量のデータを保存しないでください。 ただし、ここではまだ議論の余地のある質問です。何が良いのか-多くの小さなドキュメント、またはいくつかの大きなドキュメントですが、大きすぎるドキュメントは、最良の側面を示しませんでした。
- データベースに入ったときにos_process_errorエラーが発生し、ログにタイムアウトという単語が含まれる場合-設定でos_process_timeoutを増やしてみると、データベースが再び動作を開始し、最新の変更を処理した結果が返されます。
- 残念ながら、特定のケースでは使用しなかったゴールデンルール-ユーザーが入力したデータを確認し、,なユーザーダーティトリックのように考えます。
この投稿が、私たちのようにグーグルを苦しめることから初めてこれに直面する人々を救うことを願っています。 残念ながら、私たちのプロジェクトは出席者のピーク時に中断されました。これが二度と起こらないことを願っています。
PSHabréに関する便利な記事： CouchDBを操作するための16の実用的なヒント 。