Комментарии
Избранное
Подписка
Сортировка:
Древо
Долго грузится и вываливается на 100%
| Код |
|---|
{Форма.ФормаОтчета(40)}: Преобразование значения к типу Дата не может быть выполнено
СтрокаТаблДанных.Дата=Дата(ДатаФайлаСтр+Сред(ТекСтрока,1,2)+Сред(ТекСтрока,4,2));
Показать полностью |
В процедуре ПрочитатьДанныеФайлов() замените условие
Если Сред(Строка,3,1)=":" Тогда
на
Если Сред(Строка,3,1)=":" И Сред(Строка,6,1)="." Тогда
так как в некоторых случаях текст, например запросов, может содержать символ двоеточия.
Если Сред(Строка,3,1)=":" Тогда
на
Если Сред(Строка,3,1)=":" И Сред(Строка,6,1)="." Тогда
так как в некоторых случаях текст, например запросов, может содержать символ двоеточия.
{Форма.ФормаОтчета(20)}: Ошибка при вызове метода контекста (Добавить): Неверное имя колонки
ТаблДанныхКолонки.Добавить(ИмяКолонки,Новый ОписаниеТипов("Строка",,Новый КвалификаторыСтроки(1000, ДопустимаяДлина.Переменная)),ПредставлениеКолонки);
по причине:
Неверное имя колонки
Могу прислать логи на мыло
ТаблДанныхКолонки.Добавить(ИмяКолонки,Новый ОписаниеТипов("Строка",,Новый КвалификаторыСтроки(1000, ДопустимаяДлина.Переменная)),ПредставлениеКолонки);
по причине:
Неверное имя колонки
Могу прислать логи на мыло
(38)
1. Переделал общий принцип парсинга строк. К сожелению новый алгоритм немного медленнее старого, но ,по-крайней мере, избавляет от ошибок чтения.
2. Ухожу от идеи обобщения значений параметров от разных событий в одно (они практически все пересекаются)
3. Добавил осмысленную расшифровку параметров.
Список известных мне параметров теперь находится в макете обработки. Если при парсинге параметр в макете не найден - он воспринимается как значение какого то другого параметра. Поэтому, кому не лень - просмотрите макет на выявление лишних или недостающий параметров и сообщите сюда. Я буду редактировать список.
1. Переделал общий принцип парсинга строк. К сожелению новый алгоритм немного медленнее старого, но ,по-крайней мере, избавляет от ошибок чтения.
2. Ухожу от идеи обобщения значений параметров от разных событий в одно (они практически все пересекаются)
3. Добавил осмысленную расшифровку параметров.
Список известных мне параметров теперь находится в макете обработки. Если при парсинге параметр в макете не найден - он воспринимается как значение какого то другого параметра. Поэтому, кому не лень - просмотрите макет на выявление лишних или недостающий параметров и сообщите сюда. Я буду редактировать список.
(38) Да, все читает нормально, спасибо :-)
Только вот еще что (в прошлый раз забыл написать): почему у тебя нет такого важного поля, как длительность?
В поей простецкой обработке она получалась так:
Получается значение в десятитысячных долях секунды
Только вот еще что (в прошлый раз забыл написать): почему у тебя нет такого важного поля, как длительность?
В поей простецкой обработке она получалась так:
Длительность = Число(Сред(ТекСтрока, 7, 4));Получается значение в десятитысячных долях секунды
(42) Помарочка. Длительность идёт сразу после даты. В обработке же - <уровень>.
mm:ss.tttt-d, <наименование>, <уровень>, <ключевые свойства>
· mm — номер минуты в текущем часе;
· ss — номер секунды в текущей минуте;
· tttt — номер десятитысячной доли текущей секунды;
· d — длительность события в десятитысячных секунды;
· <наименование> — наименование события;
· <уровень> — уровень события в стеке текущего потока;
mm:ss.tttt-d, <наименование>, <уровень>, <ключевые свойства>
· mm — номер минуты в текущем часе;
· ss — номер секунды в текущей минуте;
· tttt — номер десятитысячной доли текущей секунды;
· d — длительность события в десятитысячных секунды;
· <наименование> — наименование события;
· <уровень> — уровень события в стеке текущего потока;
Широкий,
доработал твою обработку на фильтр по периоду на момент чтения файлов ТЖ.
Т.к. обычно нужно смотреть логи, например, за последний час. Понятно что можно было задать фильтр уже после прочтения в настройках СКД, но если логов очень много, то на это тратится время, поэтому удобней установить фильтр при чтении.
А так, спасибо за обработку!
Сэкономил кучу времени на написании чего то подобного.
Если понравится фильтр - может обновить свой дистрибутив)
доработал твою обработку на фильтр по периоду на момент чтения файлов ТЖ.
Т.к. обычно нужно смотреть логи, например, за последний час. Понятно что можно было задать фильтр уже после прочтения в настройках СКД, но если логов очень много, то на это тратится время, поэтому удобней установить фильтр при чтении.
А так, спасибо за обработку!
Сэкономил кучу времени на написании чего то подобного.
Если понравится фильтр - может обновить свой дистрибутив)
Прикрепленные файлы:
ЧтениеЛоговТехнологическогоЖурнала.erf
Bitnikov пишет:
Широкий,
доработал твою обработку на фильтр по периоду на момент чтения файлов ТЖ.
Т.к. обычно нужно смотреть логи, например, за последний час. Понятно что можно было задать фильтр уже после прочтения в настройках СКД, но если логов очень много, то на это тратится время, поэтому удобней установить фильтр при чтении.
А так, спасибо за обработку!
Сэкономил кучу времени на написании чего то подобного.
Если понравится фильтр - может обновить свой дистрибутив)
ПоказатьШирокий,
доработал твою обработку на фильтр по периоду на момент чтения файлов ТЖ.
Т.к. обычно нужно смотреть логи, например, за последний час. Понятно что можно было задать фильтр уже после прочтения в настройках СКД, но если логов очень много, то на это тратится время, поэтому удобней установить фильтр при чтении.
А так, спасибо за обработку!
Сэкономил кучу времени на написании чего то подобного.
Если понравится фильтр - может обновить свой дистрибутив)
Пытался открыть твою. обработку - выбивает ошибку при выполнении файловой операции.
Она случаем не под 8.2?
(67) Почему то не читает. Указываю интервал. Пишет копирование во временный каталог. Нажимаю сформировать - пустой журнал. 8.1.15
(66) Автор, если не сложно, сделай пожалуйста, возможность установки интервала более тонкую, до минут(десятков минут). Час это очень много, на больших журналах вываливается километровая портянка. Понимаю что это можно затем отбором фильтровать. Но если есть основной фильтр туда уже не с руки лазить. И мелкая просьба - выбор периода лучше разместить в одной строке с выбором каталога. Для больших журналов на небольших мониторах каждая строчка свободного места нужна.Фраза Печатная форма - тоже отъедает полезную площадь. Как и любые заголовки в самой печатной форме. Кто пользуется тот и так знает что это.
Кроме того обнаружил такую особенность. При чтении большого журнала - 500000 строк, бодро начинает читать, затем замедляется и на 180000 строке останавливается. Проверил на последней и предпоследней версии обработки. Старая версия redlog читает нормально весь журнал. Места на диске много, памяти с большим запасом. Запускал обработку на сервере 1с. Один из процессоров сервера уходит в 100% при этом, там и остается.
(66) Автор, если не сложно, сделай пожалуйста, возможность установки интервала более тонкую, до минут(десятков минут). Час это очень много, на больших журналах вываливается километровая портянка. Понимаю что это можно затем отбором фильтровать. Но если есть основной фильтр туда уже не с руки лазить. И мелкая просьба - выбор периода лучше разместить в одной строке с выбором каталога. Для больших журналов на небольших мониторах каждая строчка свободного места нужна.Фраза Печатная форма - тоже отъедает полезную площадь. Как и любые заголовки в самой печатной форме. Кто пользуется тот и так знает что это.
Кроме того обнаружил такую особенность. При чтении большого журнала - 500000 строк, бодро начинает читать, затем замедляется и на 180000 строке останавливается. Проверил на последней и предпоследней версии обработки. Старая версия redlog читает нормально весь журнал. Места на диске много, памяти с большим запасом. Запускал обработку на сервере 1с. Один из процессоров сервера уходит в 100% при этом, там и остается.
aspirator23 пишет:
Почему то не читает. Указываю интервал. Пишет копирование во временный каталог. Нажимаю сформировать - пустой журнал. 8.1.15
Почему то не читает. Указываю интервал. Пишет копирование во временный каталог. Нажимаю сформировать - пустой журнал. 8.1.15
Если журнал пустой - то тут либо на самом деле ничего нет, либо фильтры поставлены неправильно.
Автор, если не сложно, сделай пожалуйста, возможность установки интервала более тонкую, до минут(десятков минут). Час это очень много, на больших журналах вываливается километровая портянка. Понимаю что это можно затем отбором фильтровать. Но если есть основной фильтр туда уже не с руки лазить.
На самом деле идеология другая - набор файлов читаем только один раз, а потом отборами фильтруем необходимую выводимую информацию.
Ты же предлагаешь каждый раз эти файлы читать - я считаю это не корректным.
Если напрягает, что при выборе периода сразу формируется отчет - отрежь это сам в коде. Код я не закрывал - переделывайте под себя.
И мелкая просьба - выбор периода лучше разместить в одной строке с выбором каталога. Для больших журналов на небольших мониторах каждая строчка свободного места нужна.Фраза Печатная форма - тоже отъедает полезную площадь. Как и любые заголовки в самой печатной форме. Кто пользуется тот и так знает что это.
Удивлен что до сих пор кто то юзает мелкие мониторы :)
Поправил обработку - добавил на командную панель кнопку "Панель чтения" - она регулирует видимость настроек.
Кроме того обнаружил такую особенность. При чтении большого журнала - 500000 строк, бодро начинает читать, затем замедляется и на 180000 строке останавливается. Проверил на последней и предпоследней версии обработки. Старая версия redlog читает нормально весь журнал. Места на диске много, памяти с большим запасом. Запускал обработку на сервере 1с. Один из процессоров сервера уходит в 100% при этом, там и остается.
Насчет замедления чтения - тут скорее всего кончается оперативка и начинает свопирование в виртуалку. Я бы не рекомендовал такие большие объемы считывать - для анализа сложно и комп насилуешь.
(70) спасибо за доработку. Большие выборки приходится делать тогда когда нужно посмотреть за неделю аварийные завершения. В журнал кроме аварий пишется и CONN, он занимает больше всего места. А первичное чтение читает всех поголовно в том числе и CONN. Поэтому и получается 500000 строк. Проблема зависания обработки не связана с памятью. Обработка запускается на сервере. Общей памяти на сервере с большим запасом. При работе обработки потребление память на сервере не растет. На сервере запущено несколько rphost. На всех них память распределена примерно равномерно и она очень невелика - 200мб на момент измерений. Свободного места на диске С тоже достаточно. Многократно больше файла подкачки. Как и писал один из процессоров уходит в 100% и там и остается. Приходится снимать аварийно. Посмотрел код - подозрение на вот этот цикл. Еще не проверял, но возможно он из него на каком-то файле не выходит. Строка 131-152. Конкретно 132-133 строки.
Посмотрел старую версию там ты для чтения файл используешь FileSystemObject. Старая версия не виснет.
Пока Истина Цикл
Строка=ЧтениеТекста.ПрочитатьСтроку();
Если Строка=Неопределено Тогда
Прервать;
КонецЕсли;
КоличествоОбработано=КоличествоОбработано+1;
.......................................
КонецЦикла; ПоказатьПосмотрел старую версию там ты для чтения файл используешь FileSystemObject. Старая версия не виснет.
aspirator23 пишет:
спасибо за доработку. Большие выборки приходится делать тогда когда нужно посмотреть за неделю аварийные завершения. В журнал кроме аварий пишется и CONN, он занимает больше всего места. А первичное чтение читает всех поголовно в том числе и CONN. Поэтому и получается 500000 строк. Проблема зависания обработки не связана с памятью. Обработка запускается на сервере. Общей памяти на сервере с большим запасом. При работе обработки потребление память на сервере не растет. На сервере запущено несколько rphost. На всех них память распределена примерно равномерно и она очень невелика - 200мб на момент измерений. Свободного места на диске С тоже достаточно. Многократно больше файла подкачки. Как и писал один из процессоров уходит в 100% и там и остается. Приходится снимать аварийно. Посмотрел код - подозрение на вот этот цикл. Еще не проверял, но возможно он из него на каком-то файле не выходит. Строка 131-152. Конкретно 132-133 строки.
спасибо за доработку. Большие выборки приходится делать тогда когда нужно посмотреть за неделю аварийные завершения. В журнал кроме аварий пишется и CONN, он занимает больше всего места. А первичное чтение читает всех поголовно в том числе и CONN. Поэтому и получается 500000 строк. Проблема зависания обработки не связана с памятью. Обработка запускается на сервере. Общей памяти на сервере с большим запасом. При работе обработки потребление память на сервере не растет. На сервере запущено несколько rphost. На всех них память распределена примерно равномерно и она очень невелика - 200мб на момент измерений. Свободного места на диске С тоже достаточно. Многократно больше файла подкачки. Как и писал один из процессоров уходит в 100% и там и остается. Приходится снимать аварийно. Посмотрел код - подозрение на вот этот цикл. Еще не проверял, но возможно он из него на каком-то файле не выходит. Строка 131-152. Конкретно 132-133 строки.
Хочешь сказать , что встроенный 1с объект по чтению из потока глючит?
(72) Посмотрел в отладчике. Виснет, точнее не виснет а очень долго обрабатывает в процедуре
ДобавитьДанныеВТаблицуДанных(СтрокаДанных,ДатаФайлаСтр)
в нее передается строка вида
08:39.3911-0,EXCPCNTX,0,ClientComputerName......
которая имеет огромный размер. В ней идет описание какого-то сумасшедшего запроса, длина которого более 200 тыс.слов
В процедуре входим в цикл(строка 76)
И вот тут-то и происходит долгая обработка. В конце концов она его обрабатывает и идет дальше.
Так что претензии которые раньше высказывал в (71) снимаются.
Возможное решение этой проблемы - обрезать строки. Добавить в настройки флаг "Отражать строки сокращенно" и резать по нему длинные строки до каких-то разумных пределов, например 200-500. В отчете все равно такой "сверхзапрос" невозможно просмотреть.
Может для полного счастья отражать в отчете что данная строка отражена сокращенно.
Могу прислать этот лог, если есть желание с ним "побороться".
ДобавитьДанныеВТаблицуДанных(СтрокаДанных,ДатаФайлаСтр)
в нее передается строка вида
08:39.3911-0,EXCPCNTX,0,ClientComputerName......
которая имеет огромный размер. В ней идет описание какого-то сумасшедшего запроса, длина которого более 200 тыс.слов
В процедуре входим в цикл(строка 76)
Для НомерСтроки=1 По МногострочнаяЧастьКолСтрок Цикл
.........
И вот тут-то и происходит долгая обработка. В конце концов она его обрабатывает и идет дальше.
Так что претензии которые раньше высказывал в (71) снимаются.
Возможное решение этой проблемы - обрезать строки. Добавить в настройки флаг "Отражать строки сокращенно" и резать по нему длинные строки до каких-то разумных пределов, например 200-500. В отчете все равно такой "сверхзапрос" невозможно просмотреть.
Может для полного счастья отражать в отчете что данная строка отражена сокращенно.
Могу прислать этот лог, если есть желание с ним "побороться".
Bitnikov пишет:
Широкий, в моем бантике можно было читать логи и за последние 10 минут... Не обязательно кратно 1-му часу.
Дело конечно Ваше, но ИМХО зря сразу делать такое ограничение.
Широкий, в моем бантике можно было читать логи и за последние 10 минут... Не обязательно кратно 1-му часу.
Дело конечно Ваше, но ИМХО зря сразу делать такое ограничение.
Расскажи, каким же образом? То, что ты сделал период с точностью до сек ничего не меняет :)
Файлы лога хранятся с периодичностью один час.
Чтобы сделать большую точностью, надо уже анализировать не имя файла, а его содержимое - т.е. строки.
А это по ресурсоемкости примерно то же, что и считать один файл без анализа строк но при формировании поставить фильтр на время.
Широкий пишет:
Расскажи, каким же образом? То, что ты сделал период с точностью до сек ничего не меняет
Файлы лога хранятся с периодичностью один час.
Чтобы сделать большую точностью, надо уже анализировать не имя файла, а его содержимое - т.е. строки.
А это по ресурсоемкости примерно то же, что и считать один файл без анализа строк но при формировании поставить фильтр на время.
Расскажи, каким же образом? То, что ты сделал период с точностью до сек ничего не меняет
Файлы лога хранятся с периодичностью один час.
Чтобы сделать большую точностью, надо уже анализировать не имя файла, а его содержимое - т.е. строки.
А это по ресурсоемкости примерно то же, что и считать один файл без анализа строк но при формировании поставить фильтр на время.
Сделал фильтр при чтении каждой строки, анализирующий период с точностью до секунды.
Если период не подходит - строка не добавляется в таблицу СКД.
Bitnikov пишет:
Сделал фильтр при чтении каждой строки, анализирующий период с точностью до секунды. Если период не подходит - строка не добавляется в таблицу СКД.
Сделал фильтр при чтении каждой строки, анализирующий период с точностью до секунды. Если период не подходит - строка не добавляется в таблицу СКД.
В твоей обработке этого нет.
И как я описал это раньше - делать это считаю не разумным
(81) Столкнулся с проблемой чтения больших логов.
Включен Полный технологический журнал. Логи за сутки 24ГБ.
Возникает проблема чтения их.
Первая - долго читает, но это как-то еще можно оправдать.
Вторая - при попытке сформировать отчет - падает с нехваткой памяти.
Пример:
Выбрал интервал один час, прочитал файлы. Память съел 2ГБ.
Указал фильтр - без CONN. Задал фильтр выборки интервала событий - всего 15 минут.
Запустил отчет Сформировать. Память доросла до 3.8Гб и "упала" программа с "нехваткой памяти".
Запускал на сервере (64-разряда) где памяти 16Гб и доступно было 12ГБ. Возможно есть ограничение на размер выделяемой памяти на процесс на сервере, либо это проблема приложения 1с.
Как победить эту проблему? Как читать большие логи?
Включен Полный технологический журнал. Логи за сутки 24ГБ.
Возникает проблема чтения их.
Первая - долго читает, но это как-то еще можно оправдать.
Вторая - при попытке сформировать отчет - падает с нехваткой памяти.
Пример:
Выбрал интервал один час, прочитал файлы. Память съел 2ГБ.
Указал фильтр - без CONN. Задал фильтр выборки интервала событий - всего 15 минут.
Запустил отчет Сформировать. Память доросла до 3.8Гб и "упала" программа с "нехваткой памяти".
Запускал на сервере (64-разряда) где памяти 16Гб и доступно было 12ГБ. Возможно есть ограничение на размер выделяемой памяти на процесс на сервере, либо это проблема приложения 1с.
Как победить эту проблему? Как читать большие логи?
(83) Ниче так.. 24 гига :)
Считанные данные хранятся в памяти - поэтому такой объем и прочитать и вывести не получится.
В твоем случае надо делать свою базу - туда кидать данные.. А потом запросами получать нужное.
Структуру базы можно глянуть проанализировав обработку
Считанные данные хранятся в памяти - поэтому такой объем и прочитать и вывести не получится.
В твоем случае надо делать свою базу - туда кидать данные.. А потом запросами получать нужное.
Структуру базы можно глянуть проанализировав обработку
(84) А если хотя бы добавить возможность обработки больших данных кусками: наполнять ТЗ до определенного размера, сбросить их в промежуточный файл, а затем следующий кусок..?
Возможно в обработке добавить возможность сохранения данных в SQL базу? Потребность в использовании технологических журналов как правило возникает именно на больших базах, с большими логами.
Широкий пишет:
В твоем случае надо делать свою базу - туда кидать данные.. А потом запросами получать нужное.
В твоем случае надо делать свою базу - туда кидать данные.. А потом запросами получать нужное.
Возможно в обработке добавить возможность сохранения данных в SQL базу? Потребность в использовании технологических журналов как правило возникает именно на больших базах, с большими логами.
aspirator23 пишет:
А если хотя бы добавить возможность обработки больших данных кусками: наполнять ТЗ до определенного размера, сбросить их в промежуточный файл, а затем следующий кусок..?
А если хотя бы добавить возможность обработки больших данных кусками: наполнять ТЗ до определенного размера, сбросить их в промежуточный файл, а затем следующий кусок..?
У тебя и так данные в логах сидят.. ты тупо прочитать не можешь.
aspirator23 пишет:
Возможно в обработке добавить возможность сохранения данных в SQL базу?
Возможно в обработке добавить возможность сохранения данных в SQL базу?
Почему именно скуль? Чем отдельная конфигурация на 1с не подходит.
aspirator23 пишет:
Потребность в использовании технологических журналов как правило возникает именно на больших базах, с большими логами.
Потребность в использовании технологических журналов как правило возникает именно на больших базах, с большими логами.
Не надо про большие базы..
У нас документооборот 3-5 тыс документов/день. И у меня ни разу не возникало потребностей анализировать кусок лога даже на 50 мегов. Ты просто задолбаешься их читать.
Или делай корректную настройку logcfg.xml - чтобы только нужные события попадали или делай отдельную базу и грузи туда
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|
||
|
|
|