Добрый день.
Возник спор между мной, системным администратором, и 1с интегратором. При формировании печатной формы ТН процесс 1с забирает весь доступный ресурс процессора. Если эта обработка не используется - все работает отлично. При этом 1с разработчики кричат что проблема не в их коде, а в железе или настройках системы сервера. Вот даже одно из их писем:
Локальные компьютеры отпадают, так как работа идет через RDP. Сервер - виртуальная машина, выделено 11 гигов ОЗУ и 3Ггц процессор - 1 ядро. Можно конечно выделить больше ядер, но это только кое-как сгладит проблему, но не решит в корне.
как можно доказать свою точку зрения 1сникам?
У кого какие мнения и соображения на эту тему?
Возник спор между мной, системным администратором, и 1с интегратором. При формировании печатной формы ТН процесс 1с забирает весь доступный ресурс процессора. Если эта обработка не используется - все работает отлично. При этом 1с разработчики кричат что проблема не в их коде, а в железе или настройках системы сервера. Вот даже одно из их писем:
По загрузке процессора поясняю:
Проблема была не в коде, дословно было сказано «Мы нашли небольшой баг, сейчас исправим», после чего мы написали Кристине о проблеме ввода данных:
[09.08.2016 19:31:25] Екатерина: Кристина, печатная форма долго формировалась, так как дата установки цен позже перемещения.
Дело было в том, что цены для накладной были внесены позже, чем проводилось перемещение. Программа искала цены по всей истории.
Однако, вопрос, даже если программа ищет глубоко, почему может забиваться процессорное время и память сервера.
Обращаю ваше внимание на то, что долгая работы программы может быть связана и с конфигурацией оборудования, как сервера, так и локальной машины. Если локальная машина не имеет достаточных ресурсов, то исполнение идет на сервер. У одного из наших клиентов проблема решилась модернизацией оборудования.
Мы не против оптимизировать код стандартных механизмов, если это требуется. При разработке мы рассчитываем на системные требования 1с.
Проблема была не в коде, дословно было сказано «Мы нашли небольшой баг, сейчас исправим», после чего мы написали Кристине о проблеме ввода данных:
[09.08.2016 19:31:25] Екатерина: Кристина, печатная форма долго формировалась, так как дата установки цен позже перемещения.
Дело было в том, что цены для накладной были внесены позже, чем проводилось перемещение. Программа искала цены по всей истории.
Однако, вопрос, даже если программа ищет глубоко, почему может забиваться процессорное время и память сервера.
Обращаю ваше внимание на то, что долгая работы программы может быть связана и с конфигурацией оборудования, как сервера, так и локальной машины. Если локальная машина не имеет достаточных ресурсов, то исполнение идет на сервер. У одного из наших клиентов проблема решилась модернизацией оборудования.
Мы не против оптимизировать код стандартных механизмов, если это требуется. При разработке мы рассчитываем на системные требования 1с.
Локальные компьютеры отпадают, так как работа идет через RDP. Сервер - виртуальная машина, выделено 11 гигов ОЗУ и 3Ггц процессор - 1 ядро. Можно конечно выделить больше ядер, но это только кое-как сгладит проблему, но не решит в корне.
как можно доказать свою точку зрения 1сникам?
У кого какие мнения и соображения на эту тему?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
(1) alanderex, код их выложить. сложно что-то определенное сказать. (замер производительности можно попробовать, его уже посоветовали, но может ничего и не дать). "программа глубоко ищет", не знаю что это означает и что имелось ввиду. с вероятностью 99,9% кривой код. а что там такого в печатной форме, что требует крутые вычислительные ресурсы сервера и модернизации оборудования,это и хотелось бы узнать.
платформа может занимать 100% одного ядра
Так что для виртуальной машины лучше выделить еще одно ядро
но на том же "занятом" ядре могут находится и рабочие процессы n-ного количества пользователей. Получается выделение доп.ядра спасет только тех, кому повезло быть не на этом занятом ядре...
(8) alanderex, если печ. форма долго формируется, то программистам надо найти место, которое жрет больше всего времени и попытаться его оптимизировать. Почти всегда с этим можно что-нибудь сделать. Остальные печатные формы в других документах формируются нормально? Отчеты делаются быстро? С проведением документов проблем нет? Если все так, то проблема не в конфигурации сервера или количестве пользователей, а конкретно в этой форме.
Все зависит от размера базы, типа СУБД, архитектуры хранения данных. Вы ничего не сказали о том, какая печатная форма в какой конфигурации и на какой платформе формируется. То, что код кривой - это точно, но без полных сведений о решении что-то конкретное сказать невозможно.
Очень сложно что то сказать без кода, могу лишь предположения высказать.
1) Вероятно печать ТТН (формирование вывода на печать) не проблема, скорее всего программисты по требованию Заказчика дописывали заполнение определенных полей (вероятно цен) по интересному алгоритму и надо смотреть как они это делали. Не могу сказать, что редко встречаю подобный код с циклом в котором есть подзапрос + еще один цикл по обработке и соответственно нагрузка на ЦП 100%.
2) Если все типовое без модификации, то скорее нужно смотреть в момент загрузки ЦП (опять же код и отладка), возможно проблема с драйверами принтера, т.е. при выводе на пред. осмотр или запрос каких то параметров происходит глюк и обработка пытается получить и обработать данные следовательно 100% загрузка. И это может объяснить почему на компе разработчика скорее всего все гуд.
На этом предсказания закончу.
PS А вообще в данной ситуации очень просто все скинуть на систему или сервак, особенно в такой ооооочееень ресурсоемкой операции как печать ТТН!!!!! Не ругайтесь, а совместно, т.е. дружно найдите в чем косяк, если что зовите суперменов ))))
1) Вероятно печать ТТН (формирование вывода на печать) не проблема, скорее всего программисты по требованию Заказчика дописывали заполнение определенных полей (вероятно цен) по интересному алгоритму и надо смотреть как они это делали. Не могу сказать, что редко встречаю подобный код с циклом в котором есть подзапрос + еще один цикл по обработке и соответственно нагрузка на ЦП 100%.
2) Если все типовое без модификации, то скорее нужно смотреть в момент загрузки ЦП (опять же код и отладка), возможно проблема с драйверами принтера, т.е. при выводе на пред. осмотр или запрос каких то параметров происходит глюк и обработка пытается получить и обработать данные следовательно 100% загрузка. И это может объяснить почему на компе разработчика скорее всего все гуд.
На этом предсказания закончу.
PS А вообще в данной ситуации очень просто все скинуть на систему или сервак, особенно в такой ооооочееень ресурсоемкой операции как печать ТТН!!!!! Не ругайтесь, а совместно, т.е. дружно найдите в чем косяк, если что зовите суперменов ))))
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот