|
1С сервер уходит по бороде | ☑ | ||
---|---|---|---|---|
0
Coldboy
26.04.17
✎
15:04
|
Здравствуйте. Стоит конфигурация КА 1.1, все вроде бы ничего, но после последнего месяца, когда было сформировано в конце месяца 7к реализаций, начались проблемы с 1с сервером такого плана, может не с этим связано.
1. Время Проведения документов резко возросло и стали появлятся конфликты блокировок. 2. Если долго сидишь в программе и не активен, выходит сообщение Сеанс отсутствует или временно удален. 3. Изредка сам тухнет 1с сервер. В чем может быть причина, в какую сторону смотреть? Базы на 1с севрер не добавлялись, железо не менялось, ОС Windows Server 2008 R2, единственное, обновления Windows Накатывались, но не думаю, что на них стоит грешить. |
|||
1
Coldboy
26.04.17
✎
15:05
|
Что делал:
1. ТИС средствами 1с, кроме реиндексации и реструктуризации. 2. Регламентные обновление индекс, реиндексация, обновление статистики средствами SQL. 3. Резал лог. |
|||
2
Amra
26.04.17
✎
15:08
|
(0) Ни за что , слышишь, ни за что не говори какой релиз платформы!
|
|||
3
Heckfy
26.04.17
✎
15:09
|
Статистику по загрузке аппаратных мощностей сервера приложений и сервера БД нужно смотреть. Такое ощущение, что диски не справляются.
Технологический журнал настройте. |
|||
4
Одинесю
26.04.17
✎
15:09
|
А платформа какая?
|
|||
5
Одинесю
26.04.17
✎
15:10
|
информация с сайта 1С (https://users.v8.1c.ru/):
Сеанс отсутствует или удален Код ошибки: 30006898 Статус: Исправлена в будущей версии Зарегистрирована: 20.03.2014 Исправлена: "Технологическая платформа", версия 8.3.5 Описание: Сеанс тонкого клиента при непосредственном соединении с сервером Предприятия может быть завершен аварийно после временной потери TCP-соединения между клиентом и сервером. |
|||
6
dmrjan
26.04.17
✎
15:11
|
Посмотри размер tempdb и свободное место на сервере.
|
|||
7
Одинесю
26.04.17
✎
15:12
|
"Причиной возникновения ошибки «Сеанс отсутствует или удален» является разрыв TCP-соединения между тонким клиентом и рабочим процессом сервера, возможно, из-за временной неработоспособности какого-то сетевого оборудования между компьютером сервера 1С:Предприятия и проблемным клиентским компьютером."
Вирусняк еще может. |
|||
8
пипец
26.04.17
✎
15:30
|
хмм формат скуль , если 7К в конец дня впихали - открой скуль и посмотри в таблице какое время пишет (в 1С 7-ке была ошибка что писалось время 25:01, хотя в 8-ке пофиксили но все же )
про чистить кэш тоже никто не вспомнил ? |
|||
9
Одинесю
26.04.17
✎
15:47
|
(8) Да там явные проблемы с сетью.
|
|||
10
ВаськаМаська
26.04.17
✎
16:07
|
(0) Первым делом, настраивай ТЖ, собирай логи и анализируй.
Смотри количество таймаутов, на упр. блокировках и на СУБД. Если Раньше было все норм, а потом стало хреново, а конфа особо не менялось, значит у тебя где-то table scan или index scan, сейчас данных стало больше, больше вероятности нарваться на блокировку или на таймаут. Если ТЖ выявит наличие блокировок, ставь ЦУП и расследуй |
|||
11
Serg_1960
26.04.17
✎
16:12
|
Эпитафия: "единственное, обновления Windows Накатывались, но не думаю, что на них стоит грешить" Аминь.
|
|||
12
lodger
26.04.17
✎
16:15
|
(11) однажды, на одном всеми забытом сервере 1ц, обновляшки решили накатиться в 16 часов последнего отчетного дня. это были страх и ненависть во фгупе :DD
|
|||
13
Господин ПЖ
26.04.17
✎
16:16
|
с памятью все нормально?
|
|||
14
ildary
26.04.17
✎
16:23
|
(12) плюсую. Неожиданное обновление Windows8 у сервера 1С - просто отрубило сеть, хорошо хоть точка отката была рабочей.
|
|||
15
Serg_1960
26.04.17
✎
16:33
|
После очередного обновления винды - всё работает, никто ни на что не жалуется... кроме меня :( Обновления конфигурации, которые раньше занимали минут двадцать (и казались ужас как длинные), теперь растянулись на два часа мучений у монитора. Админа бью как шаман в бубен: звук - есть, толку - ноль.
|
|||
16
Господин ПЖ
26.04.17
✎
16:35
|
(15) отвалилось кеширование диска c: скорее всего
вы с одмином совершенно бесполезны для конторы на этот случай |
|||
17
ildary
26.04.17
✎
16:36
|
(15) винда обновилась где? У разработчика или на сервере 1С?
|
|||
18
Heckfy
26.04.17
✎
16:37
|
А может в (0) Сервер приложений и сервер БД на одной машине, а недавно на ней еще и DC подняли. :)
|
|||
19
Господин ПЖ
26.04.17
✎
16:39
|
(18) любимая забава...
|
|||
20
Serg_1960
26.04.17
✎
16:42
|
(16) "А мне то за что?"(цы) Я там рядовой пользователь, даже не вижу ни серверов, ни других компов сети. Политика безопасности. "I don't want to talk about it"(с)
(офф) Весело живёшь - то красный, то жёлтый гы-гы-гы :) |
|||
21
Господин ПЖ
26.04.17
✎
16:42
|
+
вполне еще может на server 2008 подхавнить старый драйвер ключа алладина он кривой как сабля турецкая и не дает выгружаться чужим процессам до конца. в итоге вся оперативка засерается "зомби" на page table + родовая травма server 2008 - высокий расход ресурсов на быстрый доступ к файлам в виде величины в графе metafile в утиле rammap |
|||
22
Coldboy
26.04.17
✎
16:47
|
(18) ничего не поднимали.
Комплексная автоматизация, редакция 1.1 (1.1.44.2) Платформа 1С:Предприятие 8.2 (8.2.19.68) Все работает на ура, уже 2 года, после марта начались проблемы. 1с сервер стоит вместе на одной машине SQL сервера, бюджет все же не безлимитный. Вариант с вирусом, надо посмотреть. |
|||
23
Господин ПЖ
26.04.17
✎
16:51
|
>после марта начались проблемы.
журнал винды и скуля открывали хоть раз? недавно одна контора тоже жаловалось - все тормозит и перегружается... оказалось что у нее все торчит наружу, даже скуль и ее долбосят без конца со всех краев земли... журнал скуля полный брутальными попытками подобрать пароль к sa по словарю и т.п. милыми шалостями |
|||
24
Serg_1960
26.04.17
✎
16:52
|
Вариант может быть ещё и с подыхающим роутером, но ещё рабочим. Было однажды: один неиспользуемый порт сгорел - никто не заметил, кроме 1С.
|
|||
25
Coldboy
26.04.17
✎
16:54
|
(23) журнал винды, сбоев в 1с сервере и SQL нету, но меня смущает две службы, котоыре часто тухнут и поднимаются сами, Служба "Служба автоматического обнаружения веб-прокси WinHTTP" перешла в состояние Остановлена.
Служба "Служба Google Update (gupdate)" перешла в состояние Остановлена. Журнал скуля, там что я должен увидеть? |
|||
26
Coldboy
26.04.17
✎
16:55
|
(24) как с роутером проверить, так как на сеть я тоже думаю грешить.
|
|||
27
ansh15
26.04.17
✎
16:57
|
(22) 8.2.19.130 хотя бы поставили, последнюю в этой редакции.
Со времени 8.2.19.68 там дестяок обновлений вышел и 2 года прошло... |
|||
28
Coldboy
26.04.17
✎
16:58
|
(27) но почему-то проблем 2 года не было, зачем ставить, что-то новое неизвестное, когда есть рабочая уже схема.
|
|||
29
profitmaker
26.04.17
✎
16:58
|
Посмотри размер журнала регистрации 1с, ежели он плотный, проблема может быть в нем. На всех боевых базах как вариант вести журнал регистрации в старом формате 1Cv8.lgf с разбивкой по дням и в настройках поставить регистрировать только Ошибки.
|
|||
30
Coldboy
26.04.17
✎
16:58
|
(29) в SQL варианте, это как?
|
|||
31
profitmaker
26.04.17
✎
16:59
|
как вариант можно ещё шринкнуть лог в SQL и поставить простую модель для БД
|
|||
32
profitmaker
26.04.17
✎
17:00
|
В настройках SQL у БД поставить увеличение объема базы и лога на 10% при необходимости, а то там может стоять 1 Mb и из-за этого бывают проблемы.
|
|||
33
Господин ПЖ
26.04.17
✎
17:01
|
>как вариант можно ещё шринкнуть лог в SQL и поставить простую модель для БД
чего ради собственно? |
|||
34
Heckfy
26.04.17
✎
17:03
|
Всё это гадание на кофейной гуще. Без сбора статистики это гадание может продолжаться очень долго. Пока база не умрет. :)
|
|||
35
profitmaker
26.04.17
✎
17:04
|
(33) При recovery model = full разрастается лог до плотных размеров + заметно медленее работает БД из за логирования каждой транзакции, вся эта петрушка нужна только для инкреметных бэкапов. Ежели они не нужны то лучше поставить Recovery model = simple и порезать лог и будет все крутится быстрее
|
|||
36
Heckfy
26.04.17
✎
17:05
|
(35) Ересь. :) Ничего что даже в режиме simple в лог пишется не завершенная транзакция.
|
|||
37
Господин ПЖ
26.04.17
✎
17:06
|
||||
38
Господин ПЖ
26.04.17
✎
17:11
|
>заметно медленее работает БД из за логирования каждой транзакции
журнал все равно используется в симл для отката. а "быстрее" делают для единичных операций с большими загрузками данных типа через "bulk copy" для 1с-ной объектной модели и манеры работы с БД - не будет никакой разницы |
|||
39
profitmaker
26.04.17
✎
17:15
|
(38) серьезно? в Full (режим полного протоколирования) — в этом режиме максимальное количество операций записывается в журнал транзакций. В связи с этим тратишь время на запись журнала, БД работает медленее
|
|||
40
profitmaker
26.04.17
✎
17:15
|
(38) В simple пишется гораздо меньше
|
|||
41
ansh15
26.04.17
✎
17:16
|
(28) Значит, база достигла такого состояния, при котором проблемы стали возникать.
"Что-то новое неизвестное" уже два года как прекратило обновляться. |
|||
42
profitmaker
26.04.17
✎
17:16
|
Full нужен только для инкрементных бэкапов, когда надо откатиться на конкретное время до секунды.
|
|||
43
profitmaker
26.04.17
✎
17:19
|
(38) Simple (простая модель восстановления) — максимальный выигрыш в производительности и удобстве работы за счет возможностей восстановления. Минимально протоколируются те же операции, что и в режиме восстановления Bulk-logged, а кроме этого, журнал транзакций автоматически очищается (блоками, размер которых изначально равен 256 Кбайт, но при необходимости он может быть автоматически увеличен). В результате вы получаете максимальную производительность и возможность не думать о потенциальной нехватке места в журнале транзакций.
|
|||
44
Господин ПЖ
26.04.17
✎
17:22
|
(39) >серьезно?
учите матчасть уже... >В связи с этим тратишь время на запись журнала, для танкистов еще раз - журнал используется и в симпл. то что он скидывает сразу завершенные транзакции по чекпоинту - и очищается (на это кстати тоже ресурсы нужны) - это не значит что он для красоты лежит |
|||
45
Господин ПЖ
26.04.17
✎
17:23
|
(43) можешь автору этой чуши в харю плюнуть.
выигрыш там будет только на операциях массовой вставки и работе с большими бинарниками |
|||
46
profitmaker
26.04.17
✎
17:28
|
(45) У тебя с головой все нормально? Тебе по русски сказали что simple работает быстрее, full нужен только для инкрементных бэкапов. Ты с этим поспорить хочешь?
|
|||
47
Господин ПЖ
26.04.17
✎
17:29
|
(46) тебе еще раз сказано - не повторяй глупости за идиотами...
|
|||
48
BigShmax
26.04.17
✎
17:54
|
Было похожее, всё как написал (41) у компании спрос сезонный и вход в сезон совпал с критической точкой размера ряда таблиц. пока не решили вопрос с железом параллельно оптимизируя код разнесли работу ряда подразделений по времени после анализа блокировок. По блокировкам выяснили кто и кому мешает.
|
|||
49
Coldboy
26.04.17
✎
18:36
|
Господа вы немного ушли от темы, тезисно, что нужно еще сделать ?
|
|||
50
tabarigen
26.04.17
✎
23:18
|
100% кеш сервера разросся. Ситуация была один в один, после очистки кеша сервера, сервер ожил. http://alimuradov.ru/2016/05/17/очистка-кеша-сервера-1с/
|
|||
51
Jump
27.04.17
✎
05:55
|
(46) Ну тебе по русски отвечают что симпл и фулл работают одинаково быстро.
Разница возникает только на некоторых операциях, и то лечиться. |
|||
52
1Сукпун
27.04.17
✎
06:14
|
(50) по этой ссылке не кэш очищают , а журналы регистрации в базах удаляют .
|
|||
53
Coldboy
27.04.17
✎
08:21
|
(50) там всего 16 ГБ, не думаю, что в них проблема)
|
|||
54
Господин ПЖ
27.04.17
✎
10:23
|
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
|
|||
55
Вафель
27.04.17
✎
10:31
|
(50) как раз папку scntx и нужно удалять
|
|||
56
Вафель
27.04.17
✎
10:32
|
(46) в симпле после каждого чекпойнта идет запсь поверх старых , а в фуле нет вот вся разница
|
|||
57
Coldboy
02.05.17
✎
09:29
|
(55) уверен, что папку scntx нужно удалять?
|
|||
58
Serg_1960
02.05.17
✎
11:13
|
Каталоги с snccntx очистить можно. Но то, что кэши раздуваются - это последствия, а не первопричина. Если через относительно короткое время они опять распухнут - первопричину вы не нашли и не устранили.
Совсем недавно была ветка, в томчисле на эту тему. повторю ссылки: Анализ причин роста сеансовых данных https://its.1c.ru/db/metod8dev#content:5860:hdoc Скрипт перезапуска агента сервера и очистка каталогов (автор: Павел Чистов) http://expert.chistov.pro/public/196770/ |
|||
59
Coldboy
02.05.17
✎
11:38
|
(58) кэш небольшой, за 2 года его не чистки, 66 мб
|
Форум | Правила | Описание | Объявления | Секции | Поиск | Книга знаний | Вики-миста |