🍊柑橘 RSS 阅读器 - 鸿蒙首款原生 RSS 阅读器

之前我写过一篇文章来吐槽 Nextcloud 的性能问题。当时我是尝试在群晖上试用 Nextcloud。考虑到我使用的群晖服务器的 CPU 性能比价差，因此我尝试在 Unraid 上部署 Nextcloud。但是性能差的问题仍然没有改观。不过近期在 Unraid 发布了 6.12.0 版本以后这个问题得到了很大的改观。

问题分析

问题出在 shfs 这个进程上。在 Unraid 中，这个进程负责将分散在各个 Disk 上的文件夹内容聚合成一个统一的目录库，这意味着如果我们要访问任何文件都需要通过 shfs 来查找文件，这也使得 shfs 成文高吞吐率场景下的一个性能瓶颈。之前我经常可以看到 shfs 的 CPU 占用飙升到 100% 甚至 200%。在新版的 Unraid 中提供了 exclusive access 的特性。 Exclusive 的是排他性，独占的意思。Exclusive Access 是指固定将一个目录放在一个 Disk 中，这样我们在访问这个目录下的文件时，就不需要通过 shfs 来检索目录，而是可以直接访问磁盘上的目录系统，从而降低开销。

另一方面，Exclusive 也意味着这个目录无法有效的利用磁盘阵列提供的存储池，而只能利用单磁盘空间。因此，Nextcloud 的数据文件夹是不能使用 Exclusive Access 的。不过好在数据文件的访问其实并不是主要瓶颈，造成 Nextcluod 卡顿的主要原因在对容器挂载的配置文件（也就是 appdata）里面的众多小文件的高频读写。

另一个需要指出的是，在 Unraid 中，尽管缓存有多个 SSD，但是这些 SSD 会预先通过 Raid 机制聚合成一个统一的缓存磁盘，对于 Shfs 来说这个缓存池就是一个单一的磁盘，因此对缓存池的访问可以启用 Exclusive Access

如何使用

要是用 Exclusive Access，首先需要再 Settings --> Global Share Settings 下打开（如下图，将 Permit exclusive shares 设置为 yes）。

但是在共享目录使用时，Exclusive Access 的含义是比较模糊的。因为 Share 的管理界面并不会提供一个可以由用户可以直接控制的选项来为具体的 Share 开启 Exclusive Access。事实上，Exclusive Access 是否会起作用是系统根据目录的状态来自动确定的。如前文所述，Exclusive Access 作用的前提是数据只位于一个磁盘中。因此，在 Permit exclusive shares 启用的前提下，如果某个 Share 的文件只可能位于一个磁盘中，那么 Exclusive Access 将自动启用。

要实现 Share 的文件只属于一个磁盘中，需要满足一下条件：

Share 只启用了一个 Storage，没有 Secondary Storage
如果 Share 是存储在 Array 中的，在设置 Include disks 时只能选择一个磁盘；
如果是事先已经存在的目录，那么在满足上两条的情况下，还需要通过适当的 Mover 动作，将数据迁移到单一磁盘中。（注意如果之前 Share 是存在多个磁盘中时，做前两条修改，并不会自动将数据迁移到目标磁盘）

在本文的场景中，我们需要在 appdata 这个共享目录上启用 Exclusive Access，就可能需要进行必要的 Mover 操作。如果你看到 appdata 的 Share settings 页面中显示了如下 Exclusive access: no 的文字，进行如下操作：

出现这个状态，说明你的 appdata 并不完全位于缓存中，有一部分是位于阵列中的，此时我们需要让 Mover 将数据从阵列中移动到缓存中。注意：
1. 如果在现在的状态下，你的 appdata 是 Cache only 的，但是你仍然看到 Exclusive access: no，这是因为曾经某个时刻你为 appdata 设置了阵列存储的选项（以老版本的术语来说，就是 use cache 不是 only，而是 yes 和prefer 的选项），那么在那个时间段内，shfs 可能会将数据文件调度到阵列上。此时即便你讲 appdata 设置为 cache only，Mover 也不会自动将文件从阵列迁移到缓存。修改共享目录的这些相关设置只会影响新文件，而不会直接影响已有文件。
2. 在上面这种情况下，你需要首先恢复缓存-阵列两级缓存架构，然后将 Mover 行为设置为 prefer cache（在 6.12,0 的属于下，是将 Mover action 设置为 Array -> Cache。然后运行 Mover 完毕。这时 Mover 会将还停留在阵列上文件移动到缓存（当然前提是的缓存的空间要够）。
3. 完成上面的操作之后，我们再将 appdata 设置为 cache only 的形式（Primiary Storage 为缓存，无 Secondary Storage），这时我们应该能够看到 Exclusive access 变成了 yes。

结语

上面的这套操作，能够极大改善 Nextcloud 在 Unraid 上的表现。其他的应用也会有很大的改观（例如 Jellyfin 的打开和搜索速度会有质的提升）。

问题分析

另一方面，Exclusive 也意味着这个目录无法有效的利用磁盘阵列提供的存储池，而只能利用单磁盘空间。因此，Nextcloud 的数据文件夹是不能使用 Exclusive Access 的。不过好在数据文件的访问其实并不是主要瓶颈，造成 Nextcluod 卡顿的主要原因在对容器挂载的配置文件（也就是 appdata）里面的众多小文件的高频读写。

另一个需要指出的是，在 Unraid 中，尽管缓存有多个 SSD，但是这些 SSD 会预先通过 Raid 机制聚合成一个统一的缓存磁盘，对于 Shfs 来说这个缓存池就是一个单一的磁盘，因此对缓存池的访问可以启用 Exclusive Access

如何使用

要是用 Exclusive Access，首先需要再 Settings --> Global Share Settings 下打开（如下图，将 Permit exclusive shares 设置为 yes）。

要实现 Share 的文件只属于一个磁盘中，需要满足一下条件：

Share 只启用了一个 Storage，没有 Secondary Storage
如果 Share 是存储在 Array 中的，在设置 Include disks 时只能选择一个磁盘；
如果是事先已经存在的目录，那么在满足上两条的情况下，还需要通过适当的 Mover 动作，将数据迁移到单一磁盘中。（注意如果之前 Share 是存在多个磁盘中时，做前两条修改，并不会自动将数据迁移到目标磁盘）

出现这个状态，说明你的 appdata 并不完全位于缓存中，有一部分是位于阵列中的，此时我们需要让 Mover 将数据从阵列中移动到缓存中。注意：
1. 如果在现在的状态下，你的 appdata 是 Cache only 的，但是你仍然看到 Exclusive access: no，这是因为曾经某个时刻你为 appdata 设置了阵列存储的选项（以老版本的术语来说，就是 use cache 不是 only，而是 yes 和prefer 的选项），那么在那个时间段内，shfs 可能会将数据文件调度到阵列上。此时即便你讲 appdata 设置为 cache only，Mover 也不会自动将文件从阵列迁移到缓存。修改共享目录的这些相关设置只会影响新文件，而不会直接影响已有文件。
2. 在上面这种情况下，你需要首先恢复缓存-阵列两级缓存架构，然后将 Mover 行为设置为 prefer cache（在 6.12,0 的属于下，是将 Mover action 设置为 Array -> Cache。然后运行 Mover 完毕。这时 Mover 会将还停留在阵列上文件移动到缓存（当然前提是的缓存的空间要够）。
3. 完成上面的操作之后，我们再将 appdata 设置为 cache only 的形式（Primiary Storage 为缓存，无 Secondary Storage），这时我们应该能够看到 Exclusive access 变成了 yes。

结语

上面的这套操作，能够极大改善 Nextcloud 在 Unraid 上的表现。其他的应用也会有很大的改观（例如 Jellyfin 的打开和搜索速度会有质的提升）。

问题分析

另一方面，Exclusive 也意味着这个目录无法有效的利用磁盘阵列提供的存储池，而只能利用单磁盘空间。因此，Nextcloud 的数据文件夹是不能使用 Exclusive Access 的。不过好在数据文件的访问其实并不是主要瓶颈，造成 Nextcluod 卡顿的主要原因在对容器挂载的配置文件（也就是 appdata）里面的众多小文件的高频读写。

另一个需要指出的是，在 Unraid 中，尽管缓存有多个 SSD，但是这些 SSD 会预先通过 Raid 机制聚合成一个统一的缓存磁盘，对于 Shfs 来说这个缓存池就是一个单一的磁盘，因此对缓存池的访问可以启用 Exclusive Access

如何使用

要是用 Exclusive Access，首先需要再 Settings --> Global Share Settings 下打开（如下图，将 Permit exclusive shares 设置为 yes）。

要实现 Share 的文件只属于一个磁盘中，需要满足一下条件：

Share 只启用了一个 Storage，没有 Secondary Storage
如果 Share 是存储在 Array 中的，在设置 Include disks 时只能选择一个磁盘；
如果是事先已经存在的目录，那么在满足上两条的情况下，还需要通过适当的 Mover 动作，将数据迁移到单一磁盘中。（注意如果之前 Share 是存在多个磁盘中时，做前两条修改，并不会自动将数据迁移到目标磁盘）

出现这个状态，说明你的 appdata 并不完全位于缓存中，有一部分是位于阵列中的，此时我们需要让 Mover 将数据从阵列中移动到缓存中。注意：
1. 如果在现在的状态下，你的 appdata 是 Cache only 的，但是你仍然看到 Exclusive access: no，这是因为曾经某个时刻你为 appdata 设置了阵列存储的选项（以老版本的术语来说，就是 use cache 不是 only，而是 yes 和prefer 的选项），那么在那个时间段内，shfs 可能会将数据文件调度到阵列上。此时即便你讲 appdata 设置为 cache only，Mover 也不会自动将文件从阵列迁移到缓存。修改共享目录的这些相关设置只会影响新文件，而不会直接影响已有文件。
2. 在上面这种情况下，你需要首先恢复缓存-阵列两级缓存架构，然后将 Mover 行为设置为 prefer cache（在 6.12,0 的属于下，是将 Mover action 设置为 Array -> Cache。然后运行 Mover 完毕。这时 Mover 会将还停留在阵列上文件移动到缓存（当然前提是的缓存的空间要够）。
3. 完成上面的操作之后，我们再将 appdata 设置为 cache only 的形式（Primiary Storage 为缓存，无 Secondary Storage），这时我们应该能够看到 Exclusive access 变成了 yes。

结语

上面的这套操作，能够极大改善 Nextcloud 在 Unraid 上的表现。其他的应用也会有很大的改观（例如 Jellyfin 的打开和搜索速度会有质的提升）。