Plots2: メモリの問題（リーク？）の調査

@icaritoのコメントにください：

docker-compose-production.ymlを編集して、使用するプロセスの数を減らしたので、jywarrenは不思議に思います（PRを作成しませんでした）。 だから、私たちはそれをそのように適合させたのかもしれません。

そしてこのグラフ：

SMTPテストエラーもたくさん見られます。

リンク：| https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZ​​yu

はい、負荷も非常に高いです。 htop 、特にiotopから、 mailmanは非常にアクティブであるように見えます。 それは確かに犯人です！ 5月22日より前は、1日に数回実行していました。数分おきに実行できれば（毎秒ではありません！）、問題ありません。

I, [2019-05-07T23:56:44.702410 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-08T21:33:03.762360 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T07:47:27.518491 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-09T08:18:47.825703 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T08:14:53.010705 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-10T21:45:50.739207 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-11T17:38:51.647335 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-13T03:33:15.682877 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:51:40.603184 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:53:20.857041 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:55:00.356772 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-14T05:56:40.487219 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-15T01:43:42.908744 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-16T10:13:45.703985 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-18T12:57:16.194957 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:27.019569 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:49:55.827419 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:18.722700 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:50:41.709075 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:00.124271 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:17.146210 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:33.745494 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:51:51.387282 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:09.145006 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:52:31.266559 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:03.176998 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:26.991989 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:53:54.074275 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:13.905343 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:37.736641 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:54:57.357057 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:15.522535 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:34.343241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:55:51.964241 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:10.016964 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:42.822692 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:56:59.826809 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:16.178517 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:35.871196 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:57:59.731422 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:16.353160 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:33.608591 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:58:50.037296 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:06.912680 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:32.287362 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T08:59:59.201948 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:18.739067 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:00:42.144910 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:03.495556 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:20.493712 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:37.089192 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:01:53.921571 #1]  INFO -- : Mailman v0.7.0 started 
I, [2019-05-22T09:02:14.509227 #1]  INFO -- : Mailman v0.7.0 started

ログはこれらのサイクルでいっぱいで、エラーはありません。

I, [2019-06-02T02:35:26.270644 #1]  INFO -- : Mailman v0.7.0 started
I, [2019-06-02T02:35:26.270851 #1]  INFO -- : Rails root found in ., requiring environment...
I, [2019-06-02T02:35:56.930267 #1]  INFO -- : POP3 receiver enabled ([email protected]@pop.gmail.com).
I, [2019-06-02T02:35:56.938850 #1]  INFO -- : Polling enabled. Checking every 5 seconds.

mailmanがクラッシュし、すぐにリスポーンしているようです。

icarito@rs-plots2:/srv/plots_container/plots2$ docker ps
CONTAINER ID        IMAGE                COMMANDCREATED             STATUS              PORTS NAMES
8d13c675568e        containers_mailman   "script/mailman_serv…"4 days ago          Up 14 seconds containers_mailman_1
f423dec91ebe        containers_web       "/bin/bash -c 'sleep…"4 days ago          Up 4 days           127.0.0.1:4001->4001/tcp containers_web_1
24f7b43efebc        containers_sidekiq   "bundle exec sidekiq…"4 days ago          Up 4 days containers_sidekiq_1
070511ab43d1        redis:latest         "docker-entrypoint.s…"4 days ago          Up 4 days           6379/tcp containers_redis_1
6ea8f0498b2c        mariadb:10.2         "docker-entrypoint.s…"4 days ago          Up 3 days           3306/tcp containers_db_1

パフォーマンスへの影響を監視するために、このコンテナーを今夜停止することにしました。

このコードが公開されるまでの数日間に、どのgemupdateaがマージされたかについても調べることができると思います。 ありがとう！

これはmailmanについてはとても奇妙なことです。設定を確認しますが、レートの変更は覚えていません。

ああ、あなたは何を知っていますか？ 3回再試行するように設定しました。 多分これらは今重なっていますか？ スケジュールされた実行ごとに3回再試行するため、少なくとも試行率が向上する可能性があります。

https://github.com/publiclab/plots2/blob/faf66c0b15473add33c10c47d57a6e7cc46ea669/script/mailman_server#L32

OKはそれを20秒間変更しました。これは、最大5秒ごとの再試行を意味するはずです-

https://github.com/publiclab/plots2/commit/a40ea5650f2ce9ec80ee2324cea2d8c9bd98e382

これは、再試行を追加したときと同じレートになります。

OK、数時間後に分析に取り組んでいます：

https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559574420/6h/endpoints

全体的に良さそうです。 しかし、よく見ると、ロード時間は増加しています。

それが戻り始めている後者の部分を比較する：

再起動直後の以前のバージョンへ：

そして、私たちのすべてのトラブルの前の数週間前からこれに：

そしてついに、5月22日から23日に問題が発生し始めた直後：

全体的にそれは決定的ではありません。

リソース：

• メモリリークのあるgemとバージョンのリスト： https ：
• https://samsaffron.com/archive/2015/03/31/debugging-memory-leaks-in-ruby

これに関する難しいことの1つは、これら2つのコミットが発生した場所のすぐ近くにあることです。

1. プロファイルのキャッシュを無効にする（後で元に戻しました）： https ：
2. コンテナビルドプロセスの変更： https ：

今日調整しようとしたhttps://github.com/publiclab/plots2/commit/2bc7b498ef3a05bc090ef26f316a30ec0104bcc6のretry 3 timesコードの追加に関連していると思います。 しかし、実際にはロード時間はまだゆっくりと伸びています。

これは、a）他の何かがそれを駆動している、またはb）「レスキュー/再試行」サイクル自体がメモリリークの蓄積を引き起こしている可能性があることを意味する可能性があります。

レスキュー/リトライコードを完全にコメントアウトする必要がありますか？

多分mysqlが拾うのを待っているハングは実際にスレッドを取っていますか？

これを試してみます。 サイトがほとんど応答していません。

ここでretryを削除しました： https ：

展開中...しばらく時間がかかります。

うーん、それは本当に解決されていないようです... https://oss.skylight.io/app/applications/GZDPChmcfm1Q/1559577660/8h13m/endpoints

コンテナの設定がmailmanコンテナにまったく影響を与えたのではないかと思いますか？ この時点で、mailmanスクリプトからすべての可能性のあるものを元に戻したからです。

OK、一晩でピークに達し、少し下がった。 しかし、問題のあるものはまだかなり高く、ピークは約20秒です。

統計範囲の呼び出しには最大40秒以上かかります！

彼らはまた、キャッシュ生成に永遠に取り組んでいます：

キャッシュの読み取り/書き込みに問題が発生している可能性がありますか？

@icaritoは、読み取り/書き込みioに問題があるのでしょうか、それともキャッシュ生成に問題があるのでしょうか。 すべてのデータをキャッシュにパックするのになぜこれほど長い時間がかかるのかわかりません。

漏れのある宝石-大丈夫かどうかチェックしてください

• [x]セルロイド> 0.16.0、<0.17.2
• [x] csspool <4.0.3
• [x]ブドウ<0.2.5
• [x] oj <2.12.4
• [x] redcarpet <3.3.3
• [x] redis = 3.3.0
• [x] sidekiq <3.5.1
• [x] sidekiq-統計
• [x] therubyracer <0.12.2
• [x] zipruby <= 0.3.6

いずれの場合も、漏れはないがメモリの問題：

• [x] activeadmin
• [x] axlsx
• [x] delayd_job> = 4.06
• [x] libxml-Ruby <2.9.0、Nokogiri RC3
• [x] newrelic_rpm> = 3.9.4、<= 3.9.7
• [x]続編> = 2.12.0
• [x] stomp <= 1.3.5

stats_controller#rangeこの膨大なキャッシュ生成時間がまだ見られ、キャッシュが格納されている場所を微調整する必要があるかどうか疑問に思っています。 デフォルトはファイルストレージのようです（チェックしたところ、 /plots2/tmp/cache/キャッシュファイルがあります。メモリ内キャッシュまたはmemcachedに切り替えると、どちらも役に立ちますか？どうやらかなり単純な変更ですか？

https://guides.rubyonrails.org/v3.2/caching_with_rails.html#activesupport -cache-memorystore

https://www.skylight.io/support/performance-tipsもご覧ください

ここで電子メールの構成を確認しますが、何も生成されない場合は、これをマージして、 begin/rescueループをオフにします：＃5840

OK https://github.com/publiclab/plots2/pull/5841の次のステップは、mailmanがダウンしたかどうかの監視戦略を開発することです。

新しい電子メールクレデンシャルを使用して展開し、 begin/rescue削除します。 ただし、メモリリークが解決された場合は、 begin/rescue戻して再デプロイする価値があると思います。これは、電子メールのクレデンシャルの問題である可能性があるためです。

最新のエラー：

mailman_1 | /app/app/models/comment.rb:265:in add_comment': undefined methodbody' for nil:NilClass (NoMethodError) mailman_1 | from /app/app/models/comment.rb:218:in receive_mail' mailman_1 | from script/mailman_server:31:inblock (2 levels) in <main>' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:in instance_exec' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/router.rb:66:inroute' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:23:in block in process' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:33:inblock in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/middleware.rb:38:in run' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/message_processor.rb:22:inprocess' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:43:in block in get_messages' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:ineach' mailman_1 | from /usr/local/lib/ruby/2.4.0/net/pop.rb:666:in each_mail' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/receiver/pop3.rb:42:inget_messages' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:133:in block in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:inloop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:130:in polling_loop' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:83:inrun' mailman_1 | from /usr/local/bundle/gems/mailman-0.7.0/lib/mailman/application.rb:11:in run' mailman_1 | from script/mailman_server:22:in<main>'

それはここにあります：

https://github.com/publiclab/plots2/blob/e62bb49e30df79a9ddca5300579b80ff0903e3f4/app/models/comment.rb#L265

それを修正しました！ https://github.com/publiclab/plots2/commit/c02b5600fa512108d44b9163f44764a9552bbb73

ug、ついにコメントを公開しました。rb修正...。

OK、メールキューがフラッシュされ、正常に戻るかどうかを確認するのを待っています...

テストするためにhttps://publiclab.org/notes/mimiss/06-04-2019/workshop-viiiにコメントを残しました

こんにちは@jywarren私はこれを

まず、過去3か月間のRAM使用量のグラフを次に示します。

このグラフから、過去3か月間メモリ消費量が増加していることがわかります。

私は一年前に戻りました：

どうやら、2019年に、私たちのアプリケーションはメモリ要件をかなり増やしました。

理論的には、これまでのメモリ消費の軌跡に従って、使用可能なRAMを消費し、スワップに依存し始めたしきい値に達した可能性があります。これにより、処理速度が大幅に低下します。

メモリの増加は、いくつかのテーブルのサイズである可能性があります（私が見ているrusers ）。 これは＃5524と関係がある可能性があります。

いくつかの最適化を実装するか、データベースを別のホストに移行するか、RAMを追加する必要があります。

スパムユーザーのデータベースを整理することも強くお勧めします。

私はまだアプリ/サイトの成長によるメモリの枯渇に傾いています。これは、スワップメモリ​​がディスクに「スラッシング」するために高いIO負荷を引き起こしています。
Webコンテナからpassenger-memory-statsを確認しましたが、プロセスプールをさらに減らすことができると思います。

パフォーマンスを改善するための最初の動きとして、これを試してみます。

2018年2月に、11個のプロセスを実行できると計算したことがわかりました（アプリの実行に500 MBかかったため）。
式は次のとおりです。

max_app_processes = (TOTAL_RAM * 0.75) / RAM_PER_PROCESS
                  = 6000Mb / 750Mb
                  = 8

ただし、Skylightd、ツイートコメントをフェッチするプロセス、Sidekickも実行しており、mailmanプロセスも実行したいと考えています。
RAMの使用の大部分はWebコンテナ内にあります。

上記の両方の画像から、特に応答が速くなる場合は、1つのプロセスを節約できることがわかります。

4プロセスプールサイズに移行します。

最初の最適化が行われました。
有望な最初の30分！

ああ！

土では、2019年6月8日、20:47セバスチャン・シルバ[email protected]
書きました：

最初の最適化が行われました。
有望な最初の30分！
[画像：imagen]
https://user-images.githubusercontent.com/199755/59154753-46635b00-8a3f-11e9-87b7-51e660e4a148.png

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
。

OK、緩和策リストは次のようになります。

• [x]プロセスプールを減らす
• []データベースをグーグルクラウドデータベースソリューションに移動
• [] rusers削減します-おそらくます
• [] memcached切り替えます

ねえ@jywarrenと@icarito 、

まず、（そして私は冗談を言わずにこれを言います）：このスレッドは実際にはかなり良い読み物であることがわかりました。 それはすべての要素、謎、狩り、行き止まり、緊密な呼びかけなどを持っていました。

とにかく。

＃5450と＃5524に関連するルーサーテーブルに関しては、2013年4月26日から2014年1月1日までの間に発生したルーサーの_巨大な_グループ化があります。

2013年4月26日：1366934400
2014年1月1日：1388534400
UID範囲：59627-420114
ユーザー：360466

そのグループの一部で、＃5450で説明したテスト実行の最初のクエリを試してみませんか？

ノード、コメント、いいね、サブスクリプションを投稿しておらず、ログインしたことがないユーザー

あなたが言ったように、これまでログインしなかった場合、それ以前のすべての基準がカバーされるため、これは簡単なクエリになります。

他のメールで提案された過去6か月と同等の部分サイズについては、先月、約250件の初回投稿をスパムとしてマークしました。 つまり、過去6か月間に、スパムが原因で約1500人のユーザーが禁止されたとしましょう。

ああ、それは良い点をもたらすと思います。 スパムユーザーを排除したい場合は、スパムとしてマークされたコンテンツを持つすべてのユーザーを見つけて、それらを投稿したユーザーを削除することができます。

問題の1つで簡単に触れたように、初めてコンテンツをスパムとしてマークしたユーザーをデータベースからすぐに削除してもらうとよいでしょう。

こんにちは@skilfullycurledご入力ありがとうございます！ つまり、大多数のrusersは2013年から2014年までです。つまり、RAMの使用量を減らすのに役立ちますが、実際には、主要なテーブルはセッションとインプレッションです。

rsessionsは30GBを超えています。
@jywarrenと@ skilfullycurled-これを減らしたり、このテーブルを使用してクエリを最適化するための戦略を考え出すのは素晴らしいことです！

また、memcachedは、RAMの消費量が少なくなるのではなく、多くなるため、この問題には適していないと思います。

memcachedのメモリ使用量を制限することはできますが、それでも試してみます。

いいえ、上記のドキュメントから：

複数のRubyon Railsサーバープロセスを実行している場合（mongrel_clusterまたはPhusion Passengerを使用している場合）、Railsサーバープロセスインスタンスはキャッシュデータを相互に共有できません。 このキャッシュストアは、大規模なアプリケーションの展開には適していませんが、サーバープロセスが数個しかない小規模でトラフィックの少ないサイト、または開発環境とテスト環境には適しています。

_rsessions_を解決するのはそれほど難しくないように見えます：
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarrenこれを

@icarito、私は確かにこれは今まで行われていたではないんだけど、2016年にデータベースへのアクセスを持っていたし、ユーザセッションがはるかにより、データベースの実際の残りの部分を、より多くのスペースを取ったことを私は皆に通知しました。 フラッシュされると言われたので、フラッシュされなかったか、データベースがセッションを維持し続けるという問題が残っています。

感じてみると、2016年の時点で、bz2として_compressed_されたプロットデータベースは1.9GB（実際のサイズで解凍する時間はありません）、_ uncompressed_、セッションが削除された場合、518MBでした。

ありがとう@skilfullycurled !!! 2016年からの入力を覚えていると思います。フラッシュを見逃した理由はわかりませんが、今日のデータベースダンプは8 GBを超えて圧縮されており、ほとんどがセッションです。
@jywarrenからの確認を待ちます-今日、本番すれば、それをrakeタスクまたはcronジョブにすることができます。

DELETEFROMセッションWHEREupdated_at <DATE_SUB（NOW（）、INTERVAL 1 DAY）;

不思議に思ったのですが、非圧縮ファイルは6.8GBなので、518MBを差し引くと6.3GBになります。 😆

rsessionsは、実際に私が持っている私のお気に入りのデータセットです。 それは完全に使用されています-_less_、しかし私はそれが私が持っている使用されているデータセットよりも大きくないにしても同じくらい大きいのが大好きです-_ful_！ 誰かがそれをどうするかについて何かアイデアがあれば、私に知らせてください！

icarito（ @icarito ：matrix.org）はここから入手しましたhttps://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito（ @icarito ：matrix.org）過去1日または1週間アクティブでなかったすべてのセッションをログアウトする必要があります-微調整できます

ここでメモを取るだけです。 いいね。

不安定なのは時間がかかるようです...試すことができます

DELETE ... FROM ... WHERE ... LIMIT x

そして、本番環境で必要な回数だけ実行します。

7時間後、これはまだステージング中です。 明らかに、これは、1つのバッチで本番環境でこれを実行したい方法ではありません。 もう1つのことは、削除後、テーブルが断片化され、 rsessionsテーブルのファイルサイズが減少しないことです。 サーバーリソースを解放するには、テーブルをダンプして再作成する必要があります。

これを行うための私の計画は次のとおりです。

• [] where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)含むMysqlダンプrsessionsテーブル
• [] rsessionsテーブルの名前を変更します
• []ダンプされたテーブルから新しいrsessionsテーブルにクリーンなデータをロードします
• []古いrsessionsテーブルを削除します

stableステージングインスタンスでこれを試してみます。

素晴らしいセバスチャンと私はこれがポジティブかもしれないと思います
この後のデータベースパフォーマンスの期待される改善への影響
このテーブルをフラッシュするだけでもこれほど時間がかかる場合は、緩和策は完了です...

月、2019年6月17日には、午前9時50分PMセバスチャン・シルバ[email protected]
書きました：

安定したステージングインスタンスでこれを試してみます。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
。

@icaritoが終了したとき、彼女は再び安定に彼女のクエリを試すことができますので@cesswairimuに持ち込みます。 これにより、＃5917の問題が＃5490（修正済み）のみに関連するのか、それとも＃5524にも関連するのかがわかります。

unstableはまだ削除中です...

安定したインスタンスのステージングでテストを行っている間、ここにいくつかのメモを残します。

• [x]更新された場所を持つMysqlダンプrsessionsテーブル> DATE_SUB（NOW（）、INTERVAL 7 DAY）
  
  
  
  • コマンド： root<strong i="13">@tycho</strong>:/srv/plots_staging/plots2# time docker-compose exec db bash -c "mysqldump --databases plots --tables rsessions --where='updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)' -h 127.0.0.1 -u plots --password=plots" > /tmp/rsessions.sql
  
  
  • 時間： 13秒
  
  
• [x] rsessionsテーブルの名前を変更します
  
  
  
  • 構文： MariaDB [plots]> rename table rsessions to rsessions_prob
  
  
  • 歩哨レポートMysql2::Error: Table 'plots.rsessions' doesn't exist: SELECT rsessions .* FROM rsessions WHER...
  
  
  • ホームページは500になります
  
  
• [x]ダンプされたテーブルから新しいrsessionsテーブルにクリーンなデータをロードします
  
  
  
  • 構文： root<strong i="38">@tycho</strong>:/srv/plots_staging/plots2# time cat /tmp/rsessions.sql | docker-comp ose exec -T db bash -c "mysql -h 127.0.0.1 -u plots plots --password=plots"
  
  
  • 時間： 7秒
  
  
  • 新しいrsessionsテーブルファイルを作成します（ステージング用に13Mb！）
  
  
  • ホームページを復元します
  
  
• [x]古いrsessionsテーブルを削除します。
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (2.75 sec)
  
  

ログインするためにhttps://stable.publiclab.orgをテストしました。

これを本番環境で試す準備ができました！

unstableはまだ削除中です...

ライブプロダクションデータベースでの操作の実行：

• [x]更新された場所を持つMysqlダンプrsessionsテーブル> DATE_SUB（NOW（）、INTERVAL 7 DAY）
  
  
  
  • 時間： 48秒
  
  
  • ダンプサイズ：143Mb
  
  
• [x] rsessionsテーブルの名前を変更します
  
  
  
  • 時間： 11秒
  
  
  • ホームページはUTC午前6時まで15分間ダウンしていました
  
  
• [x]ダンプされたテーブルから新しいrsessionsテーブルにクリーンなデータをロードします
  
  
  
  • 新しいrsessionsテーブルファイル（220Mb）を作成します
  
  
  • ホームページを復元します
  
  
• [x]古いrsessionsテーブルを削除します。
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • 〜29GBを解放しました。
  
  

テスト済みhttps： //publiclab.org-セッションは保持されました！
：多田：

緩和が完了しました！ うまくいけば、これは私たちを解放します！

今夜はそのままにしておきます。サイトは私にはスピーディーに見えます...：stuck_out_tongue_closed_eyes：うまくいけば、これです！

OK、緩和策リストは次のようになります。

• [x]プロセスプールを減らす

• []データベースをグーグルクラウドデータベースソリューションに移動

• [x] rsessions減らす

• [] memcached切り替えます

うーん、今朝はとても速かったけど、全体的に大きな違いは見られない！ 😞

Nooooooooooooo！ ええと、他に1つだけ説明があり、それは幽霊です。 別の問題を開いて、エクソシストやゴーストバスターズの宝石を見つけることを検討します。

30GBのテーブルを使用すると重いため、実際にはI / Oの使用が改善されたと思います。よく見ると、ピークはStatscontrollerに関連しているように見えます...おそらく、ステージングで統計作業を行うことができますか？ 毎週定期的に本番データベースをコピーさせることはできますか？

ねえ@icarito 、私はあなたが私のためにいくつかの「教育的」質問に答えることができるかどうか疑問に思っていました：

よく見ると、ピークはStatscontrollerに関連しているようです...

なぜこれでしょうか？ キャッシングのため？ 私はそれを使用するだろう3人の人しか思いつかない、そして私は彼らの一人であり、私は使ったことがない。

多分私たちはステージングで統計作業を行うことができますか？

私は聞いていました...えーと...あなたが最近「ステージング」という言葉をよく使うのを見ています。 それは何であり、それはサイト/ワークフローにどのように影響しますか？ それがドキュメントの一部である場合は、どれを教えてください。最初にそれを理解するために少しずつ説明します。

毎週定期的に本番データベースをコピーさせることはできますか？

いいと思います。 最新のデータが重要であるということはそれほど重要ではありませんが、Q＆Aシステムが変更されてから最近のタグの移行までの間は、構造的な変更が発生したときにそれをキャッチするため、毎週行うことをお勧めします。 @ cesswairimu 、どう思いますか？

これは読むのに本当に素晴らしいスレッドでした。 ええ、統計をステージに置いて毎週コピーするのも素晴らしいアイデアです：+1：
私は将来、統計クエリをSQLビューを作成するスクリプトにして、ジョブによって毎日/または毎週削除および再作成することを考えました。これはステージでも実行できる可能性があります。 これについてのあなたの考えを聞きたいです、そしてこれが何らかの方法でメモリリークを助けることができるかどうか。

@icaritoさん、サーバーのRAMを増やすことはできますか？ クエリの応答率が向上するまで、Webサイトの速度を上げるのに役立つかもしれません。

ありがとう！

返信ありがとうございます！ あなたが行っている仕事と、この問題に返信し、私たちの努力を通して読んでくれたことに感謝します！ 私は非難するようなことはしたくない！ 私はただデータを見て、私たちのサイトの信頼性を改善しようとしています。
たとえば、今朝はピークに達しました： https ：

また、数時間のバックアップで毎晩（UTC午前6時）ピークが見られます。

ステージングとプロダクションに関しては、現在3つのインスタンスがあります。

インスタンス| URL | ビルドログ| ワークスペース
----------- | ------- | ------------ | -------------
| 不安定| https://unstable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Unstable/ws/
| 安定| https://stable.publiclab.org/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ | https://jenkins.laboratoriopublico.org/view/Staging/job/Plots-Stable/ws/
| 生産| https://publiclab.org/ | 該当なし| 該当なし

ドキュメントに関しては、このプロセスを説明するためのより良い仕事をする必要があるのは正しいことです。 現在、 https： //github.com/publiclab/plots2/blob/master/doc/TESTING.md#testing -branchesでいくつかのドキュメントを見つけましたが、これらのブランチにプッシュしたときにこれらのブランチが構築されるかどうかはまったくわかりません。

現在、データベースは頻繁に手動で更新されていますが、データベースダンプが毎日あるので、自動化するのは簡単です。 設定してpingを実行します。

これは、これ以上ソリューションを実装するべきではないという意味ではありません。次に、スレッド化されたWebサーバー（Puma）が役立つと思います。

それは良い質問です！ ホスティングをに移行中です
新しいプロバイダーであり、新しいプロバイダーにコンテナークラスターとしてデプロイすることを望んでいました
ホスティングプロバイダー。

コンテナで実行することはすぐに簡単ではないので（私たちのアプリのため
コンテナは不変ではありません）-開始する代わりに、
最初にデータベースを移動してスペースを確保します。

現在のホストでホスティングの使用量を増やすべきではないと思います
許可された割り当ての範囲内にあるので、 @ jywarrenは確認できますか？

お疲れ様でした！

19/06/19 11:23に、GauravSachdevaは次のように書いています。
>>

ねえ@icaritohttps ：//github.com/icarito、RAMを増やすことはできますか
サーバー？ 多分それは私たちまでウェブサイトをスピードアップするのに役立つでしょう
クエリの応答率を向上させますか？

ありがとう！

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q 。

実際、そのコンテナでラムを一時的にブーストできるかどうか疑問に思います
私たちが移動するまで、そしてそれが短期的に役立つかどうか。 大丈夫だと思います
そのコストが増加します！

水、2019年6月19日には、12：59 PMセバスチャン・シルバ[email protected]
書きました：

それは良い質問です！ ホスティングをに移行中です
新しいプロバイダーであり、新しいプロバイダーにコンテナークラスターとしてデプロイすることを望んでいました
ホスティングプロバイダー。

コンテナで実行することはすぐに簡単ではないので（私たちのアプリのため
コンテナは不変ではありません）-開始する代わりに、
最初にデータベースを移動してスペースを確保します。

現在のホストでホスティングの使用量を増やすべきではないと思います
許可された割り当ての範囲内にあるので、 @ jywarrenは確認できますか？

お疲れ様でした！

19/06/19 11:23に、GauravSachdevaは次のように書いています。
>>

ねえ@icaritohttps ：//github.com/icarito、RAMを増やすことはできますか
サーバー？ 多分それは私たちまでウェブサイトをスピードアップするのに役立つでしょう
クエリの応答率を向上させますか？

ありがとう！

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
、
またはスレッドをミュートします
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
。

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
。

ああ、 @ icarito 、いや、いや、私は告発をまったく感じなかった。 私は「これが起こっていることです」と読み、「それは奇妙なことです。誰もいないのになぜそうするのでしょうか...？」と言っていました。 同じように、私はドキュメントが貧弱であることを意味するつもりはありませんでした。 あるとしてもそれを説明する必要がなかったということだけです。

そしてねえ、それは完全に根拠のない告発ではありません:)私はフレームに入れられ、地下に潜り、自分の無実を証明しなければならないふりをして少し楽しんでいますが、それは私が取り組んでいる他の脚本です。

ありがたいことに、これらのばかげた根拠のない告発; ）両方の部分が片付けられており、手元のビジネスに戻ることができます。

関連する質問：誰も使用していないのに統計コントローラーがアクティブになるのはなぜですか、それとも謎ですか？

ステージングに関しては、説明ありがとうございます。 私が持っていることを確認するために、言っています...

安定したステージングインスタンスでこれを試してみます。

...「stable.publiclab.orgでこれを試してみます」と交換できますか？

安定した.publiclab.orgへQ-はい！ そして、それはへのあらゆるプッシュから構築されています
masterブランチ-お役に立てば幸いです。

2019年6月19日水曜日午後3時19分ベンジャミンシュガー[email protected]
書きました：

ああ、 @ icarito https://github.com/icarito 、いや、いや、私は何も感じなかった
告発、まったくありません。 私は「これが起こっていることです」と読みました、そして私はただでした
「それは奇妙なことですが、誰もいないのになぜそうするのでしょうか...？」
同じように、私はドキュメントが貧弱であることを意味するつもりはありませんでした。
あるとしてもそれを説明する必要がなかったということだけです。

そしてねえ、それは完全に根拠のない告発ではありません:)私は
額に入れられて行ったふりをして少し楽しんでいる
地下にいて、私の無実を証明する必要がありますが、それはまったく別のものです
私が取り組んでいる脚本。

ありがたいことに、これらのばかげた根拠のない告発; ）両方の部分にあります
片付けられて、手元のビジネスに戻ることができます。

関連する質問：誰もいないのに統計コントローラーがアクティブになるのはなぜですか
それを使うのか、それとも謎なのか？

ステージングに関しては、説明ありがとうございます。 私が持っていることを確認するために、
言っている...

安定したステージングインスタンスでこれを試してみます。

...「stable.publiclab.orgでこれを試してみます」と交換できますか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
。

@jywarren 、

@skilfullycurledの説明を
StatsControllerがなぜそれほどアクティブなのかは確かに謎です。

少し前に、数分間ノックダウンした別のピークがありました。

この場合のトリガーは、実際には全文検索でした。
しかし、この短いタイムスライス（3分）でも、StatsControllerが21回呼び出されたことがわかります。

これは、ベースラインのパフォーマンスに大きな影響を与えている可能性があると思います。 この使用法が不明な場合は、クローラーがこれらのエンドポイントにアクセスしている可能性がありますか？ たぶんrobots.txtまたはいくつかのアクセス制御がそれを修正するでしょうか？

@jywarren明確化に感謝します、それではできるだけ早くそれを行うことを検討します。

実際には、以前のタイムスライスのStatscontrollerの詳細は次のとおりです。

すべての統計ルートをrobots.txtしますか？ それで/ stats *は基本的に？

2019年6月20日木曜日午前0時21分セバスティアンシルバ[email protected]
書きました：

実際には、以前のタイムスライスのStatscontrollerの詳細は次のとおりです。
[画像：imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
。

OK、私はそうしました、そしてまた/ api / *を免除しました-私たちはすでに/ stats / range *をブロックしていました
しかし、今ではすべて/ stats *です

https://github.com/publiclab/plots2/commit/aa93dc3465b0cbaaee41ac7bec5e690437a27f5d

2019年6月20日木曜日午後2時45分

すべての統計ルートをrobots.txtしますか？ それで/ stats *は基本的に？

2019年6月20日木曜日午前0時21分セバスティアンシルバ[email protected]
書きました：

実際には、以前のタイムスライスのStatscontrollerの詳細は次のとおりです。
[画像：imagen]
https://user-images.githubusercontent.com/199755/59818278-d4b1c980-92e8-11e9-9b9e-46900a253bd8.png

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKT
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
。

それで、あなたはそれがキャッシングだとは思わないのですか？

キャッシュは使用によって生成されます。つまり、a）有効期限が切れたときに生成されます。
b）新しいリクエストが届きます。そのため、何かがそれをリクエストしている必要があります。
生成するキャッシュ...いくつかの無関係な問題を解決してマージできる場合
彼らのPR、私は今夜生産への新しい出版を開始します（そうでなければ
明日）そしてrobots.txtがまったく役立つかどうかを確認できますか？

2019年6月20日木曜日午後4時53分ベンジャミンシュガー[email protected]
書きました：

それで、あなたはそれがキャッシングだとは思わないのですか？

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
。

statscontrollerは1分あたり5.5回呼び出されます

@icarito経由-今夜のアップデートで、robots.txtの変更がこれに役立つかどうかを確認できます。

@jywarrenさん、robot.txtの更新コミットが数日前に安定版にプッシュされたのを見ました。 あなたが気づいた改善はありますか？

はい、アップデートが大好きです！ 正しいデータを取得したかどうかはわかりませんが、コミット前、コミット後、および過去24時間の天窓からの画像をいくつか示します。 赤い線は、コミットがいつ行われたかを示します。 答えはイエスのように表面的に見えますが、それは重要ではないか、データを誤って解釈している可能性があります。

はい、完全な分析が素晴らしいと思います。 しかし、簡単な答えはそれです
すべてのサイトリクエストの平均問題応答時間がほぼ半分になりました
5.5+から3以下まで。 それは本当に大きな改善です。 そうでした
a）8〜15 GBのRAMをほぼ2倍にする、b）マーケティングをブロックするの組み合わせ
robots.txtのボット、およびc）nginx構成でもブロックします（
IPアドレス範囲）。 難しいのは、bot / stats_controllerがどれだけあったかです。
その一部は、サイト全体のアップグレードを抑制したくなかったためです。

タイミングは：

1. robots.txtの午後5時から6時頃（東部標準時）だと思います
2. robots.txtの速度がわからなかった数時間後のnginx
   読んだり尊敬したりする
3. 土曜日の午前7時までのETサイトのメモリ拡張。

いずれにせよ、私たちは今本当にうまくやっています。 負荷平均は〜8ではなく<4であり、
CPUが4つではなく6つあります。

2019年6月25日火曜日午後5時32分ベンジャミンシュガー[email protected]
書きました：

はい、アップデートが大好きです！ 正しいデータを取得したかどうかはわかりませんが、ここにあります
コミット前、コミット後、および
過去約24時間。 赤い線は、コミットがいつ行われたかを示します。 見ている
答えのような表面はイエスですが、それは重要ではないかもしれません、または私
データを誤って解釈している可能性があります。

[画像：robots_txt]
https://user-images.githubusercontent.com/950291/60135129-05718300-976f-11e9-8fe7-3ca1c08​​1abe3.png

—
あなたが言及されたのであなたはこれを受け取っています。
このメールに直接返信し、GitHubで表示してください
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN
またはスレッドをミュートします
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
。

今これを閉じます！