Step 1: delete unused large rooms

Step 1.1: Find large rooms

SELECT r.name, s.room_id, s.current_state_events
    FROM room_stats_current s
    LEFT JOIN room_stats_state r USING (room_id)
    ORDER BY current_state_events DESC
    LIMIT 20;
SELECT rss.name, s.room_id, COUNT(s.room_id)
    FROM state_groups_state s
    LEFT JOIN room_stats_state rss USING (room_id)
    GROUP BY s.room_id, rss.name
    ORDER BY COUNT(s.room_id) DESC
    LIMIT 20;

https://matrix-org.github.io/synapse/latest/usage/administration/useful_sql_for_admins.html#show-top-20-larger-rooms-by-state-events-count

Step 1.2: Use Admin API Purge the unused large rooms

https://matrix-org.github.io/synapse/latest/admin_api/rooms.html#version-2-new-version

curl "http://localhost:8008/_synapse/admin/v1/rooms/${ROOMID}" -X DELETE -H 'Accept: application/json' -H 'Referer: http://localhost:8080/' -H "authorization: Bearer ${TOKEN}" --data '{ "purge": true, "message": "Sorry - kicking you out to clean up the database" }'

Step 1.3: Delete orphan state_groups_state and state_groups

After using the Admin API to purge the rooms, but only removes the data in the events table, and there are still a lot of related room data in the state_groups_state and state_groups tables (the main space occupation). This may be a synapse bug.

So you need to remove them manually.

https://github.com/matrix-org/synapse/issues/12821#issuecomment-1295773504

DELETE FROM
state_groups_state
WHERE
room_id IN (
    SELECT
    DISTINCT(state_groups.room_id) AS room_id_gone
    FROM
    state_groups
    LEFT JOIN events USING(room_id)
    WHERE
    events.room_id IS NULL
    GROUP BY
    room_id_gone
);
DELETE FROM
state_groups
WHERE
room_id IN (
    SELECT
    DISTINCT(state_groups.room_id) AS room_id_gone
    FROM
    state_groups
    LEFT JOIN events USING(room_id)
    WHERE
    events.room_id IS NULL
    GROUP BY
    room_id_gone
);

Step 2: Run synapse_auto_compressor

https://github.com/matrix-org/rust-synapse-compress-state

git clone https://github.com/matrix-org/rust-synapse-compress-state.git

cd rust-synapse-compress-state/
cargo build -r

cd synapse_auto_compressor/
cargo build -r

cd ../target/release/

./synapse_auto_compressor -p postgresql://synapse_user:[password]@[host]/synapse -c 1000 -n 10000000 | tee ~/synapse_auto_compressor.log

Step 3: Vacuum Database

REINDEX (VERBOSE) DATABASE synapse;
VACUUM FULL VERBOSE;

Before:

/images/2023/how-to-clean-up-the-synapse-database/01.thumbnail.png

After:

/images/2023/how-to-clean-up-the-synapse-database/02.thumbnail.png

现在,你可以在 Linux 下通过 Proton (Steam Play) 来运行一些只支持 Windows 平台的游戏。比如说各类 RPGMaker 游戏。

但运行 RPGMaker 游戏,可能会出现一些图像问题,例如:黑屏、花屏等。

/images/2023/proton-rpgmaker/01.png

Read more……

很早之前写过一篇《使用 Nginx 反代 Mastodon》,但那篇主要指对没有站点管理权的情况下如何添加反代域名,而且年代久远一些内容也需要更新。

应嘎嘎的要求,今天特别写一篇博文讲一讲 Mastodon 域名设置相关的内容。

本文篇幅可能会比较长,前半部分将大致讲解 Mastodon 的架构以及域名相关设置,后半部分将讲解如何更换 WEB_DOMAIN、如何添加反代域名。

Read more……

本文最开始发布于本人的Mastodon帐户(链接),最初的发布时间是2020年8月7日。

时间已经过去两年多了,本文中的内容也有一些不太适用的地方,但总体上仍然适用。

Read more……

在与众多嘟友有关Apple公司的讨论中,我突然想到,我们心中应当有一条容忍的底线,当有人越过了这条底线,我们便应该抵制与坚绝的拒绝它。无条件的妥协与退让,只会带来得寸进尺,以及最终退无可退而致灭亡的结局。


如果你同意上面的内容,那让我们继续。

我认为这条底线是:不伤害,即对方不能主动恶意侵害我们。


如今各个互联网公司主动侵害用户的利益,似乎已经成为一种惯例,大概是数据的虚拟性麻痹了使用者的大脑,抑或是久在鱼肆不闻其臭,很多被侵害的用户都习以为常了,甚至为侵害者辩护起来。

如果你认为各个互联网公司干的事情没有什么不对的,那让我们简单替换一下主语。

不想打扫房间,所以请了一个保洁员,这个保洁员不但干活麻利,还要价便宜。但有一天,你发现这个保洁员偷偷地把你房间中你的物品偷去卖钱;如果你说偷东西卖钱涉及实物性质不一样,那就换一个,你发现这个保洁员在你的房间中装了很多针孔摄像头,卫生间、卧室都装的有。对于这样的一个保洁员,即使他要价再低,干活干的再好,相信你都会毫不犹豫的辞退他。

那为什么同样性质的行为,替换一个主语,就要采取不一样的行为呢?


就苹果公司而言,当它主动向用户推送恶意更新,降低旧机型CPU频率,劣化用户体验时。

这家公司便已经跨过那条不可容忍的底线了!


原嘟文地址:https://bgme.bid/@bgme/105226302089936130