#实例维护 — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #实例维护, aggregated by home.social.
-
-
-
BGME 实例升级完毕已经近两周了，这里想问一下，在搜索选项方面是保留现在的默认设置 in:all （即搜索时同时显示公共嘟文索引以及私有嘟文索引），还是改为默认设置 in:library（即只显示私有嘟文索引）？
关于搜索选项，这里简单说明一下。
v4.2[1] Mastodon对搜索功能进行了较大的调整（图三），具体而言分为两个方面。方面一：添加了PublicStatusesIndex
v4.2 之前，Mastodon 虽然也有搜索功能，但默认只能搜索自己的嘟文以及自己互动过（转发、喜欢、收藏、回复）的嘟文。并不存在新浪微博、推特这些微博客平台可以搜索所有人发言的公共搜索功能。
v4.2 版本添加 PublicStatusesIndex 索引，即对于勾选了「将公开嘟文纳入搜索范围」选项（图一）的用户，对其公开嘟文建立索引，用户搜索时这部分内容（PublicStatusesIndex）将连同之前的StatusesIndex内容一同出现在搜索结果中。方面二：添加了搜索参数
添加了 has、is、from、language、before、during、after、in 等搜索参数（图二）。通过这些搜索参数，可以更为精确的搜索相应嘟文。
这里需要添意的是 in 参数。in:library 表示只搜索 StatusesIndex ，即只搜索自已的嘟文以及自己互动过的嘟文。in:public 表示只搜索 PublicStatusesIndex，即前文提到的公共嘟文索引。in:all 则是同时搜索 PublicStatusesIndex 与 StatusesIndex 。Mastodon 默认设置是 in:all ，之前 BGME 实例通过修改代码，将默认设置改为 in:library 以保持与 v4.2 之前版本的行为一致。
但本次升级之后，并没有修改 in 参数设置，这也是升级之后很多嘟友发现可以搜索出其它人嘟文的原因。BGME 实例上的嘟友，你觉得是默认搜索参数是保留现在的 in:all，还是回归之前的 in:library？
这条嘟文下面将会有一个投票，你可以进行投票选择。[1] https://github.com/mastodon/mastodon/releases/tag/v4.2.0
-
CW: 为节省开支，bgme.me 实例计划将媒体文件迁移至 Jortage 项目
# Jortage 项目是什么？
Jortage 是为 Fediverse 设计的社区共享媒体存储计划。
由于 Mastodon 缓存远程实例媒体文件的机制，Fediverse 不同实例间的媒体文件存在相当多重复部分，如果将部分重复文件去重，将节省大量存储空间。正如 Jortage 项目页面上所写的那样，去重前 138.25TiB，去重后只有 62.99TiB。
关于 Jortage 项目的更多信息，可以阅读：https://jortage.com/# bgme.me 实例为什么要将媒体文件迁移至 Jortage 项目？
最大的原因是为了节省开支。
目前 bgme.me 实例的媒体文件 S3 桶大小已达 12.16TB （图一，2025年9月19日截图）。
即使 bgme.me 使用的相对便宜的 S3 服务商（wasabi，$6.99 TB/month），这仍然是一笔不小的开支。
上月（2025年8月） Mastodon 媒体文件相应 S3 桶支出 $86.62。（图二）
更大的问题是：媒体文件大小还以大约每日10GB的速度增加着。# bgme.me 实例媒体文件为什么这么多？
绝大多数媒体文件都是远程实例的本地缓存，bgme.me 并没有像很多实例那样定期清理远程实例媒体缓存。
$ RAILS_ENV=production bin/tootctl media usage
Attachments: 10.1 TB (411.3 GB local)
Custom emoji: 8.1 GB (41.7 MB local)
Preview cards: 455.3 GB
Avatars: 47.0 GB (268.5 MB local)
Headers: 99.9 GB (509.8 MB local)
Backups: 142.7 MB
Imports: 1.8 KB
Settings: 2.2 MB# bgme.me 实例为什么不定期清理远程实例媒体缓存？
bgme.me 实例最开始的时候也是像大多数 Mastodon 实例一样定期清理远程媒体文件缓存的。
但 Mastodon 早期版本 tootctl media remove 存在 BUG，运行 tootctl media remove 提示你清理了多少多少G的媒体文件，但仅仅将这些文件从数据库中移除，并没有将这些文件从实际存储系统（本地磁盘、S3）中删除。
（这个BUG导致的实际磁盘空间未释放的问题，现在版本可以通过 tootctl media remove-orphans 命令释放早期这些未被释放的空间。）
tootctl media remove 不起作用，媒体文件越积越多，本地磁盘是放不下了，那就只有上 S3 了。
S3 出于性价比考虑，选择了比较经济的 wasabi 。
wasabi 虽然只收存储费用，不收流量费，也不收 API 调用费，但wasabi 存在一个起步价，空间占用不足 1 TB 时，按 1 TB 进行收费。
当时 bgme.me 还是一个非常非常小的实例，离用满 1 TB 还有不小的距离，再加上 tootctl media remove 存在 BUG，索性就不清理远程媒体文件了。那为什么后来不清理远程实例缓存媒体文件呢？尤其是在 tootctl media remove 的 BUG 被修复了之后。
这里就必须要提一下旧草莓县（cmx.im）的突然关站了。
旧草莓县作为当时中文 Fediverse 为数不多的大型实例，它的突然关站对于整个中文 Fediverse 的影响是巨大的。
当然最直接的影响就是旧草莓县上既往嘟文直接上天了，再也访问不到了。
得益于 Fediverse 的去中心化架构以及缓存机制，虽然原实例消失了，通过其它实例的缓存，你还是可以找回一部分内容的。
但这也仅仅限于文字部分，由于大多数 Mastodon 会定期清理远程媒体文件，这使用对于旧草莓县的带图嘟文，往往只留下文字，图片却再也看不见了。
也就是在这个时候，我意识到，我由于没有清理远程媒体文件，而留下的这些旧草莓县媒体文件，可能是旧草莓县为数不多的遗迹了。也就是在这个时候，我做出了不再清理远程实例媒体文件的决定。因此，即使是在旧草莓县突然关站数年后的现在，你仍然可以在 bgme.me 实例上查看到当年旧草莓县的帐户以及旧草莓县的嘟文。就像图三那样，图文并貌，栩栩如生的查看。
如果你是 bgme.me 本站用户，可以访问 https://bgme.me/@[email protected]/101758729419349975 查看图三中的嘟文。
# 为什么 bgme.me 实例不开通捐赠？
之前考虑过开通一个 Patreon 以缓解实例的经济压力。后来因为种种考量，最后放弃了这个想法。
# Jortage 项目靠谱吗？
Jortage 项目已经运行至少5年，目前项目经济状况良好，收支平衡，相信未来可以继续运行。
2025年8月 Jortage 项目收支情况：https://sleeping.town/@unascribed/115127391015794735此外，moresci.sale 目前已经使用了 Jortage 项目。
# 迁移至 Jortage 对实例用户的使用有影响吗？
不会影响用户正常使用。
迁移过程中可能出现无法导出用户存档的情况，待迁移完成，一切使用将恢复正常。 -
接服务器运营方通知，因硬件维护，本站将于2025年9月15日1:00-3:00 UTC+8短暂下线，带来不便敬请各位谅解。
-
接上游服务商通知，BGME实例所在服务器将于 2024-12-20 20:00-21:00 UTC 进行服务器维护，届时BGME实例下线约1小时。
敬请各位谅解。 -
虽然有一些波折，但总算是将服务迁移到了新服务器上了。
bgme.bid 访问入口，因一些原因，暂未能上线。
此外，全文搜索功能暂未上线。 -
BGME 实例最近接收到 希奇！https://c7.io ( @snullp ) 捐赠的服务器一台。
计划于2024年11月3日进行Mastodon相关服务的迁移工作，届时将会有数小时的服务中断，敬请各位绒友注意。 -
Mastodon 加了 Public Status index 之后，搜索默认会在 PublicStatusesIndex + StatusesIndex 中进行搜索。
实际体验之后就会发现，这样的做法带来了一个极其严重的问题。
少数开启 Include public posts in search results 帐户的嘟文，会高频出现在搜索结果中。
而且排序时，自己的嘟文、自己互动过的嘟文也并没有获得更高的排序优先级。并不是 StatusesIndex 结果显示完了，才会显示 PublicStatusesIndex 的结果。两者的搜索结果会混在一起。如果你搜索的关键词，恰好你自己相关（自己发的、自己互动过的）的嘟文较少，那就惨了，搜索结果中一大堆公共嘟文，由于目前升 v4.2.0-beta3 实例极少，修改默认设置允许 Include public posts in search results 的帐户更少。实际上的体验就是，无论你搜什么关键词，某几个帐户的嘟文总是出现在搜索结果中。
体验相当相当差劲，甚至可以说是恶心了。因此，BGME 实例对搜索功能进行了一定修改，反转了 in 参数的作用。
将默认从 PublicStatusesIndex + StatusesIndex 中进行搜索，加入 in:library 参数后从 StatusesIndex 中进行搜索。
变成为默认从 StatusesIndex 中进行搜索，加入 in:public 参数后从 PublicStatusesIndex + StatusesIndex 中进行搜索。 -
-
BGME 实例已升级至 v4.2.6-beta3。
因全文搜索索引结构变更，需重建 elasticsearch 索引。
索引重建期间（预计耗时30小时），搜索功能可能无法正常使用。
敬请各位嘟友谅解。
#实例维护 -
因Mastodon服务压力较大，自昨晚（16:59 PM UTC）暂时关闭了MatrIx相关服务（matrix-synapse、mautrix-telegram、matrix-media-repo、matrix-dimension）。
目前正在将Matrix相关服务迁移至新服务器。
敬请各位嘟友谅解。
#实例维护 -
bgme.me 实例已升级至 v4.0.0rc1 版，升级期间实例短时间下线，现已恢复。
v4.0.0rc1 版主要更新内容：
- 允许用户关注 Tag （图一）。
- 添加嘟文翻译支持（需实例管理者添加 DEEPL_API_KEY 或 LIBRE_TRANSLATE_API_KEY）
- 修改流行嘟文语言过滤规则，由用户界面语言更改为所选倾向语言。（图二）
- 修改默认语言过滤规则，如用户未手动选择倾向语言，默认以当前界面语言过滤嘟文，而非显示所有语言嘟文。（图二）
- 修改嘟文过滤系统- 修改图标颜色及样式
- 大幅修改Web界面
- 在Web界面启用嘟文编辑功能（bgme.me 在此前便已经启用嘟文编辑功能）详细变更日志可参见：https://github.com/mastodon/mastodon/releases/tag/v4.0.0rc1
-----------------------
v4.0.0 是一个全新的大版本，目前尚未正式发布。
各位嘟友，如果对于新版本有任何吐嘈或建议都可以在此条嘟文下留言交流。 -
【bgme.me 10月31日访问故障说明】
因 bgme.me 域名濒临过期（2022-11-01 04:34:21 UTC 过期），2022-10-31 08:53:00 UTC 域名服务商 NameSilo 将 bgme.me 的 Name Server 变更为 NS1.DNSOWL.COM、NS2.DNSOWL.COM、NS3.DNSOWL.COM，而导致访问故障。根据监测结果，最早 2022-10-31 13:10:13 UTC 监测到 bgme.me 子域名出现访问故障。
2022-11-01 00:55:42 UTC 完成 bgme.me 域名续期，Name Server 记录恢复正常，访问故障原因解除。
但由于DNS各级缓存存在，bgme.me 访问故障可能仍会持续数小时或数天。
由于 NS 记录的 TTL 为 172800 (48小时)，bgme.me 访问故障最长可能持续至 2022-11-03 01:00 UTC。 -
-
-
-
可能已经有嘟友发现 bgme.bid 域名上不去了。
刚刚排查了一下，这并不是 bgme.bid 域名被墙了，而是 bgme.bid 的那台服务器流量用尽，被服务商停机了。
:aru_0171: :aru_0171: :aru_0171:正着手找新的跳板服务器。
在此之前敬请各位嘟友见谅，可以先暂时使用 0rz.one 这个域名（注意第一个字符是数字 0，在不是字母 O）。
#实例维护 -
【关于 BGME 实例被墙一事】
大约在2022年6月9日15:00 （UTC+8:00）， bgme.me 域名及其子域名， bgme.bid 部分子域名（如 img.bgme.bid 域名）遭到 GFW 的 DNS 投毒污染攻击。如果您遇到了访问故障，你可以使用备用域名 https://bgme.bid 及 https://0rz.one 进行访问。
如有更多问题，可联系管理员 @bgme 。
-
将BGME实例的电子邮件发送服务迁移到 Amazon SES，收不到注册邮件的问题应该不会再出现了。
如果你是实例管理者，你现在也为 SMTP 发件服务而烦恼，你也许可以考虑 Amazon SES ，低廉的价格（图一），多达十余个可选发信区域（图二），。
如果你现在的服务器正在使用 Amazon EC2 ，那么每月可免费发件 62,000 封，超出部分每1000封 $0.10。即使不使用 Amazon EC2，享受不到免费额度，按量支付，每1000封 $0.10的价格，相较 mailgun、sendgrid 等发件服务也有一定的价格优势。此外，如果你是新注册用户，还可以享受 Amazon 众多免费试用（图三），其中便包含为期12个月，每月750小时（31.25日）的 Amazon EC2，每月 1TB 的 Amazon CloudFront 流量。
对于小型实例而言，免费额度基本上满足日常需求。需要注意的是：Amazon 注册时需绑定 MasterCard 或 Visa 信用卡，并会进行扣费测试。
此外，Amazon 的流量费用较贵，如使用 CloudFront 等流量计费产品，需小心遭到攻击，而产生天价帐单。
#实例运维 #实例维护 -
由于大量用户涌入，BGME实例出现持续高负载状态（图一），影响用户正常使用，刚刚进行了一次服务器扩容，期间下线约3分钟，现已恢复。
但目前仍有部分堆积任务等待处理（图二），期间可能会出现上传图片需等待较长时间等问题。
敬请各位谅解。此外，你也可关注 @bgme 在 mastodon.social 实例的帐户 @[email protected] 以便在服务器出现访问故障时接收公告。
#实例维护 -
【关于bgme.me实例刚才下线的说明】
刚才为了解决与 2to2.xyz 实例的通迅问题，变更Mastodon的配置。
然后重启服务，发现 mastodon-web 服务无法启动，报错：warning: already initialized constant Net::ProtocRetryError通过关键词搜索，找到如下两个 issue：
https://github.com/mastodon/mastodon/issues/16353
https://github.com/ruby/net-imap/issues/16
经阅读，发现这个问题更新ruby版本之后依赖有关。而且所有的“Docker”用户也受到这个问题的影响。
官方的建议是：直接升级到主线版本。尝试升级至主线版本，编译静态文件时出错，提示：/home/mastodon/live/vendor/bundle/ruby/2.7.0/gems/ffi-1.15.3/lib/ffi/library.rb:112: [BUG] Segmentation fault at 0x000│00000000ed028
经搜索发现这个issue：
https://github.com/mastodon/mastodon/issues/15751
阅读完整个issue，大致了解到这是ruby自身的bug，升级到 Debian 11 Bullseye 便会触发。要想彻底解决掉这个bug，需要上游修复。
按照里因的建议，完全重新安装ruby以及mastodon，临时设置 LD_PRELOAD=libjemalloc.so 环境变量解决了此问题。总而言之：
v3.4.1 这个版本已经不太稳定，如果现在新安装 Mastodon 的话，建议直接安装主线版本。
此外，如果你的实例打算升级系统版本，要特别小心。 -
-
根据监测记录，本站主域名 bgme.me 以及图片域名 img.bgme.me，今日（2021-3-4） 8:10 至 11:20 （CST）在中国大陆的访问出现故障。
#实例维护 -
将 img.bgme.me 的反代关了试一试，使用 bgme.me 域名的嘟友，图片加载情况相比之前有什么变化吗？
变慢了？变快了？没什么变化？
#实例维护 -
-
自建实例的同学，请务必添加如下两个定时任务，推荐在每天早晨低峰时段运行
RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove --days=14
清理缓存的外站媒体文件，和
RAILS_ENV=production /home/mastodon/live/bin/tootctl media remove-orphans
清理未关联任何 toot 的“无主”媒体文件
另外推荐配合以下任务食用
RAILS_ENV=production /home/mastodon/live/bin/tootctl statuses remove
清理没有同本站任何用户产生关联的 toot 本身（比如跨站轴上收到的、没有本站用户转发/评论/收藏过的消息）
各命令参数请参考 -h 和官方文档按实际情况调整：https://docs.joinmastodon.org/admin/tootctl/
您的钱包会感谢我的╮(￣▽￣")╭
