УТ 10.3 клиент-сервер. Справочник номенклатуры ~10к. Подбор номенклатуры в режиме "по остаткам и ценам" с выключенной иерархией. При перемещении по списку тормоза не заметны, если делать поиск по наименованию (встать на колонку, начать писать первые буквы) иногда список "задумывается" на несколько секунд, вводимые буквы теряются. Вырезал весь код при активации строки. Замер производительности не показывает ни где ни каких нагрузок. А список тормозит. Что еще можно посмотреть/подкрутить?
По теме из базы знаний
Ответы
Подписаться на ответы
Инфостарт бот
Сортировка:
Древо развёрнутое
Свернуть все
А может сама БД тормозит? Написали бы какую БД исполуете. Может там памяти не хватает, может ошибки. При выборке-то первоначально идет запрос выбирающий записи соответствующие определенному условию. А потом помещает результат во временную таблицу. Так что это тяжелая операция.
(5) Const1C, ну да: на MS SQL, БД 4ГБ, лог 1ГБ, кроме этого на SQL крутится БП ~20ГБ, для просмотра висит 7.7 (~то же около 20ГБ). На 7.7 постоянно ~20 пользователей, в УТ ~50, активно работают 10-20.
Сервер 2-х процессорный ксеон. 12 ГБ ОЗУ, под SQL отдано 10.
Сервер 2-х процессорный ксеон. 12 ГБ ОЗУ, под SQL отдано 10.
В общем сделайте так. Выгрузите/Загрузите БД 1С и ребутните сервак там где у вас SQL. Если база активно используется, задумайтесь о разделении сервера 1С и MSSQL.
На самом сервере 1С, следует создать столько работающих процессов, сколько у вас ядер на сервере.
А вообще по железу у вас слабое.
ЗЫ. На одном сервере у нас крутится 2 базы Бухгалтерия и Зарплата. И прям таких существенных тормозов при активной работе их обеих не замечено
На самом сервере 1С, следует создать столько работающих процессов, сколько у вас ядер на сервере.
А вообще по железу у вас слабое.
ЗЫ. На одном сервере у нас крутится 2 базы Бухгалтерия и Зарплата. И прям таких существенных тормозов при активной работе их обеих не замечено
(15) alwiz3, Разделить количество рабочих процессов по ядрам, позволит вам максимально распределить нагрузку на сервер.
Так как БД крутится в основном в оперативной памяти, следует выбрать наиболее производительную память. И, соответственно, эта память должна быть вся из одной партии. Т.е. они должны быть максимально синхронизированы. На БД выделить столько памяти, сколько можете. Так же дисковая подсистема должна работать на достаточно высоких скоростях. ИМХО, должна быть близка к одному гигабайту в секунду в пределах тома.
Я думаю это будет достаточно, для гарантии, что БД не окажется узким местом в системе.
ЗЫ. Да есть еще такой момент - своп. Он должен быть 0.5 - 1 от количества оперативной памяти. MSSQL очень активно с ним работает. А его недостаток негативно влияет на производительность.
что наращивать?Так как БД крутится в основном в оперативной памяти, следует выбрать наиболее производительную память. И, соответственно, эта память должна быть вся из одной партии. Т.е. они должны быть максимально синхронизированы. На БД выделить столько памяти, сколько можете. Так же дисковая подсистема должна работать на достаточно высоких скоростях. ИМХО, должна быть близка к одному гигабайту в секунду в пределах тома.
Я думаю это будет достаточно, для гарантии, что БД не окажется узким местом в системе.
ЗЫ. Да есть еще такой момент - своп. Он должен быть 0.5 - 1 от количества оперативной памяти. MSSQL очень активно с ним работает. А его недостаток негативно влияет на производительность.
alwiz3
По моему опыту, проблема скорости в подборе, да еще и с ценами и особенно с остатками связана с тем, что пересчитываются остатки и цены в тот момент, когда юзер жмет кнопку навигации, типа стрелка вниз или Page Up.
И это происходит при написании отборов стандартным образом. Обычно программеры пишут и тестируют, используя маленькие базы с 3-4 позициями номенклатуры. Тоже происходит и в 1С.
Короче, мало кто смотрит, в каком мести помещать пересчет остатков и цен, некоторые загоняют эти пересчеты даже в цикл, вместо того чтобы все пересчитать при открытии формы, закинуть это в "массив" или в "табл. значений" и потом уже обращаться к этим объектам при перемещении по списку, а не пересчитывать каждый раз...
Сколько раз я уже переписывал такие вещи, и даже на 486-х машинах 1С начинает летать...
Такие ошибки очень часто допускают и 1С-цы...
Смотрите код. И дел не в серверах или рабочих станциях...
По моему опыту, проблема скорости в подборе, да еще и с ценами и особенно с остатками связана с тем, что пересчитываются остатки и цены в тот момент, когда юзер жмет кнопку навигации, типа стрелка вниз или Page Up.
И это происходит при написании отборов стандартным образом. Обычно программеры пишут и тестируют, используя маленькие базы с 3-4 позициями номенклатуры. Тоже происходит и в 1С.
Короче, мало кто смотрит, в каком мести помещать пересчет остатков и цен, некоторые загоняют эти пересчеты даже в цикл, вместо того чтобы все пересчитать при открытии формы, закинуть это в "массив" или в "табл. значений" и потом уже обращаться к этим объектам при перемещении по списку, а не пересчитывать каждый раз...
Сколько раз я уже переписывал такие вещи, и даже на 486-х машинах 1С начинает летать...
Такие ошибки очень часто допускают и 1С-цы...
Смотрите код. И дел не в серверах или рабочих станциях...
У нас так было, в одном месте, проблема с железом на компе оказалось, хотя компы все и новые были. Также проверьте сеть и не загружен ли SQL на сервере заданиями, также было регламентное задание и скуль каждые полчаса забирал 99% памяти.
Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот