Plots2: 内存问题（泄漏？）调查

注意到@icarito的评论：

我想知道 jywarren，因为我编辑了 docker-compose-production.yml 以使用更少的进程（没有为它做 PR）。 所以可能我们只是让它适合这种方式。

这张图：

我们也看到了很多 SMTP 测试错误：

链接： | https://intelligence.rackspace.com/cloud/entities/en45StuOyk/checks/chXoX9GHhF/alarm/alycd3HZ​​yu

是的，负载也非常高。 从htop尤其是iotop看来mailman非常活跃。 这绝对是罪魁祸首！ 在 5 月 22 日之前，我们每天运行几次——如果我们能每隔几分钟左右运行一次（不是每一秒！）——那就没问题了！

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.

看起来邮递员正在崩溃并立即重生！

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

我决定在今晚停止这个容器以监控对性能的影响。

我想我们也可以看看在此代码发布之前的几天里合并了哪些 gems updatea。 谢谢！

这对邮递员来说太奇怪了，我会查看配置，但我不记得费率有任何变化。

哦，你知道吗？ 我们将其设置为重试 3 次。 也许这些现在重叠了？ 它至少可以提高尝试率，因为它为每个预定的运行重试 3 次。

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

好的，修改了 20 秒，这应该意味着每 5 秒最多重试一次——

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

当我们添加重试时，这将与之前的速率相同。

好的，现在几个小时后开始分析：

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. 禁用配置文件缓存（我们后来恢复了）： 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

好的，我想知道容器设置是否会影响邮递员容器？ 因为此时我们已经从邮递员脚本中恢复了所有可能的内容。

好的，一夜之间它达到顶峰，然后又回落了一点。 但是我们的问题仍然相当高，峰值大约在 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] 红地毯 < 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] 活动管理员
• [x] 轴
• [x] 延迟作业 >= 4.06
• [x] 带有 Nokogiri RC3 的 libxml-ruby < 2.9.0
• [x] newrelic_rpm >= 3.9.4, <= 3.9.7
• [x] 续集 >= 2.12.0
• [x] 跺脚 <= 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

好的，我们对https://github.com/publiclab/plots2/pull/5841的下一步是制定一个监控策略，以了解邮递员是否宕机。

使用新的电子邮件凭据进行部署，并删除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，终于真正发布了comment.rb 修复....

好的，我们正在等待查看电子邮件队列是否刷新，然后我们看到一些恢复正常...

我在https://publiclab.org/notes/mimiss/06-04-2019/workshop-viii上发表评论来测试

嗨@jywarren我一直在重新审视这个问题并有一个理论。

首先是过去 3 个月 RAM 使用情况的图表：

从这张图中可以明显看出，过去三个月我们的内存消耗一直在增长！

我回去了一整年：

显然，在 2019 年，我们的应用程序的内存需求增加了很多。

理论是，按照我们一直拥有的内存消耗轨迹，我们可能已经达到了消耗可用 RAM 并开始依赖 Swap 的阈值，这大大减慢了速度。

内存增加很可能是我们某些表的大小（我正在查看rusers ）。 这可能与 #5524 有关系。

我们将不得不实施一些优化，将数据库迁移到不同的主机，或添加更多 RAM。

还强烈建议修剪垃圾邮件用户的数据库。

由于应用程序/站点增长，我仍然倾向于内存耗尽，由于将内存“颠簸”到磁盘，这会导致高 IO 负载。
我已经从 web 容器中检查了我们的passenger-memory-stats并认为我们可以进一步减少进程池：

我将尝试将此作为修复性能的第一步。

我发现在 2018 年 2 月，我们计算出可以运行 11 个进程（因为我们的应用程序需要 500mb 才能运行）。
公式为：

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

但我们也在运行 Skylightd，加上一个获取推文评论的进程，加上 Sidekick，还想运行 mailman 进程。
大多数 RAM 使用在 Web 容器中：

从上面的两个图像中我得出，我们仍然可以节省一个过程，特别是如果这可以使响应更快。

移动到 4 个进程池大小。

第一次优化完成。
有希望的前30分钟！

哦！

2019 年 6 月 8 日星期六晚上 8 点 47 分 Sebastian Silva通知@ github.com
写道：

第一次优化完成。
有希望的前30分钟！
[图像：图像]
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=AAAF6J7GXQIQPVWFTWGYJRLPZR4KJA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXWZHJK800000000000000000000000000000000000000000000000000000000000001
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J65RCLAEFO6H6RJLSTPZR4KJANCNFSM4HSA3N3Q
.

好的，所以缓解列表将是：

• [x] 减少进程池
• [] 将数据库移动到谷歌云数据库解决方案
• [ ] 减少rusers - 也许建立在https://github.com/publiclab/plots2/issues/5450 的工作之上
• [ ] 切换到memcached

嘿@jywarren和@icarito ，

首先，（我没有开玩笑地这么说）：这个帖子实际上非常好读。 它具有所有元素，一个谜，一个狩猎，死胡同，近距离通话等。

反正。

关于与#5450 和#5524 相关的 rusers 表，在 2013 年 4 月 26 日至 2014 年 1 月 1 日之间发生了大量的rusers 分组。

2013 年 4 月 26 日：1366934400
2014 年 1 月 1 日：1388534400
UID 范围：59627 - 420114
用户：360466

您想在该组的一部分上尝试您在 #5450 中描述的测试运行的第一个查询吗？

未发布任何节点、评论、点赞或订阅且从未登录过的用户

正如您所说，这将是一个简单的查询，因为不登录将涵盖之前出现的所有条件。

有关与您在另一封电子邮件中提议的过去 6 个月的同等份量大小的参考：在上个月，我们已将大约 250 个首次发布的帖子标记为垃圾邮件。 因此，假设在过去 6 个月中，由于垃圾邮件，我们有大约 1500 名用户被禁止。

哦，我想这提出了一个很好的观点。 如果您想摆脱垃圾邮件用户，您可以找到所有将内容标记为垃圾邮件的用户，然后删除发布这些内容的用户。

正如在其中一个问题中简要提到的那样，让第一次将内容标记为垃圾邮件的用户立即从数据库中删除可能是件好事。

嗨@skillfullycurled感谢您的投入！ 所以大多数 rusers 是从 2013-2014 年：这对我来说意味着虽然它可以帮助减少 RAM 使用量，但实际上，我们的主要表是rsessions和印象。

rsessions超过 30GB。
@jywarren和@skillfullycurled - 想出一种减少这种情况和/或使用此表优化查询的策略会很棒！

另外我认为 memcached 不适合这个问题，因为它应该消耗更多的内存而不是更少。

虽然可以限制memcached的内存使用，但我还是试试看！

不，从上面的文档：

如果您正在运行多个 Ruby on Rails 服务器进程（如果您使用的是 mongrel_cluster 或 Phusion Passenger），那么您的 Rails 服务器进程实例将无法相互共享缓存数据。 此缓存存储不适合大型应用程序部署，但适用于只有几个服务器进程的小型、低流量站点或开发和测试环境。

看起来解决_rsessions_并不太难：
https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table

@jywarren让我们这样做！

@icarito，我不知道这是曾经做过，但我不得不对数据库的访问在2016年，我通知大家的是，用户会话目前占去了更多的空间，那么数据库的实际休息。 有人告诉我他们会被刷新，所以要么他们没有，要么问题仍然是数据库只是继续保持会话。

给人一种感觉，截至 2016 年，地块数据库 _compressed_ as bz2 为 1.9GB（现在没有时间解压缩实际大小），_uncompressed_，删除会话后为 518 MB

谢谢@skillfullycurled !!! 我想我记得你在 2016 年的输入，我不知道我们是如何错过刷新的，但是我们今天的数据库转储压缩了超过 8GB，可能主要是会话。
我将等待@jywarren 的确认 - 我想今天在生产中运行以下内容，然后我们可以将它变成一个 rake 任务或 cron 作业：

DELETE FROM session WHERE updated_at < DATE_SUB(NOW(), INTERVAL 1 DAY);

我太好奇了，未压缩的文件是 6.8GB，减去 518MB 后的大小为 6.3GB。 😆

rsessions 实际上是我最喜欢的数据集。 它完全是 use-_less_ ，但我只是喜欢它与我使用的数据集一样大，即使不大于-_ful_！ 如果有人对如何处理它有任何想法，请告诉我！

icarito（ @icarito ：matrix.org）从这里得到它https://stackoverflow.com/questions/10088619/how-to-clear-rails-sessions-table
icarito ( @icarito :matrix.org) 它应该注销过去一天或一周内不活跃的每个会话 - 我们可以调整它

只是在这里做笔记。 听起来很棒。

不稳定似乎需要很长时间...可以尝试

DELETE ... from ... WHERE ... LIMIT x

并在生产中根据需要执行多次。

7 小时后，这仍在进行中。 显然，这不是我们想要在单批生产中做到这一点的方式。 另一件事是删除后，表会碎片化，并且rsessions表的文件大小不会减少。 为了释放服务器资源，需要转储并重新创建该表。

我这样做的计划如下：

• [] Mysql 使用where updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)转储 rsessions 表
• [ ] 重命名 rsessions 表
• [] 将干净的数据从转储表加载到新的 rsessions 表
• [ ] 删除旧的 rssessions 表

我将在stable登台实例中尝试这个。

好的，很棒的塞巴斯蒂安，我猜这可能有积极意义
在此之后对我们的数据库性能的预期改进的影响
缓解已完成，如果即使刷新此表也需要这么长时间......

2019 年 6 月 17 日星期一晚上 9:50 塞巴斯蒂安席尔瓦通知@ github.com
写道：

我会在稳定的登台实例中尝试这个。

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JYXKGLL2V7TV7OMNNDP3A5NVA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVX55WZPW63LNMVX5WWI22300000000000000000000000000000000000000000000000000000000000000000000004
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J7KQJ4OXJCRONW5G73P3A5NVANCNFSM4HSA3N3Q
.

引入@cesswairimu，这样她就可以在@icarito完成后再次尝试在stable 上进行查询。 这应该告诉我们#5917 中的问题是否仅与#5490（已修复）相关，或者它们是否也与#5524 相关。

unstable仍在删除...

在暂存稳定实例中进行测试时在这里留下一些笔记。

• [x] Mysql 转储 rsessions 表，其中 updated_at > 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 表，其中 updated_at > DATE_SUB(NOW(), INTERVAL 7 DAY)
  
  
  
  • 时间： 48秒
  
  
  • 转储大小：143Mb
  
  
• [x] 重命名 rsessions 表
  
  
  
  • 时间： 11秒
  
  
  • 主页在世界标准时间上午 6 点左右关闭了 15 分钟
  
  
• [x] 从转储表加载干净的数据到新的 rsessions 表
  
  
  
  • 创建新的 rsessions 表文件 (220Mb)
  
  
  • 恢复主页
  
  
• [x] 删除旧的 rsessions 表：
  
  
  
  • MariaDB [plots]> drop table rsessions_prob; Query OK, 0 rows affected (43.39 sec)
  
  
  • 释放约 29 GB。
  
  

已测试https://publiclab.org - 保留会话！
:tada:

缓解完成！ 希望这能让我们解脱！

虐待离开它今晚，网站看起来很快... :stuck_out_tongue_closed_eyes: 希望就是这样！

好的，所以缓解列表将是：

• [x] 减少进程池

• [] 将数据库移动到谷歌云数据库解决方案

• [x] 减少rsessions

• [ ]切换到memcached

嗯，今天早上速度很快，但总的来说我没有看到很大的不同！ 😞

呜呜呜呜！ 好吧，只有另一种解释，那就是鬼魂。 我将打开另一个问题并研究寻找驱魔人或捉鬼敢死队的宝石。

我认为实际上在 I/O 使用方面有所改进，因为使用 30GB 表很重——如果你仔细观察，峰值似乎与 Statscontroller 相关……也许我们可以在暂存上做统计工作？ 我可以让它每周定期复制生产数据库吗？

嘿@icarito ，我想知道您是否可以为我回答一些“教育”问题：

如果您仔细观察，峰值似乎与 Statscontroller 相关...

为什么会这样？ 由于缓存？ 我只能想到三个人会使用它，而我是其中之一，而我没有。

也许我们可以在分期上做统计工作？

我一直听说……呃……最近看到你经常使用“分期”这个词。 那是什么以及它如何在网站/工作流程中发挥作用？ 如果它是文档的一部分，请告诉我是哪一个，我会先尝试理解它。

我可以让它每周定期复制生产数据库吗？

我认为那会很好。 最新数据并不重要，但在更改问答系统和最近的标签迁移之间，我认为每周是一个好主意，因为它会在出现任何结构变化时捕捉到。 @cesswairimu ，你怎么看?

这是一个非常棒的主题阅读。 是的，将统计数据放在舞台上并每周复制也很好：+1：
我有这个想法，将来让统计查询成为一个脚本，该脚本创建一个 sql 视图，并每天/或每周通过作业删除和重新创建它，也许这也可以存在于阶段。 想听听您对此的想法，以及这是否可以以任何方式帮助内存泄漏。

嘿@icarito ，我们可以增加服务器的RAM吗？ 也许这将有助于加快网站速度，直到我们提高查询响应率？

谢谢！

感谢您的回复！ 感谢您所做的工作，感谢您回复此问题并阅读我们的努力！ 我不想听起来指责或任何东西！ 我只是在查看数据并试图提高我们网站的可靠性。
例如我们今天早上有一个高峰： https :

我们还会在几个小时内看到每晚（UTC 早上 6 点）的备份高峰。

关于登台和生产，目前我们有三个实例：

实例 | 网址 | 构建日志 | 工作区
-----------|-------|------------|------------
| 不稳定 | 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你！

这并不意味着我们不应该实施更多的解决方案，接下来我认为线程网络服务器（Puma）可以提供帮助！

这是个好问题！ 我们正在将我们的托管转移到
新的供应商，并希望在新的供应商中部署为容器集群
托管服务提供商。

由于在容器中运行并不是一件容易的事（因为我们的应用程序
容器不是一成不变的） - 开始的另一种选择是我们可以
首先移动数据库以腾出空间。

我认为我们不应该增加我们当前主机的托管使用量
因为我们几乎不在允许的配额内，但@jywarren可以确认吗？

感谢您的工作！

在 19/06/19 11:23，Gaurav Sachdeva 写道：
>

嘿@icarito https://github.com/icarito ，我们可以增加内存吗？
服务器？ 也许这将有助于加快网站速度，直到我们
提高我们的查询响应率？

谢谢！

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LONMVX52000000000000000000000000000000000000003同传
或静音线程
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q 。

其实我想知道我们是否可以暂时提升我们在那个容器中的内存
直到我们采取行动，以及它是否会在短期内有所帮助。 我想我们会没事的
随着成本的增加！

2019 年 6 月 19 日，星期三，下午 12:59，塞巴斯蒂安·席尔瓦（Sebastian Silva）通知@ github.com
写道：

这是个好问题！ 我们正在将我们的托管转移到
新的供应商，并希望在新的供应商中部署为容器集群
托管服务提供商。

由于在容器中运行并不是一件容易的事（因为我们的应用程序
容器不是一成不变的） - 开始的另一种选择是我们可以
首先移动数据库以腾出空间。

我认为我们不应该增加我们当前主机的托管使用量
因为我们几乎不在允许的配额内，但@jywarren可以确认吗？

感谢您的工作！

在 19/06/19 11:23，Gaurav Sachdeva 写道：
>

嘿@icarito https://github.com/icarito ，我们可以增加内存吗？
服务器？ 也许这将有助于加快网站速度，直到我们
提高我们的查询响应率？

谢谢！

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
<
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AABQYS3R6ENGBU4FYJXVNXTP3JMPBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LODNVX5CMD700000000000000000000000000000000000000000001同
,
或静音线程
<
https://github.com/notifications/unsubscribe-auth/AABQYS7LYPEKQ4QEANK5PRLP3JMPBANCNFSM4HSA3N3Q
.

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J4GPT5S2JYJCMGJWP3P3JQVRA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBWZKLONDMPY43VMVBWZKLODNX5004GPT5S2JYJCMGJWP3
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J4ERAAUV6JD3HUDZKDP3JQVRANCNFSM4HSA3N3Q
.

哦， @icarito ，不，不，我没有感觉到任何指控，一点也没有。 我读到，“这就是正在发生的事情”，我只是说“这很奇怪，如果没有人参与，为什么会这样做......？” 同样，我并不是要暗示文档很差。 只是如果有的话，你不必解释。

嘿，这不是一个完全没有根据的指控:) 虽然我假装自己被陷害，我已经进入地下并必须证明自己的清白，但这是我正在编写的另一个剧本.

谢天谢地，这些耸人听闻和毫无根据的指控； ) 两个部分都已清理完毕，我们可以继续处理手头的业务了。

相关问题：如果没有人使用它，为什么统计控制器会处于活动状态，或者这是个谜？

关于分期，谢谢你的解释。 为了确保我有，是说...

我会在稳定的登台实例中尝试这个。

...可以互换说，“我会在 stable.publiclab.org 上试试这个”？

到 stable.publiclab.org 问——是的！ 这是建立在任何推动
master分支 - 希望有帮助！

2019 年 6 月 19 日星期三下午 3:19 Benjamin Sugar通知@github.com
写道：

哦， @icarito https://github.com/icarito ，不，不，我没有感觉到任何
指责，完全没有。 我读到，“这就是正在发生的事情”，我只是
说“这很奇怪，如果没有人在上面，为什么要这样做......？”
同样，我并不是要暗示文档很差。
只是如果有的话，你不必解释。

嘿，这不是完全没有根据的指控 :) 虽然我是
假装我被陷害然后我走了，玩得很开心
地下，必须证明我的清白，但那完全是另一回事
我正在编写的剧本。

谢天谢地，这些耸人听闻和毫无根据的指控； ) 两个部分都有
已经清理完毕，我们可以回到手头的事情上。

相关问题：如果没有人，为什么统计控制器会处于活动状态
使用它还是那是个谜？

关于分期，谢谢你的解释。 为了确保我有，
是说...

我会在稳定的登台实例中尝试这个。

...可以互换说，“我会在 stable.publiclab.org 上试试这个”？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6J23U74QTJEVCLT6FLDP3KBBFA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LADXX5200000000000000000000000000000000000000000010同心
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J2RLJGI3ESQKZARV6DP3KBBFANCNFSM4HSA3N3Q
.

@jywarren ，是的！ 现在得到了。 谢谢！

感谢@skillfullycurled的澄清！
StatsController 为何如此活跃确实是个谜？

片刻之前，我们遇到了另一个高峰，让我们失望了几分钟：

这种情况下的触发器实际上是全文搜索。
但是可以看到，即使在这个短暂的时间片（3 分钟）中， StatsController 也被调用了21 次。

我认为这可能会显着影响我们的基准性能。 如果这种用法未知，那么也许爬虫正在访问这些端点？ 也许 robots.txt 或一些访问控制可以解决这个问题？

@jywarren感谢您的澄清，我会尽快考虑这样做。

实际上这里是以前时间片的 Statscontroller 详细信息：

我们应该robots.txt所有统计路由吗？ 所以 /stats* 基本上？

2019 年 6 月 20 日星期四上午 12:21 塞巴斯蒂安席尔瓦通知@github.com
写道：

实际上这里是以前时间片的 Statscontroller 详细信息：
[图像：图像]
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=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63KLDNX53VMZKJQY6TCZMQE3PNVW63KLDNX53VMZKJQY6TCZMQE35000000000000000000000000000000000000001001 ;
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

好的，我做到了，并且还免除了 /api/* - 我们已经阻止了 /stats/range*
但现在一切都结束了 /stats*

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

2019 年 6 月 20 日星期四下午 2:45，Jeffrey Warren [email protected]写道：

我们应该robots.txt所有统计路由吗？ 所以 /stats* 基本上？

2019 年 6 月 20 日星期四上午 12:21 塞巴斯蒂安席尔瓦通知@github.com
写道：

实际上这里是以前时间片的 Statscontroller 详细信息：
[图像：图像]
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=AAAF6J7GBBZKJQY6TCZMQE3P3MARXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63KLDNX53VMZKJQY6TCZMQE3PNVW63KLDNX53VMZKJQY6TCZMQE35000000000000000000000000000000000000001001 ;
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J7PGJ5YZZHPLWPIJ73P3MARXANCNFSM4HSA3N3Q
.

所以你不认为这是缓存？

缓存是使用生成的，也就是说，它在 a) 过期时生成，并且
b) 一个新的请求进来了。所以必须有一些东西来请求它
缓存生成...如果我能解决几个不相关的问题并合并
他们的 PR，我今晚将开始制作新出版物（否则
明天），我们可以看看 robots.txt 是否有帮助？

2019 年 6 月 20 日星期四下午 4:53 Benjamin Sugar [email protected]
写道：

所以你不认为这是缓存？

—
你收到这个是因为你被提到了。
直接回复本邮件，在GitHub上查看
https://github.com/publiclab/plots2/issues/5817?email_source=notifications&email_token=AAAF6JZ5WFKAP5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63KLDNXV43VMVBW63KLDNX500000000000000000000000040000005000000000000005同理心5ZCICW67VLP3PUZBA5CNFSM4HSA3N32YY3
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J4MBMWM6WIOH6VJCY3P3PUZBANCNFSM4HSA3N3Q
.

statscontroller 每分钟调用 5.5 次

通过@icarito - 所以在今晚的更新中，我们可以看看robots.txt 的更改是否对此有所帮助。

嘿@jywarren ，

是的，希望更新！ 不确定我获取了正确的数据，但这里有一些来自提交前、提交后和最后大约 24 小时的天窗图像。 红线表示提交的时间。 从表面上看，答案是肯定的，但它可能并不重要，或者我可能会错误地解释数据。

是的，我认为完整的分析会很棒。 但简短的回答是
我们几乎将所有站点请求的平均问题响应时间减半
从 5.5+ 到 3 或更少。 这真的是一个巨大的进步。 那是个
a) 将 RAM 从 8-15GB 几乎翻倍，b) 阻止营销
robots.txt 中的 bot，以及 c) 也在 nginx 配置中阻止它（我认为是
IP 地址范围）。 困难的部分是 bot/stats_controller 是多少
部分原因，因为我们不想阻碍整个站点的升级。

时间是：

1. robots.txt 大约在美国东部时间下午 5-6 点，我想
2. 在我们不确定 robots.txt 的速度有多快之后，nginx 阻止了几个小时
   阅读或尊重
3. 周六上午 7 点左右 ET 站点内存扩展。

无论如何，我们现在做得很好。 平均负载 <4 而不是 ~8，
我们有 6 个而不是 4 个 CPU。

2019 年 6 月 25 日星期二下午 5:32 Benjamin Sugar通知@github.com
写道：

是的，希望更新！ 不确定我获取了正确的数据，但这里是
提交前、提交后以及来自天窗的一些图像
持续约 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=AAAF6J6ALZMY2QMSC7TZQHDP4KFEXA5CNFSM4HSA3N32YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LODNVX5R43VMVBW63LODMX5R50WJW63LDNMX5R500000000000000001
或静音线程
https://github.com/notifications/unsubscribe-auth/AAAF6J4E2Z2E47A4T6OWUCDP4KFEXANCNFSM4HSA3N3Q
.

现在关闭这个！