(1) Подобные записи формируются в технологическом журнале, когда прерываются какие либо длительные транзакции.
Проблемы, к которым могут приводить длительные транзакции, в первую очередь связаны с избыточным потреблением каких-либо ресурсов: избыточные блокировки, избыточное потребление tempdb при работе с MS SQL Server.
На ИТС была статья по этому поводу. Поищи на its.1c.ru
Одина из самых общих классов. Да, выше все верно сказали, плюс такая же штука была, когда были проблемы с сетью, такая же штука была, когда виртуальны сервера мигрировали, почему-то 1С связь теряла между ними. Тут копать надо, не так просто. Кстати, проанализировать журнал можно довольно просто с помощью Инструментов Разработчика, там можно загрузить Тех журнал, просмотреть, передать таблицу в консоль запросов, хоть диаграмму по ним построить.
Вообще, может поможет, как-то анализировал логи тех журнала, разбирался в типах ошибок и отсортировал их по типам ошибок согласно гуидам, собирая информацию по ним в интернете по крупицам. Если кто кинет в меня ссылкой где есть нормальная информация на эту тему - буду благодарен
dd149677-3d47-4e05-a55f-4e75b13a441f Ошибка на сервере или соединение разорвано администратором
0874860b-2b41-45e1-bc2b-6e186eb37771 Ошибка программного лицензирования
9db1fa37-b455-4f3f-b8dd-7de0ea7d6da3 Файловые ошибки/Ошибки разделителей
SeanceContextException Не найдена лицензия.
60c686dc-798f-4d17-aadb-a90156a16eb8 Сеанс отсутствует или удален
81029657-3fe6-4cd6-80c0-36de78fe6657 Ошибка сетевого доступа к серверу
580392e6-ba49-4280-ac67-fcd6f2180121 Ошибка запросов GET/POST
acea3e6e-3687-4792-8319-09c009274c9a Ошибка рабочего процесса
DataBaseException Ошибки СУБД
a01f465c-ed70-442e-ada5-847668d7a41c Ошибка идентификации
95c658d1-d3d5-4ea9-8a81-1bf820fea4a8 Сеанс работы завершен администратором
LoadComponent(dbeng8) Ошибка загрузки компоненты dbeng8
b551bbc2-5f36-402b-bf62-ffc41825cb6b Ошибки исполнения отчетов
96380a22-60f7-4a8b-8fca-1224e6bc518f Транзакционные ошибки
(6) necropunk, а можно как то настроить ТЖ в рамках одной базы или название базы как то вытащить? на кластере крутится 7 баз хотелось сузить круг проблемы
(8) Внешняя обработка "Настройка технологического журнала" предназначена для создания и редактирования конфигурационного файла технологического журнала. Она позволяет настроить создание дампа аварийного завершения, а также указать перечень событий и условия, при которых информация будет записываться в технологический журнал.
Внешняя обработка НастройкаТехнологическогоЖурнала.epf для запуска находится на ИТС в каталоге \1CITS\EXE\ExtReps\Unireps82\TechnologicalLogSetup
\1CITS\EXE\ExtReps\Unireps83\TechnologicalLogSetup
соответственно
(12) necropunk, (9) CaptainMorgan, день №2. Пока все спокойно в части производительности. сделаны следующие настройки:
1. На серверах отключена поддержка протокола IPV6.
2. На SQL-базе настроен автоприрост. Запись каждые 500 мб. До этого стояло каждые 1%
3. Перенесены некоторые базы на другой сервер, активно использующие веб-сервисы
(14) asved.ru, у нас после первой же такой ошибки в процессе миграции серверов рабочий процесс не разбирался, а плодился до миллиона копий, забивая всю память, теряя связь с SQL, в общем, вообще все сервера 1С раком вставали.
Т.е. время определения, что это спящий сеанс 600 секунд, а время отрубания этого сеанса тоже 600 секунд. Щас плодения не наблюдаем.
Как показала практика 10 мин недостаточно, чтобы опеределить что это спящий сеанс. Пока пальцем в небо поставили 3 часа, т.е (10800 секунд).
Теперь стоит задача определить нормы обработки, работы конкретных операций во времени. т.е загрузка курсов валют из сайта нацбанка составляет 15 секунд. В таком формате. Есть у кого опыт? Так как юзеров много кто-то говорит медленно кто-то нормально. Нужен объективный инструмент по которому мы сами разработчики определили бы что та или иная операция вышла за рамки нормы.
(16) Bajo, вы на APDEX хотите все переложить что ли? Идея хорошая, даже подсистема "ОценкаПроизводительности" в БСП вам в помощь, но вот один минус - все начальные значения подбираются чисто субъективно и это мучение. Искать компромиссы, если пользователь говорит что отчет должен строиться за 1 секунду, а там только рлс отрабатывает 30 - ставить 30-40 и не париться, отчеты не очень важны. По документам берешь реальные данные, на загруженной базе, например во время нагрузочного тестирования, и в монопольном режиме. Говоришь с начальством, показываешь результаты, в результате, обычно договариваешься о чем-то среднем, изредка, когда там уж совсем что-то страшное, типа проведения реализации дольше минуты - анализ ЦУПом, оптимизация, потом снова к начальству. Зато один раз выставил и, в принципе, все работает, даже графики примерные можно видеть где производительность проседает.
(17) necropunk, (14) asved.ru, пройдено более 2-х недель кластер работает стабильно. Теперь необходимо для стабилизации работы наладить процесс разработок
(19) necropunk, да вопрос очень тяжелый. В компании много разработчиков и очень много проектов с широким спектром. Иногда бывает перезатираем доработки друг друга. Ознакамливаюсь с ITIL. Хороший сборник рекомендаций, но кажется труднореализуемо на данный момент. Поживем, увидим
(20) Bajo, ну, если народа реально много - то GIT-хранилище вполне подъемная тема. Участвовал в команде с нормально поставленной разработкой, с ночными сборками, релизами, тестированием и git-хранилищем, было круто. Не, можно, конечно, СППР попробовать, но мне кажется поддержку и актуализацию ее одной целый отдел должен работать...