技术宅的假期：AI-Mesh、J1900平台PVE+群晖+LEDE、内网穿透

创作立场声明：本文过于偏技术向，感谢耐心看完。也感谢所有的让我站在他们的肩膀上的大神。

前言

这个春节因为新冠肺炎的原因，成为我有生以来过的最为特殊的一个春节。因为宅在家里实在是无聊，就把家里的无线+NAS系统整个重新弄了一遍。

一、无线优化：华硕AC86U+华硕AC1750 B1组Ai-Mesh

1.1、现有无线系统介绍

家里的无线原本是用的华为Q2子母套装+小米路由器R2D的组合，组合的方案是Q2母路由放在A点的弱电箱内，子路由放在B点插座，小米路由器R2D通过LAN口接在C点当AP使用。

家里的WIFI设备主要包括：小米净水器、客厅空调、手机5台、iPad 2台、MacBookPro、明基GV1、风行电视、爱奇艺电视果4K、小米智能插座等。其中小米净水器固定在厨房的橱柜内，因为遮挡较多，是个弱信号设备。

Q2子母套餐的SSID为SSID-A，小米路由器R2D的SSID为SSID-B，两套路由器的SSID并有设置一致，因为主卧的小米路由器R2D主要是给自己卧床打王者用的，所以为了避免出现切换失败之类的情况，设置不同的SSID，每次进主卧之后检查一下连的是不是SSID-B，如果不是的话，手动切换一下再玩。

SSID-A则是给家里人用，但是有一个问题：因为Q2的子母路由器是通过电力线进行连接，母路由因为放在弱电箱里，所以是插在弱电箱内的插座上，然后因为家里的房子是精装修的，估计用的电线也不是特别的好，电力线只能跑到70M左右，如果遇上用电高峰，还会降到10几M这样，并且电力线的延迟也比较高，这就造成了在主卧内，如果连的SSID-A，无线的体验并不是特别好。同时，Q2子母套装的本质其实是母路由跟子路由使用同一个SSID，但并不是mesh，WIFI切换只能靠无线终端自己根据信号强度来判断，因此切换很慢，有时甚至出现WIFI信号在很差的水平上维持着一直不切，严重影响体验。

同时，在这个方案里，与主卧仅一墙之隔的次卧2莫名的WIFI信号特别特别的差，究其原因，可能是因为B点的华为Q2子母路无线功率不够，C点的小米路由器R2D往D点的方向正好被台式主机挡住信号。目前次卧2是我父亲在住，老人家平时用在客厅用明基GV1投影仪看剧，晚上便直接把投影连三角架拿到房间接着看，还好明基GV1的WIFI比较给力，虽然信号差，但勉强能看视频。

最后要提一下的是E点的卫生间，作为一个现代人，蹲马桶刷抖音是每天必做的功课之一。但是，因为E点位置的问题，ABC三个点到达E点的直线路程上都要穿好几道墙，特别是B点，还是以近30度角穿过去，所以E点只能连上A点的2.4G WIFI勉强使用。

原本我觉得这个方案也是勉强可用没问题的，但是家人经常跟我吐槽WIFI卡，呃，WIFI卡我自己分析了一下，主要是这两个原因：华为Q2路由本身的性能较低，而且可能还不支持MU-MIMO（官方宣传跟说明文档都没提），所以在10+的WIFI带机量之下，性能有点吃力，而且终端里还有小米净水器这样的弱信号设备，所以会出现即使WIFI信号满格还是卡顿的情况。实际测试中，我用手机蹲在A点的弱电箱边上通过5G连Q2母路由，实际下载速度为230Mb/s，跑不满家里的300M宽带（在主卧测速能到340Mb/s）。

1.2、无线优化方案

于是，在经过多方综合考虑之后，决定购入华硕AC86U+AC66U B1/AC1750 B1的组合。

[咨询优惠+天猫直送]asus华硕路由器RT-AC86U企业级无线商用家用2900M高速wifi千兆端口5G穿墙王智能宽带梅林699.81元天猫精选去购买

AC86U是先入手的，当时考虑的是，如果AC86U的WIFI能够实现全屋覆盖，那就可以省下一个AC66U B1的钱了。入手渠道天猫，凑单用了88VIP的满1000-100数码券，加上店铺优惠，实际入手价格为699.81元（就按700算吧）。算是好价。

华硕（ASUS）RT-AC1750B1无线路由器1750M双频全千兆低辐射/智能游戏路由器高速路由RT-AC66UB1**版479元京东去购买

AC86U买回来一加电，我就意识到自己还是太想当然，主卧几乎无信号，不得以，还是得再买台路由器组mesh。华硕支持Ai-Mesh的最便宜的路由器是AC66U B1跟AC1750 B1（这两个其实是同一个产品的换壳版），当时京东AC1750 B1比AC66U B1便宜50块，就下单了AC1750 B1，用了Plus会员的500-20券，然后正好赶上光大信用卡的499-50，最终入手价是479元，也是好价了。

AC86U的个头很大，把天线放平之后，非常勉强地挤进去了客厅A点的弱电箱。当然这样做AC86U的WIFI信号多少会受到影响，但是为了美观+便于收纳便只好进行取舍了。

AC1750 B1目前是直接放在B点的电视机移动支架下边，现在家里太挤，电视机基本就是长期放在主卧，移动支架有点投资浪费了 。线有点乱，拖延症患者还没打定决定去收拾。

最终的WIFI系统的TOPO如下：

两台路由器的使用方案为：AC86U刷Koolshare改版梅林固件，AC1750 B1使用原厂固件，然后组有线回程方式Ai-Mesh。华硕Ai-Mesh的配置方式非常简单，主路由LAN口插节点路由WAN口，然后在主路由上搜索节点即可一键完成配置，限于文章篇幅，就不详述了。

1.3无线升级效果

这个截图时间是晚上8点，正好是家里的WIFI使用高峰，可以看到总用户数22个，其中Mesh节点路由用户数12个。

家中无线方案升级为华硕Ai-Mesh系统之后，客餐厅、主卧、次卧1、次卧2均实现了5G信号覆盖。其中，客餐厅、主卧、次卧1均可跑满300M宽带（实测340Mb/s），次卧2可以跑到280Mb/s（老父亲看剧绰绰有余）。但是卫生间的E点实在是位置太差，做不到5G信号覆盖，只能跑2.4G，实测速度70-80Mb/s，但是好在延迟也在10ms内，刷抖音足够了。

家中基本实现全屋5G无线覆盖，本次无线优化也算是比较成功的。总共花费为700+479=1179元。

二、J1900主机安装PVE+群晖+LEDE（附NAS数据恢复）

2.1不太成功的群晖6.2.2版本升级

家中的无线折腾完之后，我便在vultr租了个VPS玩，搭了ss+ssr+v2ray全套。。。结果发现AC86U跑v2ray有点费劲，于是便开始想解决方案。原本想在J1900的黑群上用VMM装LEDE做旁路由，结果家里的黑群还是史前的DS3617xs 6.1.1版本，并不支持VMM，然后折腾了一番Docker无果，便头铁直升6.2.2，结果当然是喜闻乐见的挂了。

折腾了老半天的6.2.2引导U盘，始终不是很顺利，最后终于解决了：不能使用UEFI引导，只能Legacy引导。

方案：

使用引导文件：DS3617_boot_1.03b_6.22.img

用Win32DiskImager将引导文件写入U盘，通过chipeasy查看U盘的vid跟pid，通过DiskGenius访问U盘的EFI文件夹，将其中的grub.cfg中的vid跟pid改为自己U盘的vid跟pid（洗白的话，也是在这里修改sn跟mac）

将U盘插入J1900主机的USB口，通过Legacy方式进行引导。如果引导还有问题的话，可以考虑通过DiskGenius访问引导U盘的第二个隐藏分区，下载大神做的扩展驱动包extra.lzma进行替换以排除驱动问题。

引导成功之后，因为我的群晖是从6.1.1升级上来到6.2.2最新版本的，还遇上了登陆DSM时提示“您没有权限使用本项服务”的问题。在手机上试了一下safari可以正常登陆，于是尝试使用Firefox、Chrome等不同的浏览器进行登陆，最终在Chrome上成功登陆。

不过，这个问题没有完全解决，因为我遇上了另一个问题：J1900主机重启之后，依然发生失联的情况。接上显示器后发现主机重启之后又自动进入了UEFI引导方式，然后在BIOS中也没找到这块主板关闭UEFI引导的选项，看来是解决不了了。（写文章写到这里，突然起来还有一个方案可以试一下：将U盘的分区表从GUID改为MDR或许可以解决，妹的，当时怎么没想到啊！现在已经迟了 )

2.2、NAS数据恢复

因为U盘引导的问题当时无法解决，所以DSM登陆问题也没来得及解决了。再加上黑群用了这么久了，想换个方式换个玩法，于是便决定用PVE+群晖+LEDE的方案。而且，我的J1900主机是一个比较奇葩硬盘组合：1T+2T组了一个Raid1（最终空间只有1T）——嗯，因为当时刚装黑群的时候想着1T空间先用着，以后空间不够用了再把1T的那个硬盘换成2T的，这样就有2T的Raid1了，结果因为小主机用的是笔记本硬盘，眼睁睁看着希捷2T硬盘在购物车里放了快2年了价格依然坚挺，贫穷让我理智，还是继续等吧。正好趁着换方案不再用Raid1了，改用Basic方案吧，这样NAS空间就不用那么捉襟见肘了。

不过，在换方案之前，我得先把群晖盘里的数据先恢复出来。因为是Raid1，所以只需要拆下来其中一块硬盘即可完成数据恢复。

恢复方案

下载一个ubuntu的ISO，使用rufus制作一个ubuntu启动U盘。

将拆下来的NAS硬盘直接装到台式机主机中。

通过ubuntu启动U盘引导，选择Live方式直接启动进入ubuntu（因为是U盘启动系统，比较慢要耐心等待一下）。

进入ubuntu系统之后打开terminal进行NAS盘的挂载操作：

首先修改root密码

sudo passwd root

然后切换到root权限

su root

然后安装mdadm组件

apt install mdadm

通过mdadm挂载RAID（命令执行完后会提示NAS盘的RAID信息，我是的md2）

mdadm -Asf && vgchange -ay

然后随便建个目录

mkdir /mnt/nas1t

再将RAID挂上去

mount /dev/md2 /mnt/nas1t

然后后续就可以在图形界面下将NAS的数据导出来了。

还好我的NAS里面的数据不是很多，因为除了小姐姐之外，主要是自己macbook的TimeMachine以及通过DS Cloud Station备份的工作文件。TimeMachine跟Cloud Station的文件都可以直接放弃了，等新系统搞好之后重新备份一次就好了——于是我一番猛如虎的操作最后成果是救出了几百G的小姐姐

2.3、安装PVE+群晖+LEDE

安装过程其实不复杂，主要是在装群晖时遇到些问题。对于在网上能够很容易就找到相关教程的部分，我这里限于篇幅就从简了。这里主要是大致介绍一下过程，以及把自己遇到并解决的坑说出来。

2.3.1、PVE安装

PVE的安装比较简单，下载最新的ISO，用rufus制作启动盘，然后U盘引导按提示一路下一步安装即可。

安装完PVE之后，即可通过https://ipaddr:8006来访问控制台。这里要提一下，因为PVE在安装时默认只使用一块硬盘，所以其他的硬盘需要根据自己的情况手动进行添加。不过，因为我打算把另一块硬盘直通给群晖，所以就不需要在PVE中进行挂载了。（备注一下：PVE中有带Ceph组件，估计开发组的想法是除了PVE的系统盘，其他的硬盘使用Ceph做分布式存储，不过，我就2块盘，所以这里没打算尝试了）

2.3.2、群晖安装

进入PVE控制台之后，在右上角创建一个虚拟机，注意一下VM ID，这个涉及到后面的命令行操作，可以自己定义也可以用自动生成的那个。

操作系统选择“不使用任何介质”

系统默认即可

硬盘总线要选SATA，默认的SCSI会导致引导不起来。我在这里走了一晚上弯路

CPU这里，按照习惯我选的2核（这里有坑，后面会讲一下如何优化）

内存我分了1G，NAS够用了。

网卡要选E1000，不然没驱动。

详细安装教程可以参考值友文章：

基于ProXmoX VE的虚拟化家庭服务器（篇三）—黑裙6.2安装，硬盘直通上篇我们成功的安装了ikuai和lede，本篇我们讲下如何在proxmox中安装群晖虚拟机。首先网页登陆proxmox，点创建虚拟机，名称随意，记住VMID名称随意，记住VMID，下一步选择不使用任何介质，其他默认选择不使用任何介质，其他默认，下一步我们后面要硬盘直通给群晖，这里我们意思一下，磁盘大ClegeA| 赞121 评论351 收藏1k查看详情

然后下载最新的DS918+_6.21-23824-1.04b引导文件（嗯，以前装的是ds3617xs，这次想换换口味装ds918，结果后来装完了数据都恢复完了发现918不能洗白 ），安装过程如下。

通过winscp将DS918+_6.21-23824-1.04b引导文件跟img2kvm上传到PVE中。

进入上传所在目录

chmod +x img2kvm

然后将引导文件挂到群晖虚机上，我这边VM ID是100，请注意修改

./img2kvm DS918.img 100 vm-100-disk-1

然后安装lshw组件

apt-get install lshw

使用lshw查看硬盘的disk id

ls -l /dev/disk/by-id/ | grep ata

然后将之前创建虚机时的硬盘分离并删除掉

qm set 100 --sata2 /dev/disk/by-id/HGST_HTS541010A9E680_JDD030CCKXNJVH

回到PVE控制台，把虚机下未使用硬盘挂上去（我这里是sata1），再到虚机选项中设置引导顺序从sata1引导。然后虚机开机，即可通过find.synology.com或者Synology Assistant发现群晖，然后使用本地安装方式安装DS918+_6.21-23824.pat即可。

因为我下载的pat文件版本较早，安装完pat进入DSM之后就发现可以升级6.2.2，直接在线升级了，没有问题。然后就可以正常使用了。

2.3.3、LEDE安装

LEDE安装就更简单了，跟群晖一样，在PVE中建个虚机，然后将创建虚机时的硬盘分离并删除。

然后直接去https://firmware.koolshare.cn/下载最新的LEDE固件：https://firmware.koolshare.cn/LEDE_X64_fw867/openwrt-koolshare-mod-v2.31-r10822-50aa0525d1-x86-64-combined-squashfs.img.gz

下载成功之后将img解压出来，通过winscp上传到PVE里。在命令行下将img挂给虚机，然后用这个硬盘引导即可。

./img2kvm lede.img 200 vm-200-disk-1

详细安装配置也可以参考值友文章：

基于ProXmoX VE的虚拟化家庭服务器（篇二）—虚拟化软路由上篇我们已经安装好了PVE的基础，这篇我们来讲一下如何安装软路由，我这里是ikuai+lede旁路ikuai的安装首先我们先到网络部分把网络端口配置一下编辑一下vmbr0，修改备注为lan，方便维护新建一个端口桥接端口填eth1(这里每个人不一定，要看你上面的两个网络设备，填其中不活动的那个)，备注ClegeA| 赞52 评论105 收藏530查看详情

LEDE我主要是用来装v2ray client，然后ddnsto也是在LEDE上装的。旁路由主要的目的还是用来装插件减轻主路由的负担啊

三、免费实现群晖内网穿透

首先在这里介绍一下我群晖NAS的用途：

1、使用群晖自带的Download Station当下载机使用；

2、使用Cloud Station Server，在macbook上安装cloud station客户端，将重要工作文件跟NAS同步备份；

3、Cloud Sync，将上面步骤2中同步过来的重要工作文件同步到百度云；

4、File Station建个TimeMachine文件夹，用作macbook的TimeMachine。

因为J1900小主机有2块硬盘，其中2T的那块装了PVE系统，1T的那块直通给了群晖。然后在PVE下建了个1.5T的虚拟硬盘分给了群晖。以上用途中，1-3的部分是使用直通的1T硬盘，4的部分是放在1.5T的虚拟硬盘中（实际上在2T的物理盘上）。根据数据备份的三二一原则：三份数据，两种介质，一份异地，我这也算是满足甚至超出了：macbook+CloudStation+百度云+TimeMachine共计四份数据，TimeMachine从某个角度上勉强算第二种介质，然后百度云算异地

因为PVE里的群晖装的DS918，在不能用qc的情况下，我得解决内网穿透的问题了，不然做不到出差的时候随时随地进行CloudStation同步，而且，我有频繁通过手机DS File APP访问NAS上重要工作文件的需求，这些都是内网穿透的刚需。

内网穿透一般有两种方案：DDNS跟VPN。这里两种方案都用上了。

3.1、DDNS——ddnsto方案

DDNS主要是解决远程管理DSM以及手机远程访问DS File的需求。因为DSM管理、DS File都是用的5000端口（http）跟5001端口（https），我这里只用的http5000端口（要相信群晖的安全性 ）

因为DDNS是在LEDE上做，所以直接采用的ddnsto方案。在LEDE上安装ddnsto插件，然后到https://www.ddnsto.com微信扫码登陆获取token，将token复制到ddnsto插件中并开启插件即可。

然后在https://www.ddnsto.com上配置动态域名指向群晖即可。

因为我家宽带没有公网IP，所以只能内网穿透，ddnsto免费而且速度还算不错，对于我通过手机用DS File访问NAS工作文件的需求来说，还是完全可以满足的。

此外，顺便远程访问DSM、DS Download等需求也一并解决了（因为都是同一个端口）

3.2、VPN——zero tier方案

因为DDNS内网穿透需要流量转发无论是速度还是数据量都受限于DDNS供应商，所以像CloudStation这样流量很大的应用就不太适用DDNS了，一个可以直通的VPN非常重要。

zero tier方案就非常适合这个需求：免费、并且VPN节点之间数据直通无需经过转发。

注册并登陆https://my.zerotier.com/，在Network选项中Create一个Network，获得一个Network ID。

然后设置一下VPN的私网网段，可以选现成的，也可以跟我一样自定义。我是自定义的192.168.188.0/24

然后下一步先别急着用，得分别在群晖跟终端中安装zerotiear客户端。

群晖client下载地址：https://download.zerotier.com/dist/synology/

macOS client下载地址：https://download.zerotier.com/dist/ZeroTierOne.pkg

群晖直接在套件中心里手动安装，上传下载的spk文件即可。

然后在群晖中打开ZeroTier组件，复制左下方的Node ID到https://my.zerotier.com中进行添加，然后复制Network ID加入网络即可。

my.zerotier.com中的client端管理如下：

然后macOS端直接运行pkg安装即可。然后再在zerotier中通过Network ID加入VPN网络即可。通过netstat -rn可以看到VPN网段已经成功加入路由表。

然后，在macOS的CloudStation中通过VPN地址添加群晖NAS：

至此，CloudStation的需求完美解决。

3.3、内网穿透之后的收尾工作

前面的工作做完之后，我在设置TimeMachine时发现不能顺利访问NAS了。思考了一下，应该是群晖在LAN跟VPN上都响应了Bonjour导致的。这里先简单介绍一下Bonjour协议：

Bonjour是苹果为基于组播域名服务(multicast DNS)的开放性零设置网络标准所起的名字，能自动发现IP网络上的电脑、设备和服务。Bonjour 使用工业标准的 IP 协议来允许设备自动发现彼此，而不需输入IP 地址或配置DNS 服务器。

采用 Bonjour 技术的电脑和设备可以自动传播它们自己的服务，并探寻其他设备提供的服务。你的电脑能够看到可以打印的打印机，可以听的 iTunes 播放列表，以及可以视频聊天的 iChat 好友。设置可以进行文件共享的另一台电脑。

嗯，是的，macOS是通过Bonjour去发现局域网设备的，虽然在Finder下可以直接通过afp://ipaddr来访问群晖，但是TimeMachine的设置里只能使用通过Bonjour发现的磁盘。Bonjour协议是使用mdns去进行设备发现，端口号为5353。

知道原因就好处理了，直接在群晖里面把VPN接口的Bonjour跟AFP之类的禁用掉不就完了？

进入DSM，在控制面板->安全性中，启用防火墙。

然后编辑规则，在右上角选择局域网 51（我的VPN接口），为了稳妥起见，我先建了一条允许192.168.188.0/24访问6690端口（CloudStation使用的端口）的条目，然后再建了一条拒绝192.168.188.0/24访问Bonjour、AFP、CIFS、NFS、find DS的条目。然后应用即可。

然后在macOS上再次查看状态，先ping一下域名，嗯，返回的是LAN地址。

然后再通过netstat确认一下mac到群晖的连接，非常棒，CloudStation的6690端口走的VPN地址，AFP的548端口走的LAN地址。完美解决。

最后汇总一下本章节一共实现的内容：

1、通过ddns，实现手机使用DS File APP访问NAS；

2、通过zero tier，实现macbook通过VPN与NAS进行文件夹同步；

3、通过在DSM上设置防火墙，实现macbook通过局域网访问NAS进行TimeMachine（当然，也包括普通AFP访问了）。

四、群晖CPU优化

好了，终于所有功能都实现了，然后我就开始了紧张的原NAS数据导回、macbook通过CloudStation进行同步、macbook通过TimeMachine进行备份等工作。

然后，我发现群晖虚机的CPU占用特别高！要知道以前物理机装群晖时，CPU再怎样高也就10%多点，但是这次虚机的CPU利用率长期保持在50%以上，而且动不动就90%+，特别是macbook通过CloudStation进行同步时，因为zero tier跟CloudStation两个组件都在运行，一度出现DSM的web端卡爆掉的情况。

哪怕NAS在空载的时候，CPU也一直在50%左右，查看进程发现zero tier一直占着30%左右的CPU。。。而且在PC上往NAS传文件，只能跑到50MB/s多点，此时CPU已经90%以上了。。。

于是我认真阅读了PVE的帮助文件：

A CPU socket is a physical slot on a PC motherboard where you can plug a CPU. This CPU can then contain one or many cores, which are independent processing units. Whether you have a single CPU socket with 4 cores, or two CPU sockets with two cores is mostly irrelevant from a performance point of view. However some software licenses depend on the number of sockets a machine has, in that case it makes sense to set the number of sockets to what the license allows you.

Increasing the number of virtual cpus (cores and sockets) will usually provide a performance improvement though that is heavily dependent on the use of the VM. Multithreaded applications will of course benefit from a large number of virtual cpus, as for each virtual cpu you add, Qemu will create a new thread of execution on the host system. If you’re not sure about the workload of your VM, it is usually a safe bet to set the number of Total cores to 2.

Resource Limits

In addition to the number of virtual cores, you can configure how much resources a VM can get in relation to the host CPU time and also in relation to other VMs. With the cpulimit (“Host CPU Time”) option you can limit how much CPU time the whole VM can use on the host. It is a floating point value representing CPU time in percent, so 1.0 is equal to 100%, 2.5 to 250% and so on. If a single process would fully use one single core it would have 100% CPU Time usage. If a VM with four cores utilizes all its cores fully it would theoretically use 400%. In reality the usage may be even a bit higher as Qemu can have additional threads for VM peripherals besides the vCPU core ones. This setting can be useful if a VM should have multiple vCPUs, as it runs a few processes in parallel, but the VM as a whole should not be able to run all vCPUs at 100% at the same time. Using a specific example: lets say we have a VM which would profit from having 8 vCPUs, but at no time all of those 8 cores should run at full load - as this would make the server so overloaded that other VMs and CTs would get to less CPU. So, we set the cpulimit limit to 4.0 (=400%). If all cores do the same heavy work they would all get 50% of a real host cores CPU time. But, if only 4 would do work they could still get almost 100% of a real core each.

CPU Type

Qemu can emulate a number different of CPU types from 486 to the latest Xeon processors. Each new processor generation adds new features, like hardware assisted 3d rendering, random number generation, memory protection, etc … Usually you should select for your VM a processor type which closely matches the CPU of the host system, as it means that the host CPU features (also called CPU flags ) will be available in your VMs. If you want an exact match, you can set the CPU type to host in which case the VM will have exactly the same CPU flags as your host system.

This has a downside though. If you want to do a live migration of VMs between different hosts, your VM might end up on a new system with a different CPU type. If the CPU flags passed to the guest are missing, the qemu process will stop. To remedy this Qemu has also its own CPU type kvm64, that Proxmox VE uses by defaults. kvm64 is a Pentium 4 look a like CPU type, which has a reduced CPU flags set, but is guaranteed to work everywhere. In short, if you care about live migration and moving VMs between nodes, leave the kvm64 default. If you don’t care about live migration or have a homogeneous cluster where all nodes have the same CPU, set the CPU type to host, as in theory this will give your guests maximum performance.

重点部分标粗了，大意就是，理论上，虚机的CPU核数越多性能会越好，但是同时要考虑做CPU资源限制以免虚机占用过多CPU时间，此外，CPU默认类型kvm64是为了虚机迁移时的最大的兼容性，而为了更高性能的话，建议设置为host。

OK，明白了就好，按道理来讲，群晖上跑了一堆组件，对多核肯定是有要求的，立马在PVE控制台上把群晖虚机的CPU改为4核，资源限制250%，类型为host。

然后在PC机上找了个大文件进行测试——MHW的chunk0文件，17G够大吧，哈哈！

速度平均在70MB/s左右，偶尔会掉速（因为J1900不支持VT-D，I/O延迟要差一点）

在DSM中可以看到实时速度、CPU使用率、进程占用CPU情况。主要是DSM内部服务跟SMB占用较高。

然后打开资源监控看看详细数据，CPU占用基本保持在80%左右（如果我不开DSM的话应该还能低点）

内存倒是挺稳定的，使用率很低。

然后就是传输速度，峰值能跑到121MB/s，但是上下起伏挺大的，嗯，毕竟不支持VT-D，没办法。

经过CPU优化，NAS在日常空载时CPU使用率保持在10%以下，满负荷时CPU保持在80%左右。好了，我已经挺满足的了。如果想再提升一下的话，应该是可以考虑CPU资源限制提升到300%-350%，不过想想算了，就这样吧，够用就好。

五、总结

以上就是本技术宅在这个每天呆家自我隔离的春节中干的最大的一件事。

嗯，对了，J1900主机还是以前那个主机，从17年5月装DS3617xs 6.1.1洗白用到现在，然后接着装PVE+群晖+LEDE继续服役，也算是值回票价了 。

从目前这两天的使用来看，J1900平台在PVE+群晖+LEDE方案下，依然可以满足需求（自我安慰的同时顺便对GEN8土豪们表示羡慕）

本文主要是提供自己的一些方案跟思路，顺便把自己遇到的坑提一提，避免值友们走弯路（我熬过的夜，你们不用再熬了），如果是新手司机需要手把手带路的话，可以考虑百度一下网上大把的现成教程。

最后，谢谢各位看完我的万字长文。。。