二楼长，感谢您的回复，学习了。 可能bottleneck在write to disk上。 在一个论坛上，他们做performance optimization的时候，列出了这样的说法。 server is able to handle bursts of around 150,000 messages/sec, but it doesn't seem to write them out very fast, and over time seems to be limited to ~22,000 messages/sec
发布评论
评论（8）
回复 2# r2007
tcp理论上说，系统开销更大。 一收多，在高峰时期log server的带宽能上200Mbps。
再加上filter规则，负载就上去了。 不过这个syslog-ng没有研究过，搞一下。
高峰log server带宽达200Mbps，这正好是用tcp的一个理由。tcp是有流量控制的，而upd则不，不管对方是否处理完毕都会像打机关枪一样都丢过去。现在有tcp offload的网卡，只要带宽够，开销不是问题。建议做一下原型测试。如果不搞广播建议用tcp，其实很多情况下tcp比udp省流量，但是收发双方的系统开销稍大一些，相反线路上反而流量要小一些。
回复 4# r2007
二楼长，感谢您的回复，学习了。
可能bottleneck在write to disk上。 在一个论坛上，他们做performance optimization的时候，列出了这样的说法。
server is able to handle bursts of around 150,000 messages/sec, but it
doesn't seem to write them out very fast, and over time seems to be
limited to ~22,000 messages/sec
我先想办法测试一番
没人理了？
有没有用其他方案的呀，兄弟们
回复 6# 饭碗儿
scribe
回复 8# expert1
版主，在scribe开源之前呢，你们怎么做的。
你现在应该已属资深的运维了吧，爆爆料
回复 9# 饭碗儿
呵呵，我水平也一般般，之前不懂用的什么，现在用的这个scribe，你看下，我没仔细研究过。