|
|
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
На форуме видел несколько решений записи в файл из нескольких потоков: через крит. секции, через события, через отдельный поток. Сравнение не проводил, но везде было накидано на вентилятор. Единственная реализация, которая внушает доверие, но много кода - это от Wildcat (точно не помню). Написал вот это) Код: pascal 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. Задается размер файла, кол-во файлов. Запись при хорошем раскладе не очень часто (раз в 3-5 сек) Что тут не так)? Покритикуйте, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 08:18 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
Вся работа с файлом в критической секции и в том же потоке. То есть все решение так себе для "безопасного многопоточного логирования", тут и writeln с append хватит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 08:35 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
wadman, а скажите почему так себе? можно развернутый ответ? Ведь крит. секции защищают файл от "плохой записи", а что здесь "опасного"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 08:54 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrb, Это подозрений не вызывает? Код: pascal 1. Может лучше Код: pascal 1. ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:16 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
DarkMaster, вызвало бы, если бы не AnsiString, но да, лучше переделать ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:21 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbможно развернутый ответ? Тут что-то пояснить нужно? wadmanВся работа с файлом в критической секции и в том же потоке. Проще тогда делать так, чтобы каждый поток писал в свой файл. А лучше убрать тормоза при работе с файловой системой в отдельный поток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:22 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
wadman, я думал над отдельным потоком, но может сложиться ситуация, когда приложение станет колом и я не увижу последнее удачное действие, так как в потоке писателе может скопиться очередь ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:26 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
а потоков может быть много-много и файлов будет много много, а потом еще надо это все сводить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:29 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbв потоке писателе может скопиться очередь Причина надумана. cptngrbраз в 3-5 сек С тем же успехом процедура логирования может "свалиться" и не записать в файл. Но если все так серьезно, то логированием должен заниматься и вовсе отдельный процесс, а не поток. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 09:32 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
Зачем так сложно, достаточно открывать с share_deny_write, а если не открылось - небольшой слип и повтор. При записи раз в 3 секунды проблем не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:04 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
Василий 2, ну пока 3-5 сек, а потом 1 раз в секунду. А если 5-10 раз в секунду, то такая схема работать не будет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:30 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbА если 5-10 раз в секунду, то такая схема работать не будет? У меня опрос нескольких десятков железяк по RS полностью пишется в формате дампа в один файл отдельным потоком-логером, плюсом в tmemo. В теории и тысячи ему не проблема. Работает без нареканий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:36 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
Мне хватает mutex + writeln ля многопроцессного протокола и критической секции + writeln для многопоточного. Трудностей ни со скоростью ни с полнотой протоколирования не испытываю ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:39 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
wadmanА лучше убрать тормоза при работе с файловой системой в отдельный потокНе только тормоза. А и очередность действий, записанных в лог, может нарушиться, если куча потоков будет ждать входа в секцию. Сами действия нарушатся, логика работы. Изменится, скажем так. Тормоза изменят логику. А добавление в очередь происходит мгновенно, и потому всё работает, как задумано. Лично у меня в одну миллисекунду добавляется куча записей из разных потоков в 1 файл. И таких файлов несколько может быть. Несколько объеутов логирования с разным префиксом файла. Я флажок сделал - как логи (файлы) разбивать - некоторые бью по месяцам, некоторые по дням, а некоторые - по часам. Суффиксы добавляю. P.S. Ни разу у меня ничего не "становилось колом". Наоборот, всегда видно, кто перестал писать, а кто еще пишет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:45 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrb Код: pascal 1. Если речь о записи логов, то имхо разумнее каждому потоку писать в свой файл. Точнее, не "в свой", а в "в файл, соответствующий тому главному объекту, с которым работает поток". Скажем, если у меня в репликации настроены двенадцать связанных серверов - логи пишутся в \2018\07\02-Питер.log, \2018\07\02-Самара.log итп. Поток, начиная работу с конкретным сервером - начинает писать в соответствующий ему лог, при этом дополнительная синхронизация не нужна по той причине, что два потока с одним сервером работать никогда не будут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:52 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
YuRock, а очередь как организовывали? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 10:52 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
YuRockу меня в одну миллисекунду добавляется куча записей из разных потоков в 1 файл. И таких файлов несколько может бытьпорой кажется что основное чем занимается сервис это гадить в логи/базу и размер одного файла в десятки гиг в порядке вещей, так что логи архивировать/херить только успевай ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 11:52 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbYuRock, а очередь как организовывали?TList с крит. секцией обычный. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 12:19 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
vavanразмер одного файла в десятки гиг в порядке вещей, так что логи архивировать/херить только успевай Ну не одного а многих файлов разбитых. Огромные файлы читать неудобно. И логи старше 30 (по умолчанию) дней автоматом прибиваются. но гиг ~30 стабильно лежат постоянно, это да. Никому не мешают особо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 12:23 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
YuRockне одного а многихтак я про свои YuRockОгромные файлы читать неудобнопорой да, но если часто бить то порой накопиться их может изрядно, тоже неудобняк. хорошо когда динамически можно подстроить частоту/размерность дробления YuRockлоги старше 30 (по умолчанию) дней автоматом прибиваютсяя несколько месяцев стараюсь архивы держать пока есть возможность, читай свободное место. никогда не знаешь когда разбор полетов понадобится YuRockгиг ~30 стабильно лежат постоянностолько у меня и за день может навалить а, еще и каталоги с логами сжимаются ср-вами винды, тоже выручает несколько ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 12:47 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
YuRock, а почему не TThreadList? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 12:49 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbYuRock, а почему не TThreadList? Не могу сказать. Когда-то мне так захотелось, не помню - решил всю логику скрыть. Это фактически и есть TList с крит. секцией. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 14:35 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
Я использую TQueue, так как не нужно задумываться какое сообщение брать следующее. В TList всегда первый элемент брать. Не красиво. Или я не прав? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 16:59 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrb, будет, только там уже код ожидания будет не очень оптимальный - либо усыплять на большее время, либо делать больше попыток захватить файл. А это чревато торможением потока или перемешиванием событий (более позднее может успеть захватить файл раньше, чем более раннее). Но если нагрузка не очень большая, то сойдет. Более правильно, разумеется, сделать очередь записей и выгрузку на диск отдельным потоком. Но для 2-3 записей в секунду это оверхед) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 19:19 |
|
||
|
Логирование работы потоков
|
|||
|---|---|---|---|
|
#18+
cptngrbЯ использую TQueue, так как не нужно задумываться какое сообщение брать следующее. В TList всегда первый элемент брать. Не красиво. Или я не прав?Ну у меня тоже TQueue, только самописное Из TList, конечно, первый (нулевой) элемент брать, если FIFO. А для логов так и нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.07.2018, 23:03 |
|
||
|
|

start [/forum/topic.php?fid=58&startmsg=39668147&tid=2040671]: |
0ms |
get settings: |
9ms |
get forum list: |
20ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
199ms |
get topic data: |
11ms |
get forum data: |
2ms |
get page messages: |
72ms |
get tp. blocked users: |
2ms |
| others: | 237ms |
| total: | 560ms |

| 0 / 0 |
