Привет всем.
Хотелось бы услышать советы как сделать логгер лучше.
У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи.
Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей.
Как бы можно было бы ускорить работу с логгером?
15.03.10 11:24: Перенесено модератором из 'C/C++' — Кодт
Здравствуйте, na1s, Вы писали:
N>Привет всем. N>Хотелось бы услышать советы как сделать логгер лучше. N>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи. N>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей. N>Как бы можно было бы ускорить работу с логгером?
Писал свой логгер. Выводы следующие.
Если после каждой записи делать fflush (открывать и закрывать — это лишнее), то работа резко замедляется. Попытка перейти на чистый Win32 (FlushFileBuffers) тоже ничего не дала.
В конечном счете пришлось реализовать буферизацию. Записи заносятся в список, который пакетом записывается в файл периодически. Что еще можно — принудительно записывать в файл, если появилась запись с признаком "важная", естественно, при этом запишутся и все предыдущие.
Присоединяюсь к вышесказанному.
В качестве буфера я использовал файл, отображаемый в память, который сбрасывался
на диск при заполнении. С очень хорошими результатами.
Если не поможет все вышеперечисленное — смотрите в сторону отдельного приложения — логгера
и связи с ним через сокеты или именованые каналы. Больше работы, зато надежно
Здравствуйте, 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. работать должно быстрее..
в общем одни плюсы
сам процесс логирования разумно выносить в отдельную нитку- поскольку это самая тормазная операция(сотни микросекунд на запись если в файл, и миллисекунды если в бд), также при подготовке строки к записи разумно не пользоваться стандартными стримами- в зависимости от компилятора и stl'я они могут быть очень медленными (десятки а то и сотни микросекунд на запись).
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, na1s, Вы писали:
N>>Привет всем. N>>Хотелось бы услышать советы как сделать логгер лучше. N>>У нас есть логгер, и вот он выводит инфу, но выводит он ее, каждый раз открывая и закрывая файл после записи. N>>Из-за этого с логгер работает очень медленно, хотя я конечно не уверен, может быть и из-за большого количества записей. N>>Как бы можно было бы ускорить работу с логгером?
PD>Писал свой логгер. Выводы следующие.
PD>Если после каждой записи делать fflush (открывать и закрывать — это лишнее), то работа резко замедляется. Попытка перейти на чистый Win32 (FlushFileBuffers) тоже ничего не дала. PD>В конечном счете пришлось реализовать буферизацию. Записи заносятся в список, который пакетом записывается в файл периодически. Что еще можно — принудительно записывать в файл, если появилась запись с признаком "важная", естественно, при этом запишутся и все предыдущие.
А как быть если, например segfault, и нельзя ничего посмотреть, так как данные пропадут?
N>А как быть если, например segfault, и нельзя ничего посмотреть, так как данные пропадут?
Что такое segfault — не знаю, но, полагаю, падение программы. Если причина аппаратная (сбой питания) — ничего не поделаешь, что успело — то записалось. Если программная — можно ловить исключения и при невозможности возобновления работы как минимум сбросить то, что уже накопилось, прежде чем закрыться. См. SetUnhandledExceptionHandler
Здравствуйте, Sni4ok, Вы писали:
S>сам процесс логирования разумно выносить в отдельную нитку- поскольку это самая тормазная операция(сотни микросекунд на запись если в файл, и миллисекунды если в бд), также при подготовке строки к записи разумно не пользоваться стандартными стримами- в зависимости от компилятора и stl'я они могут быть очень медленными (десятки а то и сотни микросекунд на запись).
+100.
Однозначно вывод в отдельном потоке.
Самый жесткий вариант — когда файл находится на сети, и есть несколько желающих что-нить в него записать.
Вариант с набором записей и сбросом по достижении какого-то предела не пойдет, т.к. в случае нескольких пользователей лога сильно портится временной порядок сообщений.
— асинхронные попытки получить файл на запись (с одновременным накоплением сообщений)
— асинхронный сброс накопленных сообщений в файл
— ограничение на время удержания файла в открытом состоянии (даже если остались сообщения) с учетом кол-ва накопленных сообщений (чем больше сообщений, тем меньше время)
— использование глобального ивента для нотификации об открытом состоянии файла (избавляет приложения на той же машине от бесплодных попыток получить доступ к файлу).
Здравствуйте, rus blood, Вы писали:
RB>Вариант с набором записей и сбросом по достижении какого-то предела не пойдет, т.к. в случае нескольких пользователей лога сильно портится временной порядок сообщений.
почему? в буфер кладется текст соощения + timestamp. последовательность добавления сообщений обеспечивается например очередью. не вижу проблем кроме "своевременности" обновления логфайла на диске