@godymho 谢谢，第一次听到，原来爱好者还发明了第三方网游客户端。。

肯定是干坏事。。。

不就是虚拟内存吗？物理内存不香吗？虚拟内存那性能低的吓人

那为什么厂家还要用 N 年前就存在的古老技术？

主要还是国产 app 恶意抢占内存,恶意唤醒，导致 android 生态链畸形，各大厂家盲目内卷增加物理内存大小。。。现在连手机厂家都吃不住了。。。总不能手机发展成比 PC 机主流内存还要高的 16G 内存，或者 24G ，32G 运行内存吧？那成本太高了。。。

还是 ios 好，到现在只发展到 6G 内存。。。

@poporange630 我不想解释了。你就这么认为吧，挺好的。。

看不出来这个是钓鱼贴吗？大家？

@nkloveni 发现 @错了，回复成你上面那个哥们了。。。

@Damn 主要是放一根线和放两根线耗费的精力上没区别，或者是直接铠装多芯光纤也行。

主要考虑直接采用双芯方式，一收一发，这种传统方案更靠谱一些。毕竟 bidi 采用不同波长来实现收和发。如果大面积铺设线路，用 bidi 太节省成本了，最少省了一半。

但是 UP 主 A 屋和 B 屋之间不可能接那么多的线路啊。。没必要

我到现在还在用 2012 的 mac mini 做服务器+电视机 airplay 投屏器+机顶盒

@kingsoT 主要是 UP 的需求对网络要求比较高，尤其是 lol 这种网战游戏，别说延迟高有影响了,丢包更是不允许，影响战局。


如果只是单纯的浏览网页，看电影这种需求，即使是采用无线方案，控制在一定范围的丢包率，那也是可行的。延迟高，丢包对这种应用没有太大影响的。

@FabricPath 怎么会，你也对无线太自信了。你接过多少私活，部署过几次类似的长距离无线项目？有过多少次实施经验？

下雨天，雾天，雪天，对无线都有影响的，而且尤其是下大雨的时候，铁定丢包

@Tounea 你们公司 IT 水平太渣了。。而且估计是 IT 部门在公司地位太低了，被当成了服务为主的部门。。

@xsourse 是的啊，你多拨，不就有多个公网 IP 了吗

拉光纤最实际（最少双芯，一收一发，别搞运营商那套单芯，xpon/olt/onu,那是为了节省线缆资源的替代技术）。

无线一定肯定是小白最想推荐的。。但其实一旦是下雨天，下雪天，不丢包就不错了。。更别说延迟低打游戏的问题了

拉光纤最大的问题是熔纤，故意打 10000 号报故障，然后约个宽带师傅，给点钱帮你搞定了。

有条件上铠装光纤(铠装最低 4 芯起)，汽车压都压不坏，不过宽带师傅的光纤熔接机不太好熔。。。
没条件就买 2 跟单芯皮揽光纤，外面在包一层，这种任何机器都好熔。。

100 米以上别考虑双绞线了。。。不靠谱。。

哦，最好直接到位用单模光纤，一步到位（仅仅是光模块，收发器贵些） 别用多模，多模几年一个新规格（ om1,om2,om3,om4,om5 等等，未来估计还会有新的）。。。

网络设备（路由器 /交换机----双绞线---A 屋光纤收发器-----单模光纤----B 屋光纤收发器--双绞线--B 屋网络设备（路由器 /交换机）

@ReZer0 你以为我们运维部门是吃干饭的?。。。。我们公司就抓到一个。。结果去上门拍照的时候，被他同事发觉告密给他了。。。本想第 2 天上公司公告的，没想到他吓得当天晚上凌晨跑回公司，把 frp 删除。。

你真以为程序员想的小心思，我们都不知道？有太多技术可以监控你们的电脑及分析网络流量

其实本来是想拿他当出头鸟，警告公司所有人的。。。后来看他态度良好，此事就算了。。不然他肯定立刻毕业了。。

@muhairen 128G

在补充一句，跑 zfs 一定要 ecc 或者 recc,为什么，自行谷歌吧

UP 主是不是放错区了？这边是宽带症候群,不是 NAS 区

最多找个 ssd 开个 log..

还是增加内存 收益最大。。。

自组 NAS ，最好考虑服务器主板，这样会有比较多的内存槽位。ddr4 最大的是单根 32G 一根。还是多考虑下以后扩容内存的事吧。。。。

可以参考这篇文章
https://www.a-programmer.top/2021/10/15/ZFS%E7%B3%BB%E5%88%97%EF%BC%88%E4%B9%9D%EF%BC%89%E5%8E%8B%E7%BC%A9%E4%B8%8E%E6%95%B0%E6%8D%AE%E5%8E%BB%E9%87%8D/

数据去重（ Deduplication ，重复数据删除 /重删）
我们还有另一种与压缩相结合的方法来节约磁盘空间，那就是重复数据删除。现在，有三种主要的重复数据删除类型:文件、块和字节。文件重复数据删除是性能最高、系统资源成本最低的。每个文件都使用加密哈希算法进行哈希，比如 SHA-256 。如果哈希值匹配多个文件，则不将新文件存储在磁盘上，而是在元数据中引用原始文件。这可以节省大量空间，但也有一个严重的缺点。如果文件中的单个字节发生了变化，哈希值将不再匹配，这意味着我们不能再在文件系统元数据中引用整个文件。因此，我们必须将磁盘所有块做一个复本，对于大文件，这对性能有很大的影响。

另一种极端情况是字节重复数据删除，这种重复数据删除方法成本最高，因为您必须保留“锚点”，以确定重复数据删除和唯一字节区域的开始和结束位置。毕竟，字节就是字节，是不知道哪些文件需要它们，它只不过是一个数据的海洋。这种重复数据删除技术适用于文件可能被存储多次的存储，即使文件没有在相同的块下对齐，比如邮件附件。

块重复数据删除处于三者中间位置。ZFS 仅支持块重复数据删除。块重删共享文件中所有相同的块。这允许我们只在磁盘上存储唯一的块，并在 RAM 中引用共享块。它比字节重复数据删除更高效，比文件重复数据删除更灵活。然而，它有一个缺点——它需要大量的内存来记录哪些块是共享的，哪些不是。不过，因为文件系统读写数据是以块的方式，所以对现代文件系统使用块重复数据删除是最有意义的。

共享块被存储在所谓的“重复数据删除表”中，文件系统上重复的块越多，这个表就越大。每次写入或读取数据时，重复数据删除表都会被引用。这意味着您希望将整个重复数据删除表保存在快速 RAM 中。如果您没有足够的 RAM ，那么表将溢出到磁盘上。这可能会对存储的性能产生巨大的影响，无论是读数据还是写数据。


数据去重的开销
所以这还有个问题:你需要多少内存来存储你的重复数据删除表?这个问题没有一个简单的答案，但是我们可以对如何处理这个问题有一个很好的总体思路。首先，查看存储池中的块数量。你可以看到这个信息，用如下的命令(耐心点-在它给出报告之前，可能需要一段时间来扫描文件系统中的所有块):

# zdb -b rpool

Traversing all blocks to verify nothing leaked ...

No leaks (block sum matches space maps exactly)

bp count: 288674
bp logical: 34801465856 avg: 120556
bp physical: 30886096384 avg: 106992 compression: 1.13
bp allocated: 31092428800 avg: 107707 compression: 1.12
bp deduped: 0 ref>1: 0 deduplication: 1.00
SPA allocated: 31092244480 used: 13.53%


在本例中，存储池“rpool”中有 288674 块被使用(查看“bp count”)。池中的每个重复数据删除块需要大约 320 字节的内存。因此，对于 288674 块乘以 320 字节 /块，我们得到大约 92 MB 。文件系统大约有 200 GB 大小，所以我们可以假设重复数据删除只能增长到大约 670 MB ，尽管它只有 13.53%被填满。也就是说，每 1GB 的文件系统需要 3.35 MB 的重复数据删除数据，或者每 1TB 的磁盘需要 3.35 GB 的 RAM 。

@wangyuxian95 去重不要开，不然最少内存 double ，建议 x4. 及其消耗内存

@muhairen 磁盘总的 block 大小

zfs 之所以性能有很好的表现，背后都是超多的内存支持着的。。。
低内存想用 zfs,还想性能好?还是打消这个念头吧。。。