Можно ли улучшить производительность системного журнала?

Question

У нас есть приложение в Linux, которое использует механизм syslog . После недели, проведенной в попытках выяснить, почему это приложение работает медленнее, чем ожидалось, мы обнаружили, что если мы удалим системный журнал и просто сделаем запись непосредственно в файл журнала, производительность значительно улучшится.

Я понимаю, почему системный журнал работает медленнее, чем прямая запись в файл. Но мне было интересно: есть ли способы настроить syslog для оптимизации его производительности?

Answer 1

Вы можете настроить syslogd (и, по крайней мере, rsyslog), чтобы он не синхронизировал файлы журнала после сообщения журнала, добавив "-" к пути файла журнала в файле конфигурации. Это повышает производительность за счет опасности потери сообщений журнала при сбое.

Answer 2

Существует несколько вариантов повышения производительности системного журнала:

• Оптимизация вызовов с помощью макроса

   int LogMask = LOG_UPTO(LOG_WARNING);
   #define syslog(a, ...) if ((a) & LogMask ) syslog((a), __VA_ARGS__)
  
   int main(int argc, char **argv)
   {
            LogMask = setlogmask(LOG_UPTO(LOG_WARNING));
            ...
   }
  

  Преимущество использования макроса для фильтрации вызовов системного журнала состоит в том, что весь вызов сводится к условному переходу по глобальной переменной, очень полезно, если вам случится есть вызовы DEBUG, которые переводят большие наборы данных через другие функции.

• setlogmask ()

  setlogmask(LOG_UPTO(LOG_LEVEL))
  

  setlogmask () оптимизирует вызов, не входя в / dev / log, но программа по-прежнему вызывать функции, используемые в качестве аргументов.

• фильтрация с помощью syslog.conf

   *.err                                               /var/log/messages
  

  "Подробности смотрите на странице man для syslog.conf."

• настроить системный журнал на асинхронное или буферизованное ведение журнала

  metalog используется для буферизации вывода журнала и сбрасывания его в блоках. фондовый syslog и syslog-ng не делай этого, насколько я знаю.

Answer 3

Прежде чем приступить к написанию нового демона, вы можете проверить, является ли syslog-ng более быстрым (или может быть настроен для более быстрого), чем обычный старый системный журнал.

Answer 4

Одна хитрость, которую вы можете использовать, если вы управляете источником для приложения журналирования, состоит в том, чтобы маскировать уровень журнала, который вы хотите в самом приложении, а не в syslog.conf. Я сделал это несколько лет назад с приложением, которое генерировало огромное, огромное, огромное количество журналов отладки. Вместо того чтобы удалять вызовы из производственного кода, мы просто маскировали, чтобы вызовы уровня отладки никогда не отправлялись демону. Я на самом деле нашел код, это Perl, но это всего лишь фронт вызова setlogmask (3).

use Sys::Syslog;
# Start system logging
# setlogmask controls what levels we're going to let get through.  If we mask
# them off here, then the syslog daemon doesn't need to be concerned by them
# 1   = emerg
# 2   = alert
# 4   = crit
# 8   = err
# 16  = warning
# 32  = notice
# 64  = info
# 128 = debug
Sys::Syslog::setlogsock('unix');
openlog($myname,'pid,cons,nowait','mail');
setlogmask(127); # allow everything but debug
#setlogmask(255); # everything
syslog('debug',"syslog opened");

Не уверен, почему я использовал десятичную вместо битовой маски ... пожимает плечами

Answer 5

Вы можете настроить уровень (или средство) syslogd для асинхронного ведения журнала, поставив минус перед путем к файлу журнала (т. Е .: user. * [Tab] - / var / log / user.log).

Приветствие.

Answer 6

Напишите свою собственную реализацию системного журнала. : -Р

Это может быть достигнуто двумя способами.

1. Напишите свой собственный LD_PRELOAD хук, чтобы переопределить функции системного журнала, и вместо этого вывести их на stderr. Я действительно написал пост об этом много лет назад: http://marc.info/?m=97175526803720: -P
2. Напишите свой собственный демон системного журнала. Это просто вопрос извлечения дейтаграмм из /dev/log! : -Р

Хорошо, хорошо, так что это оба оскорбительные ответы. Вы профилировали syslogd, чтобы увидеть, где оно больше всего душит?

Answer 7

Реализация syslog-async () может помочь, рискуя потерять строки журнала / ограниченные задержки в другое время. http://thekelleys.org.uk/syslog-async/

Примечание: «асинхронный» здесь относится к очереди событий журнала в вашем приложении, а не к параметру конфигурации выходного файла асинхронного syslogd, к которому относятся другие ответы.