三棒的作弊空间让你用完了……

企业，又不是网吧，做好基本限速策略就行了，没必要上复杂 QoS 系统。采用跟电信联通宽带差不多的分时单点带宽硬分配+初始连接突发保障就行了，上复杂 QoS 没意义。

遇到的问题，第一个就是， 100M 的 FTTH ，上行多少是关键。 10M 上行的话，怎么分都可能比较坑，更低就更完蛋了。

第二个问题， 25 个房间，完全没有要点，你要报一个屋子多少设备， WiFi 怎么处理，这些都是关键。
如果说按照一般推测，除非 25 个小屋子，一个屋子三四个人，才是百个点以下的，否则都是 200 点以上的，几十个固定点的全放一个网段不隔离倒是还说得过去，要是上百个点，还是要根据实际需求分一下部门互访需求（主要是共享啊， IPMSG 传文件之类的）进行一下隔离。

第三个问题，公司业务是否有较大的内网传输需求，就是内部系统啊，内部传文件啊，内部服务器啊，这些决定你的基础结构是否需要千兆环境。还有就是是否要有内部服务器区啊什么的

第四个问题，两层楼，楼上楼下，各个办公室之间的布线如何处理，主网络柜如何设置，下级交换是否进柜，连接方式是级联下去还是星型网，各办公室是进去一根线再接小交换还是二三级交换甩多线直接进屋到终端， WiFi 的接入是各自为战还是统一接入。还有如果有略长距离传输，走光还是走电，上光电转换还是直接交换机模块带

另外，我看楼上给你推荐个几百块钱 H3C 接入路由都嫌贵还问更便宜的，我觉得这公司开的真够可以的……

楼主你家有没有杜邦线？如果有，我教你给简单方法。
两根公对公，一根公对母的杜邦线。
找你电源出来的供电线有没有软驱线？就是小四针
如果有，软驱小 4 针，中间 23 两针是 GND ， 1 针（通常红色）是+5V,4 针（通常黄色）为+12V

用两根公对公把风扇正接+12V ，负接+5V ，这样风扇就只有 7V 左右的电压，转速下降，更静音

然后用一根公对母延长线把 3pin 风扇测速针接到主板测速口，保持风扇速度检测功能存在避免坏了风扇烧 CPU 还不知道

PHP: str_pad

@defunct9
这种美国地址能看得动 youtube 1080P ？如果搞 ss ，最次也是弄个便宜 vps 套 finalspeed 才勉强及格啊
单纯的能访问这种档次的要求，太低了吧……

@yexm0
IP 我都有，我实测了几周，就 PCCW 的稳定性最好，综合速度排第二

@402645707 不换个说法， V2EX 都会自动转移到 chamber ……

@VmuTargh
那应该是你本地服务商的 DNS 不给解析 google 的域名导致的，用我这个就没问题的。
我说的回归，指的是内容已回归，具体你能不能访问到还得看你自己的网络，用我这个方法强制返回 IP 就可以了

@VmuTargh
我这里没啥问题啊，你那里不行么？跟 360 这种把 cdn 堆到家门口的没法比，但是绝对比自己服务器快多了……

@maomengcheng
你们作为平台产品提供方，开放程度应该多考虑考虑，生态系统建立好了，能让更多的开发者在其中找到自己的模式，你们的产品都不用自己推广就能卖。

玩得起全自动化部署自动化实施自动化弹性扩容的，哪个都不是小客户，给他们方便了，比如我之前说的这种模式，如果你能多主动提供类似的方案，很多大的解决方案公司会选择你阿里云可以全自动配置还是去选择别人家 VPS 一点点手动装？即使同等选择，实施人员也会从自己的工作量角度劝真正客户用方便的，这不比 9 折促销什么的拉动消费实在多了……

@msg7086
我觉得这是正常想装文艺结果二逼的典型……

@pubby
不一定会的。导致锁表那个操作并不一定执行频率很高，未必能 show processlist 准确抓到。
卡住以后，堵了太多 update ，然后当那个锁释放的时候，这个待执行 update 队列就变态的大了， show proceslist 只能抓到正常的高密度 update 。

@sujin190
云服务器，你确定不是 IO 的问题？感觉可能性极大……
另外发个 show create table XXX 上来让大家看看吧，感觉也可能是其他联合索引更新导致的锁
你这个 update 操作密度比较大， 100 次每秒，一旦一个其他导致锁的操作阻塞，你的 update 进队列，一秒就堵 100 个查询，导致阻塞的操作的频率，决定了累计程度，时间长就这样了，也是很可能的。

@tanteng 你想多了，两个人微秒级同时操作？总有先后顺序的。