Имя: Пароль:
1C
1С v8
Разомнем мозги) Рабочие процессы 8.1
0 lxs
 
18.03.12
12:09
1. Свой вариант 50% (3)
2. Проблема в организации обменов 33% (2)
3. Проблема в установленной версии платформы 17% (1)
4. Проблема в ресурсах сервера 0% (0)
Всего мнений: 6

Приветствую, господа!

Проблема не моя, но есть желание разобраться и порешать)
Имеем:
-физический сервер XEON 8 камней, 12 ГБ  RAM;
-сервер предприятия 8.1, 8 рабочих процессов;
-постоянные обмены.

-при начале любого обмена процесс, на котором живет этот обмен, начинает потреблять до 100%(!) ресурсов процессора(!!!), практически не потребляя ресурсы оперативной памяти (150-300МБ). Как результат, нестабильная работа всего кластера. Подключения к базам в этом кластере рвутся с периодичностью от 10 до 20 минут в зависимости от нагрузки. Жить параллельно с дикой загрузкой могут два, максимум - 3 процесса. При этом любые дополнительные попытки запуска иных обменов заканчиваются одинаково: server refused actively connection.

Перезапуск службы, естественно, решает проблему, но до того момента, как обмены снова начнут гасить ресурсы.

Требуется:
-выявить аномалию;
-устранить проблему.

Что пробовал (пока не так много, поскольку только взялся за это дело):
-играл производительностью процессов;
-менял приоритеты виндовых процессов;
-в некоторых случаях менял объем данных при обменах, там, где это реально.

Не спасло.
Я не претендую на звание гуру клиент-серверных технологий и обменов и буду признателен за любые советы и идеи.

Воткну опрос на всякий случай.
1 Кокос
 
18.03.12
12:13
сколько баз на скуль? плюс был вроде баг по съеданию памяти и в новом релизе говорят его убрали. только я его пока боюсь ставить.. посмотр. что народ скажет.
2 serg_sh75
 
18.03.12
12:14
Вся проблема только в организации обмена. Разбирай этот вариант детально-пошагово. 100% загрузка проца - это 100% кривой алгоритм

Проблема в организации обменов
3 serg_sh75
 
18.03.12
12:15
(0) подключать отладку фоновых заданий и вперед
4 Кокос
 
18.03.12
12:17
(2) у меня двухзеононовый сервак. перевел одну базу на скуль. потом вторую для отладки тоже поставил на скуль и стало тормозить. админ сказал что чем больше скуля чем больше будет тормозов. отладочную перевел на файловую версию и теперь все ок.
5 lxs
 
18.03.12
12:17
(1) Скуль на отдельном сервере. Баз всего до 10ти. Проблема из-за обмена с одной-единственной. В нее льются данные со всей России.
6 lxs
 
18.03.12
12:18
(4) Переходить на файл не вариант.
7 serg_sh75
 
18.03.12
12:19
(5) Обмен штатными средствами через планы обмена? Если да, то что происходит если запустить обмен ручками интерактивно в пользовательском режиме?
8 serg_sh75
 
18.03.12
12:21
(7) это же действие, но непосредственно на серваке где крутится app1с и под той же системной учеткой под которой крутится app1с
9 lxs
 
18.03.12
12:23
(7) да, штатными. ничего не меняется при ручном, по-моему. сейчас сказать сложно, могу точно завтра ответить.
10 serg_sh75
 
18.03.12
12:26
ну и шаманской действие впридачу: при фоновых обменах 1С распаковывает хмl файлы тепм папку пользователя из под которого запущена 1С. со временем их там скопиться может тысячи штук на десятки гигов - попробуй почистить папку.
11 serg_sh75
 
18.03.12
12:29
(4) Да есть такое. Отладка фоновых заданий ставит раком весь сервак 1С(на 81 точно, про 82 не скажу) - поэтому только во внерабочее время.
12 lxs
 
18.03.12
12:29
(10) почему ты так уверен, что причиной загрузки процессора является кривой алгоритм запроса при обмене? Память может сжираться с таким же успехом, но она на идеальном уровне)
13 lxs
 
18.03.12
12:30
+(12) я просто рассуждаю.
14 lxs
 
18.03.12
12:32
(11) Отладка в принципе ставит раком весь сервак 1С (и 8.2 в том числе)
15 lxs
 
18.03.12
12:33
(10) Папка временных файлов девственно чиста. На винте свободного места предостаточно.
16 serg_sh75
 
18.03.12
12:33
(12) не уверен, а предполагаю одну из причин.
(9) 100% загрузка проца наталкивает на мысль, что проблема может быть в БД. Как в приемнике, так и в источнике. Например так называемая петля в справочнике - зацикливание уровней. Поэтому для начала нужно пройтись отладчиком - увидишь в какой момент приходит Ж.
17 serg_sh75
 
18.03.12
12:34
(0) а какой скуль стоит?
18 PVV65
 
18.03.12
12:38
(0) Кривые программы обмена.

Проблема в организации обменов
20 PVV65
 
18.03.12
12:47
(19) Проблемы на 99% не в железе, а в мозгах. Какое железо не поставь - один хрен растущий.
21 serg_sh75
 
18.03.12
12:57
При ошибках в БД глюки у 1С могут просто беспобны:) Пример из жизни: Буха 1.6, 8.1/SQL2000, очень увесистая, ежемесячное закрытие затратных счетов можно было делать только после ТиИ - иначе процесс маслает много-много часов и падает в конце концов, у пользователей естественно блокировки. После ТиИ - около 20-30 минут и все закрывалось.
Эта же база: при формировании ОСВ по 62 счету с отбором по одному и тому же контрагенту отчет мог быть сформирован за 2 минуты, а мог и за 2 часа, или вообще не сформирован.
Лечилось опять таки ТиИ, да и то на некоторое время.
22 Злопчинский
 
18.03.12
13:12
жрите кактус, жрите!

Свой вариант
23 lxs
 
18.03.12
13:12
(17) 2005
24 Jofa
 
18.03.12
13:16
(21) Читайте ещё раз (20) и не несите чушь тк всё работатет нормально если настроить регламентированные задания на SQL.
у меня база 80 гиг все закрывается в лёт.
25 МихаилМ
 
18.03.12
13:24
1) на ресурсы не правильно наложены блокировки
(может у используется postgreesql)

2) сервер 1с не умет гамотно обработать такие ситуации.

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

либо
исправить блокировки по умолчанию (сменить субд); обновить ПО 1с


если ничего не поможет: настроить чтобы задания обмена выполнялись
на конкретном рабочем процессе для обменом.

, а "живые" пользователи    
на оставшихся.  

этому процессу присвоить конкретное ядро или процессор (не не встречал комп с 8 процессорами. максимум - с 4  )    

либо процессу выставить наименьший приоритет.

Свой вариант
26 PVV65
 
18.03.12
13:28
(25) Позовите грамотного админа. И отойдите в сторону.
27 Jolly Roger
 
18.03.12
14:13
(25) и что, блокировки на скуле приводят к загрузке проца сервера приложений?..
28 Jolly Roger
 
18.03.12
14:14
(0) анализ алгоритмов обмена не предлагать?..
29 Serg_1960
 
18.03.12
14:16
При обновлении конфигурации рекомендуют останавливать выполнение регламентных заданий... Почему и тебе тоже самое не сделать при обмене? Имхо.
30 Jolly Roger
 
18.03.12
14:19
(29) в смысле при обмене останавливать регламентные задания обмена?
31 Jolly Roger
 
18.03.12
14:20
+(30) или при обмене останавливать обновление конфигурации?..
32 Serg_1960
 
18.03.12
14:43
Перед обменом останавливать выполнение регламентных заданий, а потом вновь их запускать.

PS: странно что ты меня не понял - кажется я ясно выразился
33 lxs
 
18.03.12
14:49
(28) Предлагай, я же затем и создал тему, чтобы услышать мнения спецов.

Насчет остановки заданий при обновлении - та ки делается. Никакой динамики.
34 lxs
 
18.03.12
14:51
Блокировки? А причем здесь процессор? Характер сбоев при блокировке совершенно иной. Первая же блокировка отвалит просто обмен.
35 lxs
 
18.03.12
14:52
Хотя, я думаю, этот фактор тоже немаловажен, поэтому принимается.
36 aspirator23
 
18.03.12
14:56
Откажись от 8.1
8.2 гораздо стабильнее. Даже 13 релиз. Особенно при фоновых задачах.
Для 8.2 не нужно столько процессов. 1-2 рабочих и один резервный.
Подключения перестанут обрываться.
Попутно увидишь как резко уменьшится потребление памяти.
Попробуй поставить два или более агентов и разнеси процессы.

Проблема в установленной версии платформы
37 Jolly Roger
 
18.03.12
15:03
(32) а что это может дать?
38 Jolly Roger
 
18.03.12
15:06
(33) считай что уже предложил. я бы, кстати, с этого начал...
39 lxs
 
18.03.12
15:07
(36) Спасибо, кэп
40 lxs
 
18.03.12
15:10
(36) С потреблением памяти у меня все в порядке, прочти внимательно описание проблемы. Гибнет проц.
41 lxs
 
18.03.12
15:18
(25)
-Неверно выразился насчет проца - 8 ядер, камней 4. Тут ты прав.
-Используется скуль 2005 (скорее всего без CU)
-если у тебя 3000 филиалов по всей России, включая Владивосток, как ты собираешься их по одному запускать? Мне недели не хватит, чтобы произвести обмен со всеми магазинами в таком случае.
- Исправить блокировки по умолчанию - не понял
- обновить ПО - пук в лужу. Новое - не значит, хорошее. Да и что обновлять? Скуль? Платформу? ОС? Мозги?

Сервер предприятия и без меня умеет распределять нагрузку в кластере по процессам.
Как я уже писал, одновременно, в моем случае, могут жить 2-3 потока обмена, и они живут на разных процессах, значит, сервер предприятия со своей работой по распределению нагрузки на ядра справляется. Загрузка проца - это уже другое. Вешать поток на выделенный процесс бессмысленно. Он и так для него выделен.

Все, сказанное тобой - общие слова, но все равно спасибо.
42 aspirator23
 
18.03.12
15:19
(40) если он потребляет 100% ядра, решение - дробить задачу.
43 acsent
 
18.03.12
15:21
в 8.2 (уф) без отладки на сервере вообще нечего делать. ибо там 99% кода именно на сервере
44 lxs
 
18.03.12
16:08
(43) это ты к чему?
45 lxs
 
19.03.12
09:34
Если принять версию про блокировки. Что посоветуете? Магазинов много, блокировки неизбежны. Сейчас они в автоматическом режиме.

Если бить на транзакции по несколько сотен элементов, нагрузка на сервер может упасть. Уменьшит ли это количество блокировок? До окончания транзакции запись будет заблокирована, но с учетом уменьшенного количества элементов в одной транзакции, таблицы чаще должны освобождаться. Я прав?
46 Maxus43
 
19.03.12
09:45
всё не читал но! Обмены 1с работают немного странно, при чтении зарегистрированых изменений для выгрузки - записи блокируются даже на чтение. От этого пока не ушли и в 8.2, как варианты ускорения - уменьшение интервалов обменов, будут более маленькие порции данных, но опять же и чаще. Или делать их в наиболее свободное время для системы. Раннее утро, обед, ночь

Свой вариант
47 Bober
 
19.03.12
09:47
(0)
обмены РИБ?
Конфигурация типовая, самописка?
готов к переработке обменов?
48 Bober
 
19.03.12
09:48
(0) зависает при выгрузке?
49 lxs
 
19.03.12
10:19
(47) РИБ, переписанная Розница. К этому и стремлюсь)
50 lxs
 
19.03.12
10:23
(48) не висит, обмен идет, но грузит проц на 100%, не отжирает память. Проблемы происходит при загрузке в Центр.
51 Vovan1975
 
19.03.12
10:26
имхо, очередная вариация алгоритма маляра Шлемиля...
52 Vovan1975
 
19.03.12
10:36
(50) как ты определяешь то обмен идет?
53 lxs
 
19.03.12
10:39
(52) "Элементарно!"©Холмс
54 Vovan1975
 
19.03.12
10:40
(53) элементарно? это как?
55 Maxus43
 
19.03.12
10:41
(54) процессор по 100, значит что-то делает :)
56 Vovan1975
 
19.03.12
10:42
(55) бгыыыыыы
57 lxs
 
19.03.12
10:43
(54) Что за глупые вопросы?

- открываешь ЖР, смотришь операции;
- открываешь список документов, которые должны импортироваться при обмене, смотришь его изменение;
- смотришь трафик на сервере;

дальше продолжать?
58 Maxus43
 
19.03.12
10:45
(57) РС ИсторияОбменаДанными не легче шлянуть?
з.ы. Конфа то какая?
59 lxs
 
19.03.12
10:49
(58) >> (49)

Какое отношение имеет способ определения активности обмена к озвученной проблеме. Не засирайте тему бессмысленными постами?
60 Maxus43
 
19.03.12
10:50
(59) Замер производительности то включал при обмене? это помойму первое что надо сделать. Очертится круг подозреваемых
61 Vovan1975
 
19.03.12
10:51
участвуют ли в обмене измененные типовые или совсем нетиповые документы?
62 lxs
 
19.03.12
10:53
Пока еще не успел, поскольку только вчера начал копаться.
(61) да.
63 Vovan1975
 
19.03.12
10:56
(59) ну например такая загрузка может возникать вследствие конфликтов разных регламентных заданий... Соответственно интересно - пишутся ли объекты в базу при зависании...

посмотри на итс обработку консоль заданий на предмет что у тебя в фоне выполняется во время обмена
(62) проверь в нетиповых доментах(которые в обмене участвуют) в модуле объекта наличие конструкциии "Если ОбменДанными.Загрузка=истина тогда возврат" тоже касается модулей записей регистров где есть какой-либо код. В типовых это обычно есть...

выполни проверку конфигурации в режиме "сервер" навсякий случай....
64 Bober
 
19.03.12
11:16
(50) если грузит при загрузке, то посмотри:
1 выполни загрузку на клиенте под отдадчиком, посмотри что больше всего вызывается
2 смотреть нет-ли выполнения кода перед/ при записи удалением без проверки обменданными.загрузка
3 если проблема при записи в рн, то отключить актуальные итоги в центральном узле
65 serg_sh75
 
19.03.12
11:20
(0) Будь мужиком, запусти наконец отладчик!
66 lxs
 
19.03.12
12:18
(65) )))