eh 。。 需要体现出来你们的价值。比如，
1. 你们前端的需求来自哪里？
2. 上下游是啥？
3. 跟其他小组是如何配合的？
...

@Tinet 这个一般网工可以回答。 一般常见的也就是 /22 了，没有见过再大的。 ARP 隔离需做好工作，即然是 ARP 是瓶颈，就想办法解决他，毕竟 docker 是新技术，而 ARP 已经很古老了，就好像小孩子个长高了，衣服买了新的，鞋也得换，全套的 哈哈

兄弟 我见过一个 vlan/22 的， 1000+ 日常也没啥问题

就没指望过公司，即使给配置，那流程也是没个几个月下不来的，自己搞定喽。我是自己配置了一个 19 寸的 DELL 方平，不喜欢第二显示器，所有的精力集中在一块显示屏上，当然，系统是 MacMini 。

我们是有一个 db 库，用 python 读取 db 并 create nagiod conf file

ss -ln 看看是不是 PHPfpm 的端口队列满了

多换几个 DNS 服务器测试呢？ 比如用下 cloudxns 的工具箱 全国测试下。

要看具体的策略：

压缩备份的好处：
1. 压缩后是一个文件，传输的时候，可以直接 block by block 更快。 例如： 100 个小文件穿起来，是不如 1 个压缩文件快的。不过这个需要消耗掉 CPU ，如果可以容忍的话可以采用这个。

如果磁盘够大，不要求快速的话可以试试 btsync ，来块希捷的 NAS + btsync 客户端 https://getsync.com/platforms/other-devices/ 。

兄弟， 我们之前的场景和你差不多，根据我们的经验，多半是因为 TCP 的机制在广域网的时候会有性能问题。 我们后来采用 https://sourceforge.net/projects/tsunami-udp/ ， 这个软件 速度不错，基本可以把公网口打满。

不过需要注意， tsunami-udp + ipsec 效果最好， 如果没有 ipsec 的包裹， 多半传起来就会失败，或者中途卡住。

还有另外一个方案，可以采用 btsync 进行。

以上是大量数据进行传输，如果是控制链路， 那么一点点带宽也是足够了的。

@zzlyzq

address=/baidu.com/1.1.1.1

这样 所有 baidu 的子域名都会到 1.1.1.1

可能 dnsmasq 有这种功能

大多因为薪水问题，可以理解。吃了上顿没下顿，怎么能安心工作呢。

@pichina 朝阳公园桥东，乐视大厦东边的 观湖国际

热爱 Linux 、喜欢摆弄系统的小伙伴们看过来，请把简历发送到 [email protected]

mtu 的问题？

@lhbc 负载高因为 nginx 的日志落盘，目前我发现的是这个原因。

tokumx 的数据压缩确实牛逼。

@lhbc 就是为了防止 auto 带来的性能损失

@msg7086 乘法不错 当时没想起来