Сделайте замер производительности, посмотрите на какие строчки кода тратиться больше времени. Попробуйте уменьшить время на захват таблиц, представьте ситуацию первый пользователь проводит документ, второй тоже начинает проводить и попадает в транзакцию, тут еще третий на подходе и все ждут (насколько я знаю скуль версия не грузит сервер во время ожидания захвата таблиц, отсюда и небольшая загрузка). Уменьшите это значение до 1, возможно позволит избежать цепных реакций.
Вы используете устаревший браузер. Этот и другие сайты могут отображаться в нем неправильно.
Необходимо обновить браузер или попробовать использовать другой.
Необходимо обновить браузер или попробовать использовать другой.
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
H
Hryv
Сделайте замер производительности, посмотрите на какие строчки кода тратиться больше времени. Попробуйте уменьшить время на захват таблиц, представьте ситуацию первый пользователь проводит документ, второй тоже начинает проводить и попадает в транзакцию, тут еще третий на подходе и все ждут (насколько я знаю скуль версия не грузит сервер во время ожидания захвата таблиц, отсюда и небольшая загрузка). Уменьшите это значение до 1, возможно позволит избежать цепных реакций.
Примерно так и делаю
Проблема в том, что особых изъянов в коде не нахожу
Основные "тормоза" полечить стандартным изменением кода нельзя
Путь использования ВК и прямых запросов я пока не изучал
Да и особых "тормозов" вроде как и нет вообще
Просто несколько раз в день случается так, что все юзеры пытаются создавать/записывать/проводить документы одновременно - вот в эти моменты и возникает проблема. Даже если каждый док проводится по 2-3 секунды
G
Gman
H
Hryv
Честно говоря никогда невидел преимуществ связки 7.7 и SQL, куда проще терминалка и 7.7.
А у вас получалось одновременно залогинить 60 юзеров в 1С на dbf?
Независимо терминал или сеть
У меня начинались проблемы от 15-20 юзеров (один сервер, 4 бызы, по 3-5 юзеров в каждой)
А может и на меньшем количестве (давно было, точно не помню)
Добавлено: Возможно проблема dbf с большим числом юзеров решена в современных серверных виндах
Но индексация после аварийных завершений остается актуальной проблемой
У нас в он-лайн работают розничные точки по всей стране
1 аварийное завершение в 2 дня - гарантия
2 и более вылетов в 1 день - реальность
Ждать всем как минимум 2 часа в день пока пройдет индексация нет никакой возможности
P
puh14
Честно говоря никогда невидел преимуществ связки 7.7 и SQL, куда проще терминалка и 7.7.
А скуль не для скорости - он для базы многолетней. Иначе добется у вас таблица итогов (буховских к примеру) до двух гигов - и привет, базу надо сворачивать.
G
Gman
как раз 60-70 стабильно работают (win2003) в каждой базе, точнее работают 20-30 остальные создают иллюзию.А у вас получалось одновременно залогинить 60 юзеров в 1С на dbf?
Индексируем вечером или с утра (3,5 - 4гб за 15 мин. в среднем). Среди рабочего дня конечно нет, но реально проблемы с индексами возникали всего несколько раз, ну и с автообменом проблемки...Но индексация после аварийных завершений остается актуальной проблемой
Опыта работы с 6гб базами не имею, 4 гб по мойму предел, когда уже пора сворачивать...Ждать всем как минимум 2 часа в день пока пройдет индексация нет никакой возможности
V
vitfil
Интересно, что вы скажите на размер баз в 22 гига...Опыта работы с 6гб базами не имею, 4 гб по мойму предел, когда уже пора сворачивать...
G
Gman
Вот и мне интересна актуальность 1с 7.7 и базы в 22гб... интересна производительность системы при той логике работы 7.7 с SQL. Если же используете прямые запросы, то 1с в данном случае неболее чем интерфейс, но тогда почему бы не создать свой собстенный, лишенный ненужных элементов и настроенный под конкретный учет?Интересно, что вы скажите на размер баз в 22 гига...
V
vitfil
А так оно и есть. 1С - всего лишь пользовательский интерфейс также облагороженный средствами ВК.Если же используете прямые запросы, то 1с в данном случае неболее чем интерфейс, но тогда почему бы не создать свой собстенный, лишенный ненужных элементов и настроенный под конкретный учет?
Д
Дайнеко
В чем беда? Где узкое место?
ЗЫ просьба не ругаться и объяснить как чайнику, так как я физику происходящего внутри 1С и SQL понимаю только в общих чертах
Главный совет: избавится от SQL. Даю голову на отсечение - SQL для 7.7 только имитация работы. Т.е. конвертируйте базу в файловый режим.
Второе узкое место: как я понял один сервер (Citrix) берет данные с другого (SQL). Если так сделали "для распределения нагрузки", то нелепо. Разместите базы на сервере и работайте через Citrix. Ведь пересылка данных по любой скорости все равно медленнее, чем с родного диска. Если сервера одинаковые раскидайте базы. Если один мощнее другой - все на него при загрузке ЦП до 40%.
Третье: если в серверах стоит RAID, очень часто не включают в BIOSе буферизацию записи - тормозит в разы.
P.S. Перечитал форум. Фраза: "..вопрос ... в том что медленно, но железо при этом не загружено" наводит на мысли. 1-действительно потери времени не на вычисление а на обмены.2-на одном сервере так было, пока не включили буферизацию. 3-проверьте на какую дату у вас установлены оперативные и бухгалтерские периоды. Их нельзя делать сильно вперед.
V
vitfil
Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут.Второе узкое место: как я понял один сервер (Citrix) берет данные с другого (SQL). Если так сделали "для распределения нагрузки", то нелепо.
H
Hryv
Раз уж тема опять поднялась, то отвечу
1. От SQL избавиться невозможно (причины я уже указывал)
2. Найдено временное решение.
Сервер под SQL у нас слабее, чем под Citrix.
Решили поставить SQL на сервер к Citrix. Поставили 2005. И перенесли на него одну базу (самую большую и интенсивно используемую).
Примерно через неделю проверили по журналу количество блокировок: оно сократилось в среднем более чем в 2 раза.
Пока на этом остановились.
В планах апгрейд сервера под SQL и попытка возврата базы на него.
Если апгрейд состоится, то отпишусь чем все закончится
1. От SQL избавиться невозможно (причины я уже указывал)
2. Найдено временное решение.
Сервер под SQL у нас слабее, чем под Citrix.
Решили поставить SQL на сервер к Citrix. Поставили 2005. И перенесли на него одну базу (самую большую и интенсивно используемую).
Примерно через неделю проверили по журналу количество блокировок: оно сократилось в среднем более чем в 2 раза.
Пока на этом остановились.
В планах апгрейд сервера под SQL и попытка возврата базы на него.
Если апгрейд состоится, то отпишусь чем все закончится
N
NomadSoul
Встретил недавно случай один реальный... был удивлен...Вот и мне интересна актуальность 1с 7.7 и базы в 22гб... интересна производительность системы при той логике работы 7.7 с SQL.
В 1с 7.7 + MS SQL 2000 + Citrix работают одновременно порядка 150 пользователей, размер базы уже больше 40 гигабайт, база распределенная (распределение сделано для автоматического создания резервных копий, из "рабочей" базы изменения идут в "центральную" и "резервную"). Сервер восьмипроцессорный, оперативки много (вроде 64 гига), операционка 2003 сервер, 64 битка, сетка быстрая. Для Citrix Metaframe сервер отдельный (характеристик не знаю). До ноября 2009 в базе велась бухгалтерия и торговля (компоненты бух. и опер. учет), после 1 ноября (внедрили SAP) осталась только торговля. Производительнось системы была (у меня этот проект закончился в конце ноября) вполне адекватная, до ноября была проблема с блокировками при проведении объемных (более 2000 строк) документов. В основном код был написан стандартно (все на "черных" запросах, естественно, встретил и один прямой запрос), конфа "вылизанностью" не блистала. Использовалась одна внешняя компонента, для считывателя штрих-кодов.
Так что пришлось посмотреть на 1С 7.7 другими глазами :newconfus:
G
Gluk8888
Попробуйте ВК от ромикса "vkhook.dll" (найти можно на мисте) решает проблему загрузки процессоров при работе в терминале
+ рекомендую загружать при начале работы системы компоненту 1cpp.ru для вкллючения функционала turbobl. что ускоряет процессы создания объектов
и до кучи рекомендую почитать здесь:
+ рекомендую загружать при начале работы системы компоненту 1cpp.ru для вкллючения функционала turbobl. что ускоряет процессы создания объектов
и до кучи рекомендую почитать здесь:
Ссылка скрыта от гостей
Д
Дайнеко
Решили поставить SQL на сервер к Citrix. .... количество блокировок: оно сократилось в среднем более чем в 2 раза.
....
В планах апгрейд сервера под SQL и попытка возврата базы на него.
Я правильно понял, теперь на одном сервере данные и хранятся, и к нему подключаются пользователи (значит обрабатываются)? Если, как я и советовал, Вы положили все на 1 сервер, убрав тем самым обмен между ними, то непонятно, зачет опять стремится к старым граблям? Да, если нарастить мускулы раза в два, то порочность решения уже на так будет видна.
Далее, кто-то написал: "Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут." Как человек практикующий и нигилист, абстрактных слов вроде "не живут" не понимаю. В чем конкретно проблема? Да, нагрузка на компьютер в целом высокая, ведь он читает/записывает данные, затем обсчитывает. Но нету глупого обмена по сети между серверами. А объем этот огромен, т.к. технология SQL в исполнении 1С 7.7 это только название - он мало чем отличается от файлового. Наконец, если именно программа SQL категорически не хочет с программой Citrix - использовать Terminal Server.
N
NomadSoul
Далее, кто-то написал: "Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут." Как человек практикующий и нигилист, абстрактных слов вроде "не живут" не понимаю. В чем конкретно проблема?
IMHO, проблема в том, что и Citrix Metaframe и MS SQL server (особенно он) при большой нагрузке занимаются тем, что "подгребают" под себя все доступные системные ресурсы. А идея "Citrix Metaframe на одном компьютере, а MS SQL server на другом" в том, чтобы на компе с MS SQL освободить (переложить на другой комп) часть ресурсов, которые необходимы для работы сервера терминалов.
D
dimetra2008
Обучение наступательной кибербезопасности в игровой форме. Начать игру!
Поделиться: