Hmm, perl compiling the swatch script, which creates a sub-script that really does the monitoring is really expensive compared to the simple forking of processes. Based on this I'd say try using a shell wrapper script that sleeps a random amount of time before launching swatch. Granted your writes to that destination will block for the sleep period, but at least your system won't thrash trying to lauch all those heavy perl processes at once. This might work for the short term, until you find a more elegant solution. On Tue, Feb 11, 2003 at 12:29:44PM -0500, Keith Resar wrote:
Our central syslog server has a separate SWATCH process for each server (though it is sometimes divided only by server type).
Overall, we like the granularity of control and reliability that this setup offers -- i.e. changing the rules for one server/SWATCH process has no impact on the monitoring for other servers.
Keith Resar.
On Tue, Feb 11, 2003 at 10:10:21AM -0500, Keith Resar wrote:
In my current syslog-ng setup there are many destination programs. When syslog-ng restarts these all load at once, causing the system to grind to a halt.
As a solution, I'd like syslog-ng to spawn these programs more slowly, perhaps one every few seconds.
Perhaps we could explore whether this is the best solution. If you tell us what you use so many destination programs for, maybe we can help you to come up with a setup where you need fewer. -- Nate Campi http://www.campin.net
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
--
_______________________________________________ syslog-ng maillist - syslog-ng@lists.balabit.hu https://lists.balabit.hu/mailman/listinfo/syslog-ng Frequently asked questions at http://www.campin.net/syslog-ng/faq.html
-- Nate Campi http://www.campin.net