Имя: Пароль:
1C
1С v8
Раз в несколько дней начинают виснуть новые сеансы. У кого-то такое было?
,
0 fisher
 
17.09.13
10:30
Релиз 8.2.15.310
Старенький, да. Планируем обновляться.
debian, postgres - вот это всё...
Подскажите, кстати, на какой релиз 8.2 лучше переходить в таких условиях? Или можно уже на 8.3 в режиме совместимости?
С какого-то момента без видимых причин появилась плавающая байда.
Новые сеансы начинают загружаться "бесконечно". Старые - работают без проблем. Ошибок никаких нигде не фиксируется. Рестарт сервака лечит и байда может неделю не повторяться. Появляется как под нагрузкой, так и в моменты её отсутствия. И появляется,  скотина такая, теперь достаточно регулярно.
Хоть у кого-то такое было? Если да, то расскажите свою историю :)
1 Maxus43
 
17.09.13
10:31
у нас ночью процессы перезапускаются.
1с пока не даёт долгой стабильности процессов, утечки памяти и т.д. Перезапускайте регулярно, процессы хотя бы, а не сам сервер 1с
2 fisher
 
17.09.13
10:37
(1) Вариант. У нас когда-то интервал перезапуска процессов в свойствах кластера был настроен, потом не помню уже в процессе чего - убрали. А каким образом у вас регламентируется именно НОЧНАЯ перезагрузка процессов? Скриптом?
3 Maxus43
 
17.09.13
10:39
(2) ага, скриптом
4 RomaH
 
naïve
17.09.13
10:44
на винде
15.301
запущено несколько рабочих процессов на сервере 1С

запускаю клиента - висит
если снять задачу и снова попытаться запустить - опять зависает
если не снимая запустить новый - загружает (может не с первого раза прокатить)

лечим перезапуском сервера 1С
так как есть путь обхода - то перезапуск по мере необходимости - пользователи уже в курсе, что над еще раз запустить если не запускается
5 fisher
 
17.09.13
10:49
(3) А чем штатный интервал перезапуска в свойствах кластера не устраивает? Он же вроде "интеллигентно" это делает при рабочих сеансах?
(4) Хм... У нас не совсем так. У нас стабильно ВСЕ новые процессы "висят".
И происходило это как при одном рабочем процессе, так и при двух.
6 Balabass
 
17.09.13
10:51
Такая же фигня. День - два - ребут сервера 1с.
7 fisher
 
17.09.13
10:53
(6) Винда/линух? Релиз? Интересно статистику собрать. Может, какие-нить закономерности проявятся...
8 Balabass
 
17.09.13
10:57
вин 2003 *32 8.2.17.143
9 Balabass
 
17.09.13
10:57
Закономерностей не нашел. По всякому делал.
Просто виснит и все и не отвечает.
10 Balabass
 
17.09.13
10:58
С кем не советовался, все ссылаются на х32 систему
11 wade25
 
17.09.13
11:00
Ключи программные? У нас пропала фигня, как перешли с флешек на программные. Платформа на данный момент:8.2.17.169
12 fisher
 
17.09.13
11:01
Кстати, да! Разок или два, но было что байда повторялась после рестарта сервака в течение того же дня! Но это исключение было. Обычно между рестартами несколько дней безпроблемной работы.
(8) Спс.
(9) Аналогично. И так и эдак пробовал и резервные рабочие процессы заводил - без толку.
(10) Хм... У нас x64. Но база под 70 гиг и тяжелые аналитические отчеты крутятся.
(11) Программные. Но звоночек интересный. Есть над чем подумать...
13 fisher
 
17.09.13
11:03
(12) + Баз, на самом деле, много. Это просто самая тяжелая. Но, как я уже говорил, проблема проявлялась и при отсутствии нагрузки.
14 fisher
 
17.09.13
11:07
Была еще мысля настроить ТЖ на полную детализацию (сейчас только на ошибки), но боюсь что за неделю засрет диск мама не горюй и на производительность повлияет...
15 МихаилМ
 
17.09.13
15:06
(0)
посмотрите трэйсером
или через технологический журнал,
что происходит на сервере в момент недоступности.
16 fisher
 
26.09.13
10:13
Ж... продолжается и постепенно усиливается. Бяка может повторяться в течение суток. Закономерностей по прежнему никаких.
Штатный интервал перезапуска рабочих процессов её не лечит.
Если случается эта бяка, с автозапуском нового процесса тоже случается бяка - он не может нормально запустится (в консоли сервера появляется как включенный, но не активный).
Будем детализировать ТЖ, пытаться выявить закономерности.
Апнул, чтобы собрать стороннюю статистику. Может, кто-то еще выскажется по теме.
17 fisher
 
26.09.13
15:14
Обеденный ап.
2 + 2 = 3.9999999999999999999999999999999...