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

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

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

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

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

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

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

Воткну опрос на всякий случай.

сколько баз на скуль? плюс был вроде баг по съеданию памяти и в новом релизе говорят его убрали. только я его пока боюсь ставить.. посмотр. что народ скажет.

Вся проблема только в организации обмена. Разбирай этот вариант детально-пошагово. 100% загрузка проца - это 100% кривой алгоритм

(0) подключать отладку фоновых заданий и вперед

(2) у меня двухзеононовый сервак. перевел одну базу на скуль. потом вторую для отладки тоже поставил на скуль и стало тормозить. админ сказал что чем больше скуля чем больше будет тормозов. отладочную перевел на файловую версию и теперь все ок.

(1) Скуль на отдельном сервере. Баз всего до 10ти. Проблема из-за обмена с одной-единственной. В нее льются данные со всей России.

(4) Переходить на файл не вариант.

(5) Обмен штатными средствами через планы обмена? Если да, то что происходит если запустить обмен ручками интерактивно в пользовательском режиме?

(7) это же действие, но непосредственно на серваке где крутится app1с и под той же системной учеткой под которой крутится app1с

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

ну и шаманской действие впридачу: при фоновых обменах 1С распаковывает хмl файлы тепм папку пользователя из под которого запущена 1С. со временем их там скопиться может тысячи штук на десятки гигов - попробуй почистить папку.

(4) Да есть такое. Отладка фоновых заданий ставит раком весь сервак 1С(на 81 точно, про 82 не скажу) - поэтому только во внерабочее время.

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

+(12) я просто рассуждаю.

(11) Отладка в принципе ставит раком весь сервак 1С (и 8.2 в том числе)

(10) Папка временных файлов девственно чиста. На винте свободного места предостаточно.

(12) не уверен, а предполагаю одну из причин.
(9) 100% загрузка проца наталкивает на мысль, что проблема может быть в БД. Как в приемнике, так и в источнике. Например так называемая петля в справочнике - зацикливание уровней. Поэтому для начала нужно пройтись отладчиком - увидишь в какой момент приходит Ж.

(0) а какой скуль стоит?

(0) Кривые программы обмена.

(19) Проблемы на 99% не в железе, а в мозгах. Какое железо не поставь - один хрен растущий.

При ошибках в БД глюки у 1С могут просто беспобны:) Пример из жизни: Буха 1.6, 8.1/SQL2000, очень увесистая, ежемесячное закрытие затратных счетов можно было делать только после ТиИ - иначе процесс маслает много-много часов и падает в конце концов, у пользователей естественно блокировки. После ТиИ - около 20-30 минут и все закрывалось.
Эта же база: при формировании ОСВ по 62 счету с отбором по одному и тому же контрагенту отчет мог быть сформирован за 2 минуты, а мог и за 2 часа, или вообще не сформирован.
Лечилось опять таки ТиИ, да и то на некоторое время.

жрите кактус, жрите!

(17) 2005

(21) Читайте ещё раз (20) и не несите чушь тк всё работатет нормально если настроить регламентированные задания на SQL.
у меня база 80 гиг все закрывается в лёт.

1) на ресурсы не правильно наложены блокировки
(может у используется postgreesql)

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

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

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


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

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

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

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

(25) Позовите грамотного админа. И отойдите в сторону.

(25) и что, блокировки на скуле приводят к загрузке проца сервера приложений?..

(0) анализ алгоритмов обмена не предлагать?..

При обновлении конфигурации рекомендуют останавливать выполнение регламентных заданий... Почему и тебе тоже самое не сделать при обмене? Имхо.

(29) в смысле при обмене останавливать регламентные задания обмена?

+(30) или при обмене останавливать обновление конфигурации?..

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

PS: странно что ты меня не понял - кажется я ясно выразился

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

Насчет остановки заданий при обновлении - та ки делается. Никакой динамики.

Блокировки? А причем здесь процессор? Характер сбоев при блокировке совершенно иной. Первая же блокировка отвалит просто обмен.

Хотя, я думаю, этот фактор тоже немаловажен, поэтому принимается.

Откажись от 8.1
8.2 гораздо стабильнее. Даже 13 релиз. Особенно при фоновых задачах.
Для 8.2 не нужно столько процессов. 1-2 рабочих и один резервный.
Подключения перестанут обрываться.
Попутно увидишь как резко уменьшится потребление памяти.
Попробуй поставить два или более агентов и разнеси процессы.

(32) а что это может дать?

(33) считай что уже предложил. я бы, кстати, с этого начал...

(36) Спасибо, кэп

(36) С потреблением памяти у меня все в порядке, прочти внимательно описание проблемы. Гибнет проц.

(25)
-Неверно выразился насчет проца - 8 ядер, камней 4. Тут ты прав.
-Используется скуль 2005 (скорее всего без CU)
-если у тебя 3000 филиалов по всей России, включая Владивосток, как ты собираешься их по одному запускать? Мне недели не хватит, чтобы произвести обмен со всеми магазинами в таком случае.
- Исправить блокировки по умолчанию - не понял
- обновить ПО - пук в лужу. Новое - не значит, хорошее. Да и что обновлять? Скуль? Платформу? ОС? Мозги?

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

Все, сказанное тобой - общие слова, но все равно спасибо.

(40) если он потребляет 100% ядра, решение - дробить задачу.

в 8.2 (уф) без отладки на сервере вообще нечего делать. ибо там 99% кода именно на сервере

(43) это ты к чему?

Если принять версию про блокировки. Что посоветуете? Магазинов много, блокировки неизбежны. Сейчас они в автоматическом режиме.

Если бить на транзакции по несколько сотен элементов, нагрузка на сервер может упасть. Уменьшит ли это количество блокировок? До окончания транзакции запись будет заблокирована, но с учетом уменьшенного количества элементов в одной транзакции, таблицы чаще должны освобождаться. Я прав?

всё не читал но! Обмены 1с работают немного странно, при чтении зарегистрированых изменений для выгрузки - записи блокируются даже на чтение. От этого пока не ушли и в 8.2, как варианты ускорения - уменьшение интервалов обменов, будут более маленькие порции данных, но опять же и чаще. Или делать их в наиболее свободное время для системы. Раннее утро, обед, ночь

(0)
обмены РИБ?
Конфигурация типовая, самописка?
готов к переработке обменов?

(0) зависает при выгрузке?

(47) РИБ, переписанная Розница. К этому и стремлюсь)

(48) не висит, обмен идет, но грузит проц на 100%, не отжирает память. Проблемы происходит при загрузке в Центр.

имхо, очередная вариация алгоритма маляра Шлемиля...

(50) как ты определяешь то обмен идет?

(52) "Элементарно!"©Холмс

(53) элементарно? это как?

(54) процессор по 100, значит что-то делает :)

(55) бгыыыыыы

(54) Что за глупые вопросы?

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

дальше продолжать?

(57) РС ИсторияОбменаДанными не легче шлянуть?
з.ы. Конфа то какая?

(58) >> (49)

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

(59) Замер производительности то включал при обмене? это помойму первое что надо сделать. Очертится круг подозреваемых

участвуют ли в обмене измененные типовые или совсем нетиповые документы?

Пока еще не успел, поскольку только вчера начал копаться.
(61) да.

(59) ну например такая загрузка может возникать вследствие конфликтов разных регламентных заданий... Соответственно интересно - пишутся ли объекты в базу при зависании...

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

выполни проверку конфигурации в режиме "сервер" навсякий случай....

(50) если грузит при загрузке, то посмотри:
1 выполни загрузку на клиенте под отдадчиком, посмотри что больше всего вызывается
2 смотреть нет-ли выполнения кода перед/ при записи удалением без проверки обменданными.загрузка
3 если проблема при записи в рн, то отключить актуальные итоги в центральном узле

(0) Будь мужиком, запусти наконец отладчик!

(65) )))