小编kvz*_*kvz的帖子

我的 tar 命令

tar --remove-files -cvif 2011-08-02_14-05-09.tar 2011-08-02_14-05-09

写入 80MB/s。这超出了我们可以节省的容量，因为 MySQL 开始排队写入，最终我们会收到监控警报，因为系统不会永远等待 MySQL 并超时。

问：我可以节流tar到 20MB/s 吗？

在联机帮助页中没有找到任何内容，我们已经尝试使用最低ionice级别：/usr/bin/ionice -c3 tar <...>但这不会影响写入的 MB/s 并且 MySQL 仍然冻结。

也许ionice因为我们在/dev/md0软件 RAID 设备上而被忽略？

使用 HAProxy 1.6 和一个聪明的 hack，我现在有一个 HAProxy tcp 模式前端，它检测浏览器是否支持 SNI，并基于此，路由到一个强加密的 SSL 终止后端，或更弱的一个。这确保了 SSL 实验室的 A+ 等级，同时仍然允许除 IE6 之外的所有浏览器使用 SSL。

这是我的配置。它有一些模板变量应该是不言自明的，但不在与我的问题相关的领域：

frontend https_incoming
 bind 0.0.0.0:443
 mode tcp
 option tcplog
 tcp-request inspect-delay 5s
 tcp-request content accept if { req.ssl_hello_type 1 }
 use_backend https_strong if { req.ssl_sni -m end .transloadit.com }
 default_backend https_weak

backend https_strong
 mode tcp
 option tcplog
 server https_strong 127.0.0.1:1665

frontend https_strong
 bind 127.0.0.1:1665 ssl crt ${DM_ROOT_DIR}/envs/ssl/haproxy-dh2048.pem no-sslv3 no-tls-tickets ciphers ${strongCiphers}
 mode http
 option httplog
 option httpclose
 option forwardfor if-none …

在云平台上，您经常听到由于相邻 VM 的高负载、磁盘超额订阅以太网、备份或实时迁移到其他硬件，虚拟机可能会“冻结”片刻。

我怀疑这发生在我们的一个云提供商上的 Ubuntu 虚拟机上，我不想公开羞辱。

每天晚上，外部监控服务都无法使用它。机器本身在负载、流量等方面看起来很健康。供应商建议网络虽然很好。

我希望能够（反驳）证明 VM 冻结导致这些寻呼机。

我的一个想法是每秒将日期写入日志，然后在短暂的不可用后查看我们是否跳过了“节拍”。
然而，这似乎是有缺陷的，因为如果 VM 保持自己的时钟并允许从主机的硬件漂移怎么办。
如果我们的内部时钟与 VM 一起冻结，我们在该日志文件中仍然会有很好的秒数序列，并且时钟现在落后于实时。

有没有更好的方法/工具可以用来确定是否有机器冻结？

我猜是实时的，我们的时间可以证明，然后再一次，时钟漂移还有其他原因。

假设我有项目 A、B 和 C。我有两个后端服务器：server01 和 server02。

项目 A 可以由 server01 处理，项目 B 和 C 可以由 server02 处理。添加和删​​除新项目和服务器，我们以编程方式更新文件、Redis、Memcache 或类似文件（无论代理支持什么）中项目 ID 和后端服务器之间的哈希表。

我可以制作一个前端，例如/items/${id}基于 HAProxy 路由到正确的后端服务器${id}吗？那么通过查找什么 id 与什么服务器相关联？

如果没有，Nginx 能做到这一点吗？