Just a heads up Mike. I tried doing the same thing with regards to using loggen to find the best rate on my V490. My version of loggen did not have the --active-connections parameter for sure, and I think it didn&#39;t have the --idle connection parameter either. I set the -I to 600 for 10 minutes, and that didn&#39;t work either. It ran until I manually killed it about 25 minutes later.<br>
<br>Then for the output all I got was :<br>count=14877   diff=15930    rate = 627.75<br><br>I haven&#39;t found what they mean yet. I reckon count would be the number of packets sent, not sure what diff is, but I know what the msg/sec is:))<br>
<br>I am curious to see what you come up with. Oh, did you use the SunFreeware version or did you compile it yourself?<br><br><br><br><div class="gmail_quote">On Tue, Apr 26, 2011 at 1:58 PM, Mishou Michael <span dir="ltr">&lt;<a href="mailto:Michael.Mishou@csirc.irs.gov">Michael.Mishou@csirc.irs.gov</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Gergely,<br>
<br>
Thanks for any testing you can do.  I&#39;m not sure if a SPARC processor is<br>
an important testing component or not, I suppose your VMs will help<br>
determine this since you&#39;ll be using x86.  If there&#39;s any testing I can<br>
do to help things along, please let me know.<br>
<br>
Yes, I&#39;m (very) scared of rsyslog as a maintainable solution, the<br>
configs for syslog-ng are *so* much easier to read and understand.  I&#39;ll<br>
try 3.3 and report back how threading helps things out, I&#39;m glad to hear<br>
that it&#39;s been pretty stable for you, that was my major concern in<br>
testing 3.3 since eventually we&#39;ll need this to be in production with<br>
our basic (from a config complexity standpoint) requirements.<br>
<br>
I&#39;ll report back how 3.3 works out for me after I get it compiled and up<br>
today.<br>
<br>
Regards,<br>
<br>
--Mike<br>
<div class="im"><br>
-----Original Message-----<br>
From: <a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a><br>
</div>[mailto:<a href="mailto:syslog-ng-bounces@lists.balabit.hu">syslog-ng-bounces@lists.balabit.hu</a>] On Behalf Of Gergely Nagy<br>
Sent: Tuesday, April 26, 2011 12:19 PM<br>
<div class="im">To: Syslog-ng users&#39; and developers&#39; mailing list<br>
Subject: Re: [syslog-ng] Solaris 10 UDP overflows, message drops<br>
<br>
</div><div><div></div><div class="h5">(A few preliminary answers follow - I&#39;ll have another look at this later<br>
tonight from home, once I tested a few things on my local solaris vm)<br>
<br>
&quot;Mishou Michael&quot; &lt;<a href="mailto:Michael.Mishou@csirc.irs.gov">Michael.Mishou@csirc.irs.gov</a>&gt; writes:<br>
<br>
&gt; I&#39;m going to experiment with syslog-ng and the loggen tool to find a<br>
&gt; point at which a single syslog-ng instance starts dropping inbound UDP<br>
&gt; traffic with a simple configuration writing to disk.  Once I have that<br>
&gt; number, I have a few options:<br>
&gt;<br>
&gt; 1.  Experiment with syslog-ng 3.3 and the new threaded code to see if<br>
I<br>
&gt; have performance gains.  I&#39;m hesitant to push Alpha code in<br>
production,<br>
&gt; if anyone has any experience with 3.3 in semi-production environment<br>
&gt; running consistently I&#39;d love to hear it.<br>
<br>
I&#39;ve been running 3.3 on most systems I administer (2 of my own servers<br>
+ a few I administer for friends; and all of my virtual machines). It&#39;s<br>
been serving me fine for the past 4 months now.<br>
<br>
However, most of my systems are also linux systems, where syslog-ng is<br>
much better tested (and I&#39;m not using UDP at all).<br>
<br>
Personally, I&#39;d give it a test run, as current 3.3 is fairly stable.<br>
<br>
&gt; 3.  Give up on syslog-ng until 3.3, or move to some other solution.<br>
Not<br>
&gt; sure what I could do here, rsyslog is the other major contender I<br>
guess,<br>
&gt; not sure what gains I would get.  Could also do native syslog server<br>
and<br>
&gt; post-process to different buckets/relay which is what we mainly use<br>
&gt; syslog-ng for.<br>
<br>
I wouldn&#39;t consider rsyslog. It&#39;s a nightmare to maintain that, and an<br>
even bigger nightmare to get it to perform well in any but the most<br>
trivial situations. (Or it might be just me being too used to good<br>
documentation and readable config files, but I&#39;m fairly sure it&#39;s not<br>
just that :P)<br>
<br>
--<br>
|8]<br>
________________________________________________________________________<br>
______<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation:<br>
<a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.campin.net/syslog-ng/faq.html" target="_blank">http://www.campin.net/syslog-ng/faq.html</a><br>
<br>
______________________________________________________________________________<br>
Member info: <a href="https://lists.balabit.hu/mailman/listinfo/syslog-ng" target="_blank">https://lists.balabit.hu/mailman/listinfo/syslog-ng</a><br>
Documentation: <a href="http://www.balabit.com/support/documentation/?product=syslog-ng" target="_blank">http://www.balabit.com/support/documentation/?product=syslog-ng</a><br>
FAQ: <a href="http://www.campin.net/syslog-ng/faq.html" target="_blank">http://www.campin.net/syslog-ng/faq.html</a><br>
<br>
</div></div></blockquote></div><br>