如何扩展您的 Mastodon 服务器

作者选择了 Apache Software Foundation和 Free and Open Source Fund作为 Write for Donations计划的一部分接受捐款。

介绍

Mastodon是一个开源的自我托管的社交网络 Mastodon是联邦化的,这意味着Mastodon的多个实例可以相互协作, 允许来自不同服务器的用户相互通信,以创建一个名为fediverse的网络 fediverse是相互连接的服务器的网络,这些服务器使用ActivityPub(https://activitypub.rocks/)协议相互通信。

随着Mastodon社区的增长,服务器的负载也同样如此。在过去的一年里,由于用户活动的峰值而发生了许多Mastodon服务器下跌的事件,为了防止Mastodon服务器在用户流入期间下跌,它需要扩展。

In order to understand how to scale a Mastodon, you need to understand what Mastodon is made of. A Mastodon server consists of five main components: Web service, StreamingAPI service, Sidekiq service, Redis, and PostgreSQL. Mastodon Architecture Non-Transparent

可选的是,对象存储可以大大提高静态媒体文件的性能并降低 Web 服务的负载,虽然不提供性能提升,但 ElasticSearch 也可以启用全文本搜索,LibreTranslate 可以允许您的服务器自动翻译消息,使您的服务器变得更漂亮一点。

<$>[注] 注: Mastodon 服务只通过数据存储(Redis 和 PostgreSQL)进行通信,这为分布式设置提供了很大的灵活性,但简单地在没有正确配置的情况下在多个机器上分布组件不会带来所需的性能提升。

在本教程中,您将了解您的Mastodon服务器的不同扩展技术:

  • 增加数据库资源和可用连接
  • 将Sidekiq队列分成多个流程
  • 配置每个Sidekiq队列的线程和资源
  • 添加对象存储来下载Web服务
  • 增加Web服务的线程和流程

如果您打算扩展您的Mastodon服务器以满足某些活跃用户的容量,我们建议通过整个文章并扩展每个组件 另一方面,如果您打算扩展某个特定组件 - 请放心跳到相应的组件部分 拇指规则是保持每个运行Mastodon组件的机器的平均负载约60% - 70%。

<$>[注] 注: 本文包含针对在 systemd 服务上运行的 Mastodon 服务器的示例(如 Mastodon Droplet 1-Click)。

提高数据库性能

PostgreSQL 是您的 Mastodon 服务器的主要真相来源. 它包含所有用户的身份证、点击、增强、用户关系等。

Mastodon 使用大量连接到数据库. 连接饥饿的症状包括 Sidekiq 性能差,传输更新延迟时间,整体缓慢,甚至整个服务器无法访问。

在本节中,您将计算为您的服务器所需的连接数量,并相应地配置数据库. 没有额外的资源,它将保护您的服务器免受连接饥饿,这会影响所有Mastodon服务的性能。

<$>[info] 信息: 您的Mastodon服务器所需的连接数量绝不能超过您的PostgreSQL的max_connections变量。

要计算 Mastodon 服务器所需的连接总数,您需要计算每个组件所需的连接总数:

  • 对于每个 Web 服务实例,所需的连接是 MAX_THREADS 乘以 WEB_CONCURRENCY
  • 对于每个 StreamingAPI 实例,所需的连接是 STREAMING_CLUSTER_NUM 乘以 DB_POOL
  • 对于每个 Sidekiq 实例,所需的连接等于 DB_POOL

<$>[info] **信息:**上面的所有变量都可以在相应组件的环境中找到。

总结所有这些数字,并为维护添加额外的 20 个连接,这是 max_connections 的值。

<$>[info] **信息:**正确配置数据库是您在扩展 Mastodon 时的首要任务,但要确定 max_connections 的数量,您必须首先知道如何扩展其他服务。

现在您知道 max_connections 有值,您将使用它来配置您的数据库。

创建配置的好方法是使用一个名为 PGTune的服务。 在打开PGTune页面时,您将收到配置字段,您必须填充:

  • DB 版本:在这里指定您的 Mastodon 服务器使用的 PostgreSQL 版本,您可以使用此命令在运行 PostgreSQL 的机器上找到它:
1pg_config --version
  • OS 类型:运行 PostgreSQL 的机器的操作系统
  • DB 类型:您的 PostgreSQL 将执行的工作负载类型。在 Mastodon 的情况下,请选择 Online Transaction Processing System (OLTP 在未来) 因为 Mastodon 会创建大量连接
  • Total Memory (RAM): PostgreSQL 将使用的内存量。 尝试分配高达一半的机器的物理内存,但如果其他服务在同一台机器上运行 - 请确保不超过 RAM 总量。 例如,在拥有 8 GB 的 RAM 和仅有 PostgreSQL 的机器上,我们在 PuneGT 中指定 4 GB。

例如,在 8 GB RAM 机器、 8 个线程和 420 max_connections 上,配置是这样的:

PGTune example

点击生成后,您将收到配置参数,这些参数应添加到您的postgresl.conf文件中。

在运行 PostgreSQL 的机器上打开 postgresql.conf:

1sudo nano /etc/postgresql/major version of your PostgreSQL/main/postgresql.conf

例如,如果您正在运行 PostgreSQL 版本 15.x,此文件的位置将是 /etc/postgresql/15/main/postgresql.conf。

接下来,对于 PGTune 生成的每个参数,您将在您的 postgresql.conf 中寻找相同的参数,并更改其值. 使用 Ctrl+W 搜索 nano 和 Esc+/ 在 vi/vim 中。 如果在您的 postgresql.conf 中没有任何参数,您可以在文件中的任何地方创建它。

Example of searching parameter in postgresql.conf

最后,重新启动 PostgreSQL 服务以应用更改:

1sudo service postgressql restart

现在你知道如何配置 PostgreSQL 以提高 Mastodon 的性能,以及如何应用新的配置. 在下一节中,你将找到计算 max_connections 所需的所有变量的准确值。

完美的Sidekiq队列

Sidekiq 是一个 Ruby 工作计划员和工作者,负责执行背景任务,例如在服务器之间传播帖子,生成链接预览,处理喜欢等。

Sidekiq 使用 Redis 作为工作排列管理器和 PostgreSQL 来保存工作结果. 如果多个服务器连接(用户正在跟踪来自其他服务器的人),将创建大量工作来将必要的数据从一个服务器传输到另一个服务器。

Sidekiq瓶颈的症状包括长期延迟的源更新,堵塞的Sidekiq队列和持久的数据库负载。

在本节中,您将接近服务器所需的Sidekiq队列的大小以及运行它们所需的物理机器数量。

Mastodon 对 Sidekiq 有几个队列. 然而,其中一些队列更为资源密集,将完全加载 CPU,而其他队列几乎不会造成负载的任何百分比。 下表包含所有队列的描述,需要 Mastodon 以及其资源优先级,高优先级队列将比低优先级使用更多的 CPU:

QQ排行榜 QQ优先出道 角色出道 (- -) 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道 出道人. ) 默认 QQQ 最高 QQ 处理所有影响本地用户的任务. QQ ingress QQ 高 QQ 处理即将到来的远程活动. 优先级低于默认队列, 因此当服务器被装入时, 本地用户仍然可以看到自己的帖子 。 记住, " 女性 " 排队非常密集。 QQ 将 中 QQ 送出有效载荷到其他服务器. QQ @ @% 中度 处理导入、备份、解析线程、删除用户和转发回复等任务。 QQ QQ邮递员 低QQ发送电子邮件. QQ QQ 排程器 Lowest QQ 管理 cron 任务, 如刷新趋势标签并清理日志 。 |

<$>[警告] 警告: scheduler 排队永远不会扩展到多个流程。只有一种运行 scheduler 的过程应该存在于您的 Mastodon 服务器 <$> 上面的表将帮助您正确分配机器,但如何配置排队本身?排队被限制在他们可以有效地服务的活跃用户的数量上,并且这种限制与特定排队的线程数量有关。分配的线程越多 - 特定排队的活跃用户越多。排队类型也影响了这种限制,一些排队需要更少的线程来服务与其他排队相同的用户数量。 该多维关系在下图中描述。

The X-axis indicates the expected number of active users Mastodon will serve, while the Y-axis indicates the estimated number of threads required for each queue to serve the corresponding amount of active users: Mastodon Sidekiq Scaling Estimation

根据您的服务器社区,推或推队列可能具有不同的优先级。如果您的社区与其他联盟高度相互连接,请优先考虑推队列。

<$>[注] **注:**不同的服务器有不同的使用模式和负载分布. 尝试通过分析来自您的服务器的用户将增加或喜欢来自其他服务器的用户的概率来预测您的服务器的使用模式。

例如,如果您的服务器涵盖特定科学主题,则来自您的服务器的用户将主要彼此通信,另一方面,如果您的服务器是个人政治博客,则来自您的服务器的用户可能会更有可能推动其他政治家。

The last important note about Sidekiq queues is the fact that ~10-15 threads of Sidekiq require 1 GB of RAM. This concludes a relation: Sidekiq parameters to resources relation

<$>[warning] **警告:**单个Sidekiq服务不应该使用超过50个线程。

例如,我们估计有15000名活跃用户将主要使用本地联盟 根据上面的图表,我们需要:

  • 默认:大约70个线程总数,2个服务各有35个线程
  • ingress:大约50个线程总数,2个服务各有25个线程
  • pull:大约40个线程总数,1个服务各有40个线程
  • push:大约30个线程总数,1个服务各有35个线程
  • mailer:大约20个线程总数,1个服务各有20个线程
  • scheduler:5个线程总数,1个服务各有5个线程

请记住,我们的用户并不使用外部联盟,所以我们优先选择推而不是推。

由于scheduler队列是最低的优先级队列,我们可以与默认队列一起运行,这根本不会影响默认队列。 它们需要70 + 5 = 75线程,相当于大约8GB的RAM。 因为它只是一条重的队列,我们可以使用一个单一的4核8GB机器 ingress和mailer是高和低优先级队列,这意味着它们将需要比单一的默认队列更少的CPU资源,但我们仍然会使用4核机器。 它们的线程总量是25 + 20 = 45,这大约是6GB的RAM( _pull和push队列都是中等优先级,使它们比ressing和

总之,如果我们计划为15000名活跃用户提供服务,那么对于Sidekiq配置,我们将需要总共3台机器:

  • 一台 4c/8GB 机器可为默认队列的 2 个服务提供 35 个线索,每个服务为 5 个线索提供 1 个日程安排队列
  • 一台 4c/8GB 机器可为 50 个线索提供 1 个入门队列的服务和 20 个线索提供 1 个邮递队列的服务
  • 一台 4c/6GB 机器可为 40 个线索提供 1 个推队列的服务和 30 个线索提供 1 个推队列的服务

<$>[注] **注:**确定所需的内核数量的最佳方法是观察运行Sidekiq的机器的平均负载 如果平均负载超过80%,需要更多的CPU内核。

要充分利用硬件资源,Sidekiq 需要配置适当数量的线程,并在流程级别上扩展。 在本节中,您将了解如何准确设置 Sidekiq 排列的线程数量以及如何使用服务模板在同一台机器上运行多个排列。

<$>[注] **注:**下面的示例可列入 systemd 服务的ExecStart或 Docker 的命令字段中。

增加单个 Sidekiq 流程使用的线程数量

服务是一种资源,系统d 可以管理、登录、自动重新启动等等。在服务中包装可执行的应用程序是部署应用程序的最简单方法之一。系统d 服务是运行 Sidekiq 队列的最常见方式 Sidekiq 服务的位置取决于您的 Mastodon 安装类型。例如,如果您正在使用 Mastodon Droplet 1-Click,您可以在这个位置找到 Sidekiq 服务文件:

1cat /etc/systemd/system/mastodon-sidekiq.service

让我们快速看看服务文件的顶部:

 1[Unit]
 2Description=mastodon-sidekiq
 3After=network.target
 4
 5[Service]
 6Type=simple
 7User=mastodon
 8WorkingDirectory=/home/mastodon/live
 9Environment="RAILS_ENV=production"
10Environment="DB_POOL=25"
11Environment="MALLOC_ARENA_MAX=2"
12Environment="LD_PRELOAD=libjemalloc.so"
13ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25
14...
15
16[Install]
17WantedBy=multi-user.target

我們應該關注兩個特定的領域:『ExecStart』和『環境』 『ExecStart』定義在服務啟動或重新啟動時運行的服務的起點 。

要扩展一个单一的 Sidekiq 流程,你应该增加 Sidekiq 将使用的线程的数目。这个数目由 ExecStart 字段中的 -c 参数控制。 不要忘记将 DB_POOL 环境变量与 -c 参数同步 例如,让我们将线程的数目增加到 45。

 1[Unit]
 2Description=mastodon-sidekiq
 3After=network.target
 4
 5[Service]
 6Type=simple
 7User=mastodon
 8WorkingDirectory=/home/mastodon/live
 9Environment="RAILS_ENV=production"
10Environment="DB_POOL=40"
11Environment="MALLOC_ARENA_MAX=2"
12Environment="LD_PRELOAD=libjemalloc.so"
13ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 40
14...
15
16[Install]
17WantedBy=multi-user.target

信息:DB_POOL环境应该总是与 -c 参数相同的值(在上面的例子中是 40)。如果它较小,会引入 Sidekiq 性能问题,而如果它更高,则会引入数据库的额外负载。

对服务文件进行任何更改后,请确保重新加载单元文件并重新启动Sidekiq服务:

1sudo systemctl daemon-reload
2sudo systemctl restart mastodon-sidekiq.service

通过应用本节的更改,您增加了Sidekiq使用的线程数量,使其能够为更多用户提供服务。

指定单个 Sidekiq 实例的特定队列

如果您正在使用Mastodon Droplet 1-Click,您可以在这个位置找到Sidekiq服务文件:

1cat /etc/systemd/system/mastodon-sidekiq.service

正如你所知道的,Mastodon将Sidekiq数据分为几个队列,默认情况下,服务文件中没有明确的队列。

 1[Unit]
 2Description=mastodon-sidekiq
 3After=network.target
 4
 5[Service]
 6Type=simple
 7User=mastodon
 8WorkingDirectory=/home/mastodon/live
 9Environment="RAILS_ENV=production"
10Environment="DB_POOL=25"
11Environment="MALLOC_ARENA_MAX=2"
12Environment="LD_PRELOAD=libjemalloc.so"
13ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25
14...
15
16[Install]
17WantedBy=multi-user.target

没有明确的队列意味着Sidekiq将为所有队列提供一些默认优先级的服务,因为即使是单一的Sidekiq队列也具有资源密集性,所以在单一的Sidekiq实例上运行所有队列不如理想 你想要实现的就是将Sidekiq队列分成几个Sidekiq实例。

例如,让我们让Sidekiq只服务于入口队列:

 1[Unit]
 2Description=mastodon-sidekiq
 3After=network.target
 4
 5[Service]
 6Type=simple
 7User=mastodon
 8WorkingDirectory=/home/mastodon/live
 9Environment="RAILS_ENV=production"
10Environment="DB_POOL=25"
11Environment="MALLOC_ARENA_MAX=2"
12Environment="LD_PRELOAD=libjemalloc.so"
13ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c 25 -q ingress
14...
15
16[Install]
17WantedBy=multi-user.target

通过指定 -q ingress,你告诉Sidekiq只服务ingress队列,而不是其他任何东西。

<$>[警告] ** 警告:** 上面的示例将使除了ingress之外的所有队列未经处理,这意味着Mastodon 不会正常工作. 请确保至少覆盖每个队列一次。

有Sidekiq服务只处理一个单一的队列有几个优点:它更容易处理特定队列的日志,它提供了每个队列的管理和线程控制,并允许通过在不同的机器上运行不同的队列进行分布式设置。总体而言,它被认为是扩展Sidekiq队列的主要做法。

使用模板在单个机器上运行多个Sidekiq实例

要进一步扩展 Sidekiq,您可以同时运行多个 Sidekiq 实例. 由于 systemd 服务是运行 Sidekiq 的最常见方式,您将学习如何创建服务模板,以简化在单台机器上运行多个 Sidekiq 实例。

服务模板允许我们从一个服务文件创建多个服务。

首先,让我们创建我们现有的Sidekiq服务文件的副本:

1cp /etc/systemd/system/mastodon-sidekiq.service /etc/systemd/system/mastodon-sidekiq-template.service

这将创建一个名为 mastodon-sidekiq-template.service 的新文件,该文件是现有 Sidekiq 服务的副本. 您将修改此副本以将其转换为模板。

  • %i 是实例名. 对于实例服务,这是第一个@字符和类型补充符之间的字符串
  • %j 是前缀的最终组成部分。

听起来很困惑?让我们跳入实际部分来更好地理解它。

首先,打开新的服务文件来编辑它:

1sudo nano /etc/systemd/system/mastodon-sidekiq-template.service

现在,更改服务文件中的某些值以创建模板规格:

  • 描述字段应包含 %j 指标,以便更容易跟踪和维护服务
  • DB_POOL 环境变量应等于 %i 指标
  • ExecStart 中的 -c 参数应等于 %i
  • ExecStart 中的 -q 参数应等于 %j
 1[label /etc/systemd/system/mastodon-sidekiq-template.service]
 2[Unit]
 3Description=mastodon-sidekiq-%j-queue
 4After=network.target
 5
 6[Service]
 7...
 8Environment="DB_POOL=%i"
 9Environment="MALLOC_ARENA_MAX=2"
10Environment="LD_PRELOAD=libjemalloc.so"
11ExecStart=/home/mastodon/.rbenv/shims/bundle exec sidekiq -c %i -q %j
12...
13[Install]
14WantedBy=multi-user.target

正如你可能猜到的, %i specifier 将包含 Sidekiq 的线程数, %j specifier 将包含 Sidekiq 排列的名称。

So, how you can set these variables? Specifiers are substituted with particular sections from the service file. Substitution of specifiers from the service file

让我们使用这个模板来创建所需的 Sidekiq 配置的服务文件。

首先,复制模板以指定您想要在该机器上运行的排列,例如,要运行默认和日程表排列:

1cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/[email protected]
2cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/[email protected]

对于队列的名称,你可以使用一个默认,入,推,拖,邮件员,日程表。

你可能已经注意到你没有在 @ 符号之后指定任何东西,因为当你启用服务本身时,你会指定这个参数 现在要启用新的服务,让我们使用 20 个线程为默认排序和 5 个排序:

1sudo systemctl enable [email protected]
2sudo systemctl enable [email protected]

最后,在启用新服务后,您可以使用以下命令同时运行所有服务:

1sudo systemctl start mastodon-sidekiq*

在此时,您成功创建了一个模板服务文件,并使用它运行多个Sidekiq服务,使用不同的队列和线程。

更改运行模板服务的配置

例如,如果您想更改您的模板默认服务的线程数量从 20 到 40 时,您应该先禁用现有服务:

1sudo systemctl stop mastodon-sidekiq-default.service
2sudo systemctl disable [email protected]

注意如何只指定禁用命令的线程数量,而不是停止。

在禁用旧的推服务后,您可以创建一个新的服务,其中有40个线程,而不是20个:

1sudo systemctl enable [email protected]
2sudo systemctl start mastodon-sidekiq-default.service

此时,您已成功更改现有 systemd 服务的线程数量。

运行同一 Sidekiq 队列的多个服务

正如你所知道的,Sidekiq的单个实例不应该有超过50个线程,运行某个线程的60个线程需要将其分为2个服务,每个线程30个线程。

要做到这一点,你需要复制模板多次使用相同的队列,但添加一个索引. 索引只是一个数字,它将区分每个服务文件. 复制原始模板多次,但每次相同的队列重复时增加索引。

1cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/[email protected]
2cp /etc/systemd/system/mastodon-sidekiq-template.service /etc/systemd/system/[email protected]

<$>[警告] 警告: 不要在排序名称之后添加索引: /etc/systemd/system/mastodon-sidekiq-default-2@service. 这将使模板将‘2’视为排序名称,这将不可避免地使排序名称失败。

现在,让我们为默认队列的第一个实例启用40个线程,为第二个实例启用60个线程:

1sudo systemctl enable [email protected]
2sudo systemctl enable [email protected]

最后,在启用服务后,您可以使用以下命令运行所有服务:

1sudo systemctl start mastodon-sidekiq*

在此时,您成功创建了相同排队的多个实例,允许您正确分割大量线程。

在某些情况下,一个默认服务就足够了,其他情况下需要在单台机器上提供多个服务,有些情况下甚至需要在多个机器上排队的多个服务。

添加物体存储

对象存储,或简单的桶,允许存储用户上传的媒体文件您的服务器. 这包括照片,视频,GIF,音频文件,等等。

从文件系统迁移到对象存储有助于增加存储的速度和容量,但更重要的是,它减少了来自Mastodon服务的负载。

注意:Mastodon 使用 S3 兼容接口,这意味着您的对象存储提供商必须支持 S3 接口,并为 S3 存储凭证提供地图。

如果您在 Mastodon 初始化过程中意外错过了对象存储配置,您可以直接将必要的变量添加到运行 Web 服务的机器的配置中,因为对象存储只能由 Web 服务使用。

警告:通过更改对象存储,您将失去服务器上的任何现有媒体文件

在运行 Web 服务的机器上,在您喜欢的文本编辑器中打开 .env.production,如果您正在使用 Mastodon Droplet 1-Click env.production 位于 /home/mastodon/live:

1sudo nano .env.production

如果这些变量已经存在 - 意味着在设置过程中配置了对象存储,则如果值不正确,您仍然可以更改它们:

 1[label .env.production]
 2...
 3S3_ENABLED=true
 4S3_PROTOCOL=https
 5S3_BUCKET=your bucket name
 6S3_REGION=your bucket region
 7S3_HOSTNAME=your bucket hostname
 8S3_ENDPOINT=your bucket endpoint
 9AWS_ACCESS_KEY_ID=your bucket secret ID
10AWS_SECRET_ACCESS_KEY=your bucket secret key
11...

上面的变量代表 S3 接口连接参数. 请确保您使用对象存储提供商的正确 S3 映射连接参数。

然后保存并退出编辑器。

请确保在保存更改后重新启动 Web 服务(s):

1sudo systemctl restart mastodon-web.service

现在你知道如何在自动设置失败、人为错误或手动安装的情况下手动配置 Mastodon 对象存储。 对象存储将有助于降低 Mastodon Web 服务(s)的负载,并为您的服务器上的媒体文件提供更好的上传/下载速度。

扩展网站服务

网页服务是一个 Ruby-on-Rails HTTPS 服务器,服务 Mastodon UI 并处理用户的请求。网页服务的负载与活跃用户的数量直接比例,每个线程可以同时响应一个单一的请求。如果所有线程都忙碌,下一个请求必须等待。如果请求等待太长时间,则被取消时效错误。网页服务的瓶颈可以通过长期的请求处理时间来识别:页面打开缓慢,帖子创建有明显的延迟,或时效错误出现在日志上。

<$>[警告] 警告: Web 服务只执行 HTTPS,这意味着无法在多个托管 Web 服务的机器之间的负载平衡器上使用 SSL 终止。

要允许 Web 服务处理更多用户,您需要增加该服务使用的线程总量。 这样做可以通过增加 WEB_CONCURRENCY (工人数) 和/或 MAX_THREADS (每工的线程) 的环境变量。

增加MAX_THREADS倾向于消耗更多的CPU,而增加WEB_CONCURRENCY倾向于消耗更多的RAM。Mastodon版本 4.0.2的平均估计为1个工人2～3 GB的RAM。在上面的例子中,WEB_CONCURRENCY = 3所需的估计 RAM量为9 GB 对于MAX_THREADS,我们建议从一些通用值开始,如15,并增加它,直到平均使用70%的CPU。

<$>[注] 注: 以下是系统d Web 服务配置的示范片段。如果您正在使用其他技术来运行您的 Web 服务(Docker、K8s 等),则根据您的技术环境规格调整 WEB_CONCURRENCY 和 MAX_THREADS 变量。

首先,让我们打开 Web 服务文件:

1sudo nano /etc/systemd/system/mastodon-web.service

你会看到一个 Web 服务 systemd 文件,它看起来像这样:

 1[label /etc/systemd/system/mastodon-web.service]
 2[Unit]
 3Description=mastodon-web
 4After=network.target
 5
 6[Service]
 7...
 8Environment="LD_PRELOAD=libjemalloc.so"
 9ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
10ExecReload=/bin/kill -SIGUSR1 $MAINPID
11...
12[Install]
13WantedBy=multi-user.target

现在,添加两个额外的域,其中包含 WEB_CONCURRENCY 和 MAX_THREADS 变量,直接在 ExecStart 字段上方:

 1[label /etc/systemd/system/mastodon-web.service]
 2[Unit]
 3Description=mastodon-web
 4After=network.target
 5
 6[Service]
 7...
 8Environment="LD_PRELOAD=libjemalloc.so"
 9Environment="WEB_CONCURRENCY=your concurrency value"
10Environment="MAX_THREADS=your threads value"
11ExecStart=/home/mastodon/.rbenv/shims/bundle exec puma -C config/puma.rb
12ExecReload=/bin/kill -SIGUSR1 $MAINPID
13...
14[Install]
15WantedBy=multi-user.target

这些新字段将对 WEB_CONCURRENCY 和 MAX_THREADS 的默认值加以代替。

保存和退出编辑器。

请确保在保存更改后重新加载单元文件并重新启动服务:

1sudo systemctl daemon-reload
2sudo systemctl restart mastodon-web.service

<$>[注] **注:**自2017年以来,Web服务的性能几乎翻了一番,我们强烈鼓励每个人监控硬件的使用,以确定是否应该分配更多的或更少的资源。

在此时,您已经增加了 Web 服务配置的默认值,这使得您的 Mastodon 前端支持更多活跃的用户。 请记住,始终有一个额外的性能边缘,以确保您的 Mastodon 服务器不会受到大量用户的涌入。

增加流量流量

StreamingAPI 是一个托管实时更新 API 的 NodeJS 服务器. 它允许用户直接从服务器接收事件的流程. StreamingAPI 受到它可以同时服务的用户数量的限制. 限制取决于环境变量 STREAMING_CLUSTER_NUM。

如果类似于node[1201554]:ERR!错误:抱歉,客户端已经太多了在日志中出现,则意味着使用StreamingAPI的用户数量超过其处理能力,并且新用户会自动脱离连接。

扩展StreamingAPI非常简单 增加STREAMING_CLUSTER_NUM环境变量将允许StreamingAPI为更多用户提供服务 如果您在日志中看到大量的错误:对不起,已经有太多客户消息,请将STREAMING_CLUSTER_NUM增加 1.5x-2x 次 例如,如果当前的STREAMING_CLUSTER_NUM配置为 2,则更新变量为 4。

在运行 StreamingAPI 的机器上,打开 StreamingAPI 服务文件:

1sudo nano /etc/systemd/system/mastodon-streaming.service

编辑 STREAMING_CLUSTER_NUM 变量的值:

 1[label /etc/systemd/system/mastodon-streaming.service]
 2[Unit]
 3Description=mastodon-streaming
 4After=network.target
 5
 6[Service]
 7...
 8Environment="STREAMING_CLUSTER_NUM=your new value"
 9ExecStart=/usr/bin/node ./streaming
10...

保存文件并确保在保存更改后重新加载单元文件并重新启动服务:

1sudo systemctl daemon-reload
2sudo systemctl restart mastodon-streaming.service

此外,默认情况下,StreamingAPI 没有 DB_POOL 变量集. 没有这个变量,StreamingAPI 将使用 10 个连接。 明确增加 DB_POOL 变量而不增加 STREAMING_CLUSTER_NUM 变量,但如果您想要这样做,您可以简单地在 StreamingAPI 服务文件中创建一个新的环境变量。

在运行 StreamingAPI 的机器上,打开 StreamingAPI 服务文件:

1sudo nano /etc/systemd/system/mastodon-streaming.service

添加新的环境变量 DB_POOL:

 1[label /etc/systemd/system/mastodon-streaming.service]
 2[Unit]
 3Description=mastodon-streaming
 4After=network.target
 5
 6[Service]
 7...
 8Environment="DB_POOL=your value"
 9Environment="STREAMING_CLUSTER_NUM=your value"
10ExecStart=/usr/bin/node ./streaming
11...

保存文件并确保在保存更改后重新加载单元文件并重新启动服务:

1sudo systemctl daemon-reload
2sudo systemctl restart mastodon-streaming.service

这将取代 DB_POOL 的默认值,并为您的 StreamingAPI 实例提供需要多少数据库连接的更清晰的理解。

<$>[注] 注: 如果您没有明确指明 DB_POOL 的值,则在计算 max_connections 变量时使用值 10 作为 DB_POOL。

现在,您已经更新了 StreamingAPI 配置以允许更好的输出量,这将有助于您的 StreamingAPI 服务于更多的同时用户而不会失败。

结论

在本教程中,您已经学会了如何识别和解决PostgreSQL、Sidekiq、Web服务和StreamingAPI中的瓶颈,现在您可以 设置新服务器或扩展现有服务器。

扩展方法总是可以改进和改进,例如,复杂的Sidekiq配置可以(https://softwaremill.com/the-architecture-of-mastodon/)。 官方的Mastodon扩展(https://docs.joinmastodon.org/admin/scaling/)包含一些关于如何扩展和优化您的服务器的额外观点。

在您的服务器上改善用户体验的另一个很好的方法是使用ElasticSearch 启用(https://docs.joinmastodon.org/admin/optional/elasticsearch/)全文本搜索,这将允许用户从他们的状态,提及,喜好和标记中找到结果。

还可以将Mastodon翻译到用户语言的音符和其他信息,通过enablingLibreTranslate。

Published At
Categories with 技术
Tagged with
comments powered by Disqus