| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Moave element status out of batch_obj_t because we
get a *much* better cache hit ratio this way.
Note that this is really a HUGE saving, even if it
doesn't look so (both profiler data as well as
practical tests indicate that!).
|
| |
|
|
|
|
|
|
| |
looks like GCC, even if optimizing, uses 32 bits - at least this
is suggested by the profiler results (both in terms of runtime and
cache misses).
|
| |
|
|
|
|
|
| |
do only when possible. However, the profiler only shows as *very* minimal
effect.
|
|
|
|
| |
this is just a small improvement, but let's get the benefit ;)
|
| |
|
|
|
|
| |
at least so tells the profiler...
|
|
|
|
| |
included some additional refactoring for cleaner code
|
|
|
|
| |
instead, we use a lookup table for the values.
|
|
|
|
|
|
|
| |
1) usually, no cancellation happens
2) even if so, there is no cancellation point inside the
destructors, so disabeling cancellation was mood in the first
place...
|
|
|
|
| |
remove snprintf() in favor for quicker code
|
|
|
|
| |
also fixed a couple of smaller issues along that way
|
|\
| |
| |
| |
| | |
Conflicts:
ChangeLog
|
| |\ |
|
| | |\ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | | |
This is a useful debug aid, but nothing of concern for regular users.
|
| |\| |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
ChangeLog
|
| |\ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
ChangeLog
configure.ac
|
| |\ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Conflicts:
plugins/omudpspoof/omudpspoof.c
|
| | | | | | |
|
|\ \ \ \ \ \
| | |_|_|/ /
| |/| | | |
| | | | | |
| | | | | | |
Conflicts:
ChangeLog
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | |_|/ /
| |/| | | |
|
|\| | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
...due to invalid assumption on structure data types.
closes: http://bugzilla.adiscon.com/show_bug.cgi?id=394
|
| | |/ /
| |/| |
| | | |
| | | |
| | | | |
...when FromPos was specified in template, but ToPos not.
Thanks to Radu Gheorghe for alerting us of this bug.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The problem was that incomplete fiter evaluation was done *during the
shutdown phase*. This affected only the LAST batches being processed. No
problem existed during the regular run. Could usually only happen on
very busy systems, which were still busy during shutdown.
|
|\ \ \ \
| | |/ /
| |/| |
| | | |
| | | | |
Conflicts:
runtime/rsyslog.h
|
| | | | |
|
|\| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
configure.ac
plugins/impstats/impstats.c
plugins/omudpspoof/omudpspoof.c
runtime/rsyslog.h
|
| |/ /
| | |
| | |
| | | |
retains bugfix while increasing performance again
|
| | | |
|
| | | |
|
|\ \ \ |
|
| | | |
| | | |
| | | |
| | | | |
... and replace it with a (much faster) prifilt() call
|
|\ \ \ \
| | |/ /
| |/| | |
|
| |\ \ \ |
|
| | |\ \ \
| | | | |/
| | | |/|
| | | | |
| | | | | |
Conflicts:
ChangeLog
|
| | | | | |
|
|\| | | |
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
runtime/msg.c
runtime/queue.c
tools/syslogd.c
|
| |\| |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
tools/syslogd.c
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This happened only on very high volume systems, if the same message was
being processed by two different actions. This was a regression caused
by the new config processor, which did no longer properly enable msg
locking in multithreaded cases. The bugfix is actually a refactoring of
the msg locking code - we no longer do unlocked operations, as the use
case for it has mostly gone away. It is potentially possible only at
very low-end systems, and there the small additional overhead of doing
the locking does not really hurt. Instead, the removal of that
capability can actually slightly improve performance in common cases,
as the code path is smaller and requires slightly less memory writes.
That probably outperforms the extra locking overhead (which in the
low-end case always happens in user space, without need for kernel
support as we can always directly aquire the lock - there is no
contention at all).
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The "queue.xxx" parameter set was not supported, and legacy ruleset
config statements did not work (by intention). The fix introduces the
"queue.xxx" parameter set. It has some regression potential, but only
for the new functionality. Note that using that interface it is possible
to specify duplicate queue file names, which will cause trouble. This
will be solved in v7.3, because there is a too-large regression
potential for the v7.2 stable branch.
|