Привет всем.
Хотелось бы услышать советы как сделать логгер лучше.
У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
Как бы можно было бы ускорить работу с логгером?

Здравствуйте, na1s, Вы писали:

N>Как бы можно было бы ускорить работу с логгером?

Наверное самый простой вариант — буферизация Складировать записи, а писать их в файл, когда количество достигнет некоторой границы.

Здравствуйте, na1s, Вы писали:

N>Привет всем.
N>Хотелось бы услышать советы как сделать логгер лучше.
N>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
N>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
N>Как бы можно было бы ускорить работу с логгером?

Писал свой логгер. Выводы следующие.

Если после каждой записи делать fflush (открывать и закрывать — это лишнее), то работа резко замедляется. Попытка перейти на чистый Win32 (FlushFileBuffers) тоже ничего не дала.
В конечном счете пришлось реализовать буферизацию. Записи заносятся в список, который пакетом записывается в файл периодически. Что еще можно — принудительно записывать в файл, если появилась запись с признаком "важная", естественно, при этом запишутся и все предыдущие.

Здравствуйте.

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

Если не поможет все вышеперечисленное — смотрите в сторону отдельного приложения — логгера
и связи с ним через сокеты или именованые каналы. Больше работы, зато надежно

N>Как бы можно было бы ускорить работу с логгером?

void setbuf(FILE *stream, char *buf);
int setvbuf(FILE *stream, char *buf, int mode, size_t size);

Здравствуйте, na1s, Вы писали:

N>Привет всем.
N>Хотелось бы услышать советы как сделать логгер лучше.
N>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
N>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
N>Как бы можно было бы ускорить работу с логгером?

Открывать и закрывать каждый раз это, конечно, слишком. Чучше далать flush. Но это всё-равно не сильно улучшит производительность. По своему опыту flush после каждой записи бывает очень полезен, чтобы увидеть, что программа делала непредственно перед падением. Попробуйте сделать лог менее шумным.

Здравствуйте, na1s, Вы писали:

N>Привет всем.
N>Хотелось бы услышать советы как сделать логгер лучше.
N>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
N>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
N>Как бы можно было бы ускорить работу с логгером?

http://msdn.microsoft.com/en-us/library/ms810613.aspx
создавать файлы ограниченного размера, и при заполнении просто переходить на следующий...
log1
log2
....
на все случаи включая падения, система ответственна за flushing. работать должно быстрее..
в общем одни плюсы

Здравствуйте, na1s, Вы писали:

сам процесс логирования разумно выносить в отдельную нитку- поскольку это самая тормазная операция(сотни микросекунд на запись если в файл, и миллисекунды если в бд), также при подготовке строки к записи разумно не пользоваться стандартными стримами- в зависимости от компилятора и stl'я они могут быть очень медленными (десятки а то и сотни микросекунд на запись).

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, na1s, Вы писали:

N>>Привет всем.
N>>Хотелось бы услышать советы как сделать логгер лучше.
N>>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
N>>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
N>>Как бы можно было бы ускорить работу с логгером?

PD>Писал свой логгер. Выводы следующие.

PD>Если после каждой записи делать fflush (открывать и закрывать — это лишнее), то работа резко замедляется. Попытка перейти на чистый Win32 (FlushFileBuffers) тоже ничего не дала.
PD>В конечном счете пришлось реализовать буферизацию. Записи заносятся в список, который пакетом записывается в файл периодически. Что еще можно — принудительно записывать в файл, если появилась запись с признаком "важная", естественно, при этом запишутся и все предыдущие.

А как быть если, например segfault, и нельзя ничего посмотреть, так как данные пропадут?

Здравствуйте, na1s, Вы писали:


N>А как быть если, например segfault, и нельзя ничего посмотреть, так как данные пропадут?

Что такое segfault — не знаю, но, полагаю, падение программы. Если причина аппаратная (сбой питания) — ничего не поделаешь, что успело — то записалось. Если программная — можно ловить исключения и при невозможности возобновления работы как минимум сбросить то, что уже накопилось, прежде чем закрыться. См. SetUnhandledExceptionHandler

Здравствуйте, Sni4ok, Вы писали:

S>сам процесс логирования разумно выносить в отдельную нитку- поскольку это самая тормазная операция(сотни микросекунд на запись если в файл, и миллисекунды если в бд), также при подготовке строки к записи разумно не пользоваться стандартными стримами- в зависимости от компилятора и stl'я они могут быть очень медленными (десятки а то и сотни микросекунд на запись).

+100.

Однозначно вывод в отдельном потоке.

Самый жесткий вариант — когда файл находится на сети, и есть несколько желающих что-нить в него записать.
Вариант с набором записей и сбросом по достижении какого-то предела не пойдет, т.к. в случае нескольких пользователей лога сильно портится временной порядок сообщений.

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

Здравствуйте, na1s, Вы писали:

N>А как быть если, например segfault, и нельзя ничего посмотреть, так как данные пропадут?

в результате крэша должен остаться дамп памяти, в нем все можно посмотреть, только надо предусмотреть удобный вход в память логгера

You will always get what you always got
  If you always do  what you always did

Здравствуйте, rus blood, Вы писали:

RB>Вариант с набором записей и сбросом по достижении какого-то предела не пойдет, т.к. в случае нескольких пользователей лога сильно портится временной порядок сообщений.
почему? в буфер кладется текст соощения + timestamp. последовательность добавления сообщений обеспечивается например очередью. не вижу проблем кроме "своевременности" обновления логфайла на диске