Снова о тормозах. УПП, мощный сервер, около 50 юзеров #682781

В последнее время стало совсем невозможно жить. Если раньше на время помогала выгрузка-загрузка в dtник, то сейчас эффект практически нулевой от этого действия. Документы, связанные с партионными движениями могут проводиться от секунд до минут (не скажу что это один и тот же док, но по параметрам близкие, например две реализации). Строк в реализациях от 1 до 20, в ТН - 10-40. В остальных доках примерно то же самое. УПП, 1.3.43.2, партионка по среднему. платформа 8.2.18.109 серверная часть на одном сервере с sql. 28Г памяти, сколько-то много процов, быстрая дисковая подсистема (я в этом не спец, но по уверениям админов сервер 90% времени простаивает, нагрузки нет). В кластере серверов 1с создано 2 рабочих процесса, настроен их перезапуск. На sql - настроены по шедулеры все рекомендуемые регламенты. Куда еще копать - ума не приложу ( Сейчас вот проводило реализация с 2 строками несколько минут и в итоге выдало: Ошибка при выполнении обработчика - 'ОбработкаПроведения' по причине: {Документ.РеализацияТоваровУслуг.МодульОбъекта(3492)}: Ошибка при вызове метода контекста по причине: Ошибка обращения к серверу 1С:Предприятия. по причине: server_addr=tcp://S-1C-1-HW:1565 descr=Ошибка сетевого доступа к серверу (Windows Sockets - 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение. ) line=1041 file=SrcDataExchangeTcpClientImpl.cpp Строка 3492 в модуле это вызов УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить); В общем хелп, кто чем сможет )

Да размер базы (mdf) - около 40Г Отключили недавно бэапирования лога транзакций на sql, выставили базу в simple mod. Соответственно лог - до 100 Мб. Но прироста производительности не получили. tempdb - на отдельном ssd диске. что еще можно сделать?

Сервер 1С 32-битный? Ключи аппаратные?

Какой-то лог маленький.

Поиск узкого места в железе осуществлялся?

- сервер 64 битный - когда была полная модель восстановления до 100гиг доходило - как сие сделать, чтобы админам предложить? по их словам сервер не нагружен и на 20 процентов

>В кластере серверов 1с создано 2 рабочих процесса, настроен их перезапуск. 1 раб. процесс на 4 гига оперативки, соответственно как минимум увеличить до 5 раб. процессов

Его ограничили, что-ли?

опечатка в на сервере 48Г памяти

>>tempdb - на отдельном ssd диске. Отличный способ внезапно потерять данные. Проверено на 2 различных серверах, которые последовательно вышли из строя по причине смерти ссд-шек. При чем откатиться на бэкап было нельзя т.к. "умирали" серваки постепенно, и юзеры успели наколбасить достаточно много данных. Пришлось лечить каждую поврежденную табличку отдельно. Вам это надо? Да еще и при симпл модели.

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

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

что-то в сетке не так

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

запускаешь проведение документа и смотришь загрузку процессора процессом rphost.exe. Если она постоянна и равна 100/<число_ядер>, то скорее всего регистр партий разросся до неприличия. А в момент падения клиентской части скорее всего увидишь и падение rphost из за недостатка памяти. Но это так чисто телепатия.

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

Регламенты в скуле выполняются?

сетка 99%

Из за умирания tempdb - умирают базы? Вот это поворот!

блин! регламент же должен рассчитывать. а не отработал. итоги в 31.08. сенкс!! это поправлю, понаблюдаю

Да

а что может быть с сеткой? что мониторить?

Ну, если точнее в первом случае на ссд был кэш контроллера дискового массива, где лежали сами базы. А во втором таки да - данные были испорчены из-за глюков ссд-шки с темпдб. В обоих случаях ссд умирали по причине выработки ресурса. В обоих случаях они умирали не сообщая о том что ресурс перезаписи заканчивается, и вообще не выдавая каких-либо ошибок, и не переходя в режим read-only. И что характерно - после переноса tempdb на массив из обычных пятнадцатитысячников к основным базам, не было никакого падения производительности. Для себя я выводы сделал.

Сервер 1С и Сервер СУБД на разных машинках ??? Они надеюсь напрямую между собой контачат Гигабитом(минимум) ? Или в какой нибудь супер пупер ЦИСКО воткнуты ? вместе с юЗверями ? Сетка 98%. Имхо.

Сорри невнематочно читал то есть на одной железяке 1С+СУБД ? Тогда точно сетка, если в моммент проведения железяка курит.

да, на одном сервере. юзеры в терминалах на других серверах.

ЦУП уже предлагали?

уже много раз думал в эту сторону ) был на паре семинаров франчевых по производительности. с их слов, информация которая получена с помощью ЦУП мягко говоря помогает крайне редко. вернее не так. информации много можно получить, вся она очень интересна, но чтобы получить реальный прирост один хрен придется курочить типовые модули. а т.к. мне сие вообще никуда не уперлось - то пока ЦУП откладывается

ТС настолько наивен, что ждёт от форума решения своей проблемы, стоящее его квартальной зарплаты ?

Если кто-то готов взяться за решение проблемы за разумные деньги и реальные сроки и гарантировать результат (без переписывания типовых модулей) - это обсуждаемо. и кстати напомнили про пересчет итогов, который почему-то не выполнился регламентом - сделал ручками, первое впечатление - гут. стало много легче. теперь буду контролировать. спасибо форуму и отдельно Fragster!

процессов-то можно и поболе насоздавать, чай памяти-то дофига. Ну да это не спасет все равно

"В кластере серверов 1с создано 2 рабочих процесса, настроен их перезапуск" Перезапуск как настроен? Может на объем памяти? Проблема у вас из за падения(или перезапуска) рабочих процессов. Настроить техжурнал и ловить. Еще можно для ускорения врубить shared memory.

мы экспериментировали от одного до 8. по ощущениям 2 - лучше всего. хотя даже с настроеным временем жизни процесса 12 часов и смерти после этого через 12 часов, они иногда зависают. И зависший процесс реально поттормаживает.

Модели сдохших SSD ?

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

"админы говорят, что делают все возможное и не возможное. предлагают переписать партионный блок в 1С ), типа единственное спасение." - короче, смотреть ничего не хотят, валят всё на 1С. Посмотри вместе с ними счетчики производительности на сервере.

заметь, уже не 1 человек тебе говорит, что админы либо ленивые, либо малознающие, выбирать тебе.

Спасибо всем! когда будем с админами следующий раз думать, что делать, скину им ссылку на эту ветку. может поможет )

обязательно отпишись как решили проблему, интересно

Эйфория в и была немного преждевременна. Симптомы остались в целом прежние. То густо, то пусто. Ну т.е. то 1-2 минуты на реализацию, то пара секунд. Запускает один и тот же юзер. Активность остальных - тоже в норме. Мега отчеты никто не запускает, документы скопом какой-нить обработкой не формирует/не проводит. Админы очень интересуются, куда могут падать пакеты и как это на 1С влияет? Если сервер 1С и сервер БД на одной машине. И маршрутизаторы не из дешевых. Циски.

ну что вернулись к

(39+) каких-то особых всплесков по процессорному времени и отожратой памяти на rphost-ах при зависаниях и не зависаниях не отмечено. всего 4 процесса rphost. каждый в среднем юзает проц на 3-7%. Памяти - не больше гига. Всплесками загрузка проца до 15%, но с проведением доков именно этим пользователем это не связано. Активность других.

Я в озвучил готовность заплатить за результат. А так - наверное да.

Зайти на сервер по rpd и запустить там 1С, чтобы исключить влияние сети. При проведении документа посмотреть нагрузку на сервер. Если это слишком сложно, то позовите, наконец, специалистов.

если явно не указано localhost, то трафик может идти как угодно. shared memory стоит использовать. на циске по умолчанию может быть не включен Flow Control и так далее.

в смысле по рпд? они локально юзают шоле?

а, в терминалах

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

а я бы  ещё глянул нагрузку терминал сервера.  как я понимаю он отдельно от SQL+1c.   если все 50 пользователей  на терминале  то они  могут  там  разносить дисковое  пространнство оного тока в путь.

Зашел на сервер. Запустил базу (в качестве сервера прописано localhost). Реализация. 4 строки. 48 секунд. на rphost-ах никак не отразилось. должны. админы во всяком случае утверждают, что выполняются ночью после бэкапирования.

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

+ 1     что тормозит проверить 5 секунд замером.

а отложенное проведение по партиям врубить - не?

вам, наверное, к gilev.ru. По крайней мере, "удаленное ознакомление с проблемой и предварительная оценка объёма работ" - бесплатно :-) тут тусуются в разной степени инкарнации odavid :-)

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

это?

А что они делают с суммой "здесь и сейчас"?

напиши им отчет о приблизительной стоимости, пусть его смотрят

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

кароче, переходи на РАУЗ ))

Им так спокойнее. Зависшие количества без сумм и наоборот бухгалтерия регулярно мониторит, разбирается и приводит в чувство. Главбуху "черный ящик" РАУЗА как нож вострый. Когда в течении месяца непонятно как закроется и расчет себестоимости на много часов (это совсем не устраивает)

что замер производительности показывает то?

весь пост - вода :)

УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров(Ссылка, Движения.СписанныеТовары.Выгрузить);    1    69,323181    82,79

69 с лишним секунд и 82% на движение партий..

кстати, если несвежий УПП, то там запрос с соединений на временные переписать сильно помогает

Если на сервере 48 сек то тут надо отладчиком или другими обработками проверить что там долго считается. Выше сказали надо  капнуть регистры.

ну а теперь смотри что тормозит в УправлениеЗапасамиПартионныйУчет.ДвижениеПартийТоваров

все не читал, на сервере режим энергопотребелния какой включен?

ты сам посмотри тупым универсальным отчетом

softpoint или Гилев решат ваши проблемы за пару дней. Там скорее всего пару запросов надо переписать, регистры закрыть и индексы включить.

Индексы ладно. А потом 1С в новом релизе че-нить меняет партионное - и привет. Это пока не могу. Отладка на сервере не включена. Да смотрел. нет там ничего криминального. И собственно насчет закрытия партий и переписывания запросов: если бы дело в этом было, то не было бы скачков от секунд до минут. Всегда получал бы стабильно плохие результаты.

+ к   а ещё сервер физический или виртуальный?:)

ЦУП. и переписывать, переписывать, переписывать...

на виртуальных ваще беда ). хардварный

почитай Гилева. Навскидку - давние опорные итоги/неразделенные итоги, нет отложенного проведения, журнал транзакций на диске с рабочей базой, неоптимальные  запросы, РЛС, большая фрагментация индексов на скл, синхронная статистика зы  500Гб база 200 юзеров все тянет

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

Причем, описанные симптомы проявлялись только в одном секторе сети.

вобщем решили. вали все на админов

Смотри не ЦУП, смотри счетчики производительности

Дык сетку проще простого идентифицировать. Установите 1С вечером прямо на сервер, отрубите внешние подсетки и запустите проведение с сервера. Если все будет летать - сетка.

ИМХО у тебя диски лажовые

У меня была база 150 гиг, 100 юзеров, проводилось секунд за 10. SQL точно только 1С юзает?

За билет на ИС могу попробовать ускорить проблемный участок. Раза в три-пять. но конфу корежить чуть чуть нужно

Согласен. О чем вообще можно говорить, если ТС даже ping -t на сервак не проверил. Да еще с не стандартным размером пакетов.

А никого не смутила фраза: "tempdb - на отдельном ssd диске"? ЭТО ЖЕ НОНСЕНС! ssd оптимальнее под чтение, а не под постоянную перезапись. Куда оптимальнее поставить RAID 10 отдельно для БД, отдельно логов, отдельно под tempdb. Без ssd.

Я думаю, это тема отдельной ветки. И с Ошибка при выполнении обработчика - 'ОбработкаПроведения' по причине: {Документ.РеализацияТоваровУслуг.МодульОбъекта(3492)}: Ошибка при вызове метода контекста по причине: Ошибка обращения к серверу 1С:Предприятия. по причине: server_addr=tcp://S-1C-1-HW:1565 descr=Ошибка сетевого доступа к серверу (Windows Sockets - 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение. ) line=1041 file=SrcDataExchangeTcpClientImpl.cpp Никак не связана.

Мы использовали массив ssd для OLAP. Вот там было здорово!

совсем не связан, но ТС Гилева не читал =)

Ну "Удаленный хост принудительно разорвал существующее подключение" - это потеря пакетов стопудово. У нас такое было, когда периодически рвалось соединение клиентов с сервером DNS. Они получали новый динамический ip и их отрубало от сервера 1С...

в 90% случаев это фоновое задание

У ТС всего 2 рабочих процесса, если бы фоновое задание валило процесс, половина юзверей бы вылетела.

в том числе, но я к тому, что тут тс не найдет решений проблемы, имхо :-)

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

Автор, админов пинай. Серьёзно. Эти продуманные ребята, оценивают производительность по диспетчеру, где стоит загрузка процов. У нас в одной конторе процы вообще процентов на 5-10 загружались, а диски на 1100% Меня тоже тут один "крутой" автосервис долбил в плане тормозов. И сервер хорорший и пользователи по струнке ходят, а админ вообще образец честности и порядочности. В итоге выяснилось, что кто-то нечаянно на серверах разместил игровые сервера. Один с вовкой, один с контерстрайком. Вроде мелочи, а работать могли только на счетах