Здравствуйте. Стоит конфигурация КА 1.1, все вроде бы ничего, но после последнего месяца, когда было сформировано в конце месяца 7к реализаций, начались проблемы с 1с сервером такого плана, может не с этим связано.
1. Время Проведения документов резко возросло и стали появлятся конфликты блокировок.
2. Если долго сидишь в программе и не активен, выходит сообщение Сеанс отсутствует или временно удален.
3. Изредка сам тухнет 1с сервер.
В чем может быть причина, в какую сторону смотреть? Базы на 1с севрер не добавлялись, железо не менялось, ОС Windows Server 2008 R2, единственное, обновления Windows Накатывались, но не думаю, что на них стоит грешить.

Что делал:
1. ТИС средствами 1с, кроме реиндексации и реструктуризации.
2. Регламентные обновление индекс, реиндексация, обновление статистики средствами SQL.
3. Резал лог.

(0) Ни за что , слышишь, ни за что не говори какой релиз платформы!

Статистику по загрузке аппаратных мощностей сервера приложений и сервера БД нужно смотреть. Такое ощущение, что диски не справляются.
Технологический журнал настройте.

А платформа какая?

информация с сайта 1С (https://users.v8.1c.ru/):
Сеанс отсутствует или удален
Код ошибки: 30006898
Статус: Исправлена в будущей версии Зарегистрирована: 20.03.2014
Исправлена:
"Технологическая платформа", версия 8.3.5
Описание:
Сеанс тонкого клиента при непосредственном соединении с сервером Предприятия может быть завершен аварийно после временной потери TCP-соединения между клиентом и сервером.

Посмотри размер tempdb и свободное место на сервере.

"Причиной возникновения ошибки «Сеанс отсутствует или удален» является разрыв TCP-соединения между тонким клиентом и рабочим процессом сервера, возможно, из-за временной неработоспособности какого-то сетевого оборудования между компьютером сервера 1С:Предприятия и проблемным клиентским компьютером."
Вирусняк еще может.

хмм формат скуль , если 7К в конец дня впихали - открой скуль и посмотри в таблице какое время пишет (в 1С 7-ке была ошибка что писалось время 25:01, хотя в 8-ке пофиксили но все же )
про чистить кэш тоже никто не вспомнил ?

(8) Да там явные проблемы с сетью.

(0) Первым делом, настраивай ТЖ, собирай логи и анализируй.
Смотри количество таймаутов, на упр. блокировках и на СУБД. Если Раньше было все норм, а потом стало хреново, а конфа особо не менялось, значит у тебя где-то table scan или index scan, сейчас данных стало больше, больше вероятности нарваться на блокировку или на таймаут.
Если ТЖ выявит наличие блокировок, ставь ЦУП и расследуй

Эпитафия: "единственное, обновления Windows Накатывались, но не думаю, что на них стоит грешить" Аминь.

(11) однажды, на одном всеми забытом сервере 1ц, обновляшки решили накатиться в 16 часов последнего отчетного дня. это были страх и ненависть во фгупе :DD

с памятью все нормально?

(12) плюсую. Неожиданное обновление Windows8 у сервера 1С - просто отрубило сеть, хорошо хоть точка отката была рабочей.

После очередного обновления винды - всё работает, никто ни на что не жалуется... кроме меня :( Обновления конфигурации, которые раньше занимали минут двадцать (и казались ужас как длинные), теперь растянулись на два часа мучений у монитора. Админа бью как шаман в бубен: звук - есть, толку - ноль.

(15) отвалилось кеширование диска c: скорее всего

вы с одмином совершенно бесполезны для конторы на этот случай

(15) винда обновилась где? У разработчика или на сервере 1С?

А может в (0) Сервер приложений и сервер БД на одной машине, а недавно на ней еще и DC подняли. :)

(18) любимая забава...

(16) "А мне то за что?"(цы) Я там рядовой пользователь, даже не вижу ни серверов, ни других компов сети. Политика безопасности. "I don't want to talk about it"(с)

(офф) Весело живёшь - то красный, то жёлтый гы-гы-гы :)

+

вполне еще может на server 2008 подхавнить старый драйвер ключа алладина

он кривой как сабля турецкая и не дает выгружаться чужим процессам до конца. в итоге вся оперативка засерается "зомби" на page table + родовая травма server 2008 - высокий расход ресурсов на быстрый доступ к файлам в виде величины в графе metafile в утиле rammap

(18) ничего не поднимали.
Комплексная автоматизация, редакция 1.1 (1.1.44.2)
Платформа 1С:Предприятие 8.2 (8.2.19.68)

Все работает на ура, уже 2 года, после марта начались проблемы.
1с сервер стоит вместе на одной машине SQL сервера, бюджет все же не безлимитный.

Вариант с вирусом, надо посмотреть.

>после марта начались проблемы.

журнал винды и скуля открывали хоть раз?

недавно одна контора тоже жаловалось - все тормозит и перегружается...


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

Вариант может быть ещё и с подыхающим роутером, но ещё рабочим. Было однажды: один неиспользуемый порт сгорел - никто не заметил, кроме 1С.

(23) журнал винды, сбоев в 1с сервере и SQL нету, но меня смущает две службы, котоыре часто тухнут и поднимаются сами, Служба "Служба автоматического обнаружения веб-прокси WinHTTP" перешла в состояние Остановлена.
Служба "Служба Google Update (gupdate)" перешла в состояние Остановлена.

Журнал скуля, там что я должен увидеть?

(24) как с роутером проверить, так как на сеть я тоже думаю грешить.

(22) 8.2.19.130 хотя бы поставили, последнюю в этой редакции.
Со времени 8.2.19.68 там дестяок обновлений вышел и 2 года прошло...

(27) но почему-то проблем 2 года не было, зачем ставить, что-то новое неизвестное, когда есть рабочая уже схема.

Посмотри размер журнала регистрации 1с, ежели он плотный, проблема может быть в нем. На всех боевых базах как вариант вести журнал регистрации в старом формате 1Cv8.lgf с разбивкой по дням и в настройках поставить регистрировать только Ошибки.

(29) в SQL варианте, это как?

как вариант можно ещё шринкнуть лог в SQL и поставить простую модель для БД

В настройках SQL у БД поставить увеличение объема базы и лога на 10% при необходимости, а то там может стоять 1 Mb и из-за этого бывают проблемы.

>как вариант можно ещё шринкнуть лог в SQL и поставить простую модель для БД

чего ради собственно?

Всё это гадание на кофейной гуще. Без сбора статистики это гадание может продолжаться очень долго. Пока база не умрет. :)

(33) При recovery model = full разрастается лог до плотных размеров + заметно медленее работает БД из за логирования каждой транзакции, вся эта петрушка нужна только для инкреметных бэкапов. Ежели они не нужны то лучше поставить Recovery model = simple и порезать лог и будет все крутится быстрее

(35) Ересь. :) Ничего что даже в режиме simple в лог пишется не завершенная транзакция.

http://www.gilev.ru/1c/support/research.htm

>заметно медленее работает БД из за логирования каждой транзакции

журнал все равно используется в симл для отката.

а "быстрее" делают для единичных операций с большими загрузками данных типа через "bulk copy"

для 1с-ной объектной модели и манеры работы с БД - не будет никакой разницы

(38) серьезно? в  Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. В связи с этим тратишь время на запись журнала, БД работает медленее

(38) В simple пишется гораздо меньше

(28) Значит, база достигла такого состояния, при котором проблемы стали возникать.
"Что-то новое неизвестное" уже два года как прекратило обновляться.

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

(38) Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций.

(39) >серьезно?

учите матчасть уже...

>В связи с этим тратишь время на запись журнала,

для танкистов еще раз - журнал используется и в симпл.

то что он скидывает сразу завершенные транзакции по чекпоинту - и очищается (на это кстати тоже ресурсы нужны) - это не значит что он для красоты лежит

(43) можешь автору этой чуши в харю плюнуть.

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

(45) У тебя с головой все нормально? Тебе по русски сказали что simple работает быстрее, full нужен только для инкрементных бэкапов. Ты с этим поспорить хочешь?

(46) тебе еще раз сказано - не повторяй глупости за идиотами...

Было похожее, всё как написал (41)   у компании спрос сезонный  и вход в сезон совпал  с критической точкой размера  ряда таблиц.   пока не  решили вопрос с железом  параллельно оптимизируя код  разнесли работу ряда подразделений по времени после анализа блокировок. По блокировкам выяснили кто и кому мешает.

Господа вы немного ушли от темы, тезисно, что нужно еще сделать ?

100% кеш сервера разросся. Ситуация была один в один, после очистки кеша сервера, сервер ожил.  http://alimuradov.ru/2016/05/17/очистка-кеша-сервера-1с/

(46) Ну тебе по русски отвечают что симпл и фулл работают одинаково быстро.

Разница возникает  только на некоторых операциях, и то лечиться.

(50)  по  этой  ссылке  не кэш  очищают  ,  а  журналы  регистрации   в  базах  удаляют .

(50) там всего 16 ГБ, не думаю, что в них проблема)

1с плодит много временных файлов. сервер 2008 тратит много ресурсов на организацию "быстрого доступа" к ним. в итоге драгоценная оперативка тратится на metafile (rammap) https://social.technet.microsoft.com/Forums/windows/en-US/80c045fc-32ff-4b7f-90ce-545e8bd95138/server-2008-r2-metafile-as-seen-from-sysinternals-rammap-increases-memory-usage-rapidly?forum=winservergen

(50) как раз папку scntx и нужно удалять

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

(55) уверен, что папку scntx нужно удалять?

Каталоги с snccntx очистить можно. Но то, что кэши раздуваются - это последствия, а не первопричина. Если через относительно короткое время они опять распухнут - первопричину вы не нашли и не устранили.

Совсем недавно была ветка, в томчисле на эту тему. повторю ссылки:
Анализ причин роста сеансовых данных
https://its.1c.ru/db/metod8dev#content:5860:hdoc
Скрипт перезапуска агента сервера и очистка каталогов (автор: Павел Чистов)
http://expert.chistov.pro/public/196770/

(58) кэш небольшой, за 2 года его не чистки, 66 мб