Оптимизация 1С 7.7 + Sql + Citrix

Блин, так и не смог старым ником зайти, пришлось по новой региться
Но это так о наболевшем

А вот может кто даст совет по теме

Есть такая система
Два сервака: на одном Citrix, на втором SQL, соединены гигабитом
Юзеры заходят в 1С через Citrix
В 4 разные базы
При этом в 3 базы одновременно до 20 подключений вместе взятых, а в четвертую 30-50
Ее SQL-ный файл около 6 гиг. (Три первые вместе меньше ее)

При работе с этой базой не очень понятная ситуация.

1С подтормаживает, некоторые документы проводятся по несколько минут
Но при этом "железо" совсем не нагружено
Процессоры на обоих серваках на 10-30%, сеть вообще на 3-5%

В чем беда? Где узкое место?

ЗЫ просьба не ругаться и объяснить как чайнику, так как я физику происходящего внутри 1С и SQL понимаю только в общих чертах

0

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

0

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

Примерно так и делаю
Проблема в том, что особых изъянов в коде не нахожу
Основные "тормоза" полечить стандартным изменением кода нельзя
Путь использования ВК и прямых запросов я пока не изучал

Да и особых "тормозов" вроде как и нет вообще
Просто несколько раз в день случается так, что все юзеры пытаются создавать/записывать/проводить документы одновременно - вот в эти моменты и возникает проблема. Даже если каждый док проводится по 2-3 секунды

0

Честно говоря никогда невидел преимуществ связки 7.7 и SQL, куда проще терминалка и 7.7.

0

Сообщение от Gman Честно говоря никогда невидел преимуществ связки 7.7 и SQL, куда проще терминалка и 7.7.

А у вас получалось одновременно залогинить 60 юзеров в 1С на dbf?
Независимо терминал или сеть

У меня начинались проблемы от 15-20 юзеров (один сервер, 4 бызы, по 3-5 юзеров в каждой)
А может и на меньшем количестве (давно было, точно не помню)

Добавлено: Возможно проблема dbf с большим числом юзеров решена в современных серверных виндах

Но индексация после аварийных завершений остается актуальной проблемой
У нас в он-лайн работают розничные точки по всей стране
1 аварийное завершение в 2 дня - гарантия
2 и более вылетов в 1 день - реальность

Ждать всем как минимум 2 часа в день пока пройдет индексация нет никакой возможности

0

Честно говоря никогда невидел преимуществ связки 7.7 и SQL, куда проще терминалка и 7.7.

А скуль не для скорости - он для базы многолетней. Иначе добется у вас таблица итогов (буховских к примеру) до двух гигов - и привет, базу надо сворачивать.

0

Сообщение от Hryv А у вас получалось одновременно залогинить 60 юзеров в 1С на dbf?

как раз 60-70 стабильно работают (win2003) в каждой базе, точнее работают 20-30 остальные создают иллюзию.

Сообщение от Hryv Но индексация после аварийных завершений остается актуальной проблемой

Индексируем вечером или с утра (3,5 - 4гб за 15 мин. в среднем). Среди рабочего дня конечно нет, но реально проблемы с индексами возникали всего несколько раз, ну и с автообменом проблемки...

Сообщение от Hryv Ждать всем как минимум 2 часа в день пока пройдет индексация нет никакой возможности

Опыта работы с 6гб базами не имею, 4 гб по мойму предел, когда уже пора сворачивать...

0

Опыта работы с 6гб базами не имею, 4 гб по мойму предел, когда уже пора сворачивать...

Интересно, что вы скажите на размер баз в 22 гига...

0

Сообщение от vitfil Интересно, что вы скажите на размер баз в 22 гига...

Вот и мне интересна актуальность 1с 7.7 и базы в 22гб... интересна производительность системы при той логике работы 7.7 с SQL. Если же используете прямые запросы, то 1с в данном случае неболее чем интерфейс, но тогда почему бы не создать свой собстенный, лишенный ненужных элементов и настроенный под конкретный учет?

0

Если же используете прямые запросы, то 1с в данном случае неболее чем интерфейс, но тогда почему бы не создать свой собстенный, лишенный ненужных элементов и настроенный под конкретный учет?

А так оно и есть. 1С - всего лишь пользовательский интерфейс также облагороженный средствами ВК.

0

Сообщение от Hry В чем беда? Где узкое место? ЗЫ просьба не ругаться и объяснить как чайнику, так как я физику происходящего внутри 1С и SQL понимаю только в общих чертах

Главный совет: избавится от SQL. Даю голову на отсечение - SQL для 7.7 только имитация работы. Т.е. конвертируйте базу в файловый режим.
Второе узкое место: как я понял один сервер (Citrix) берет данные с другого (SQL). Если так сделали "для распределения нагрузки", то нелепо. Разместите базы на сервере и работайте через Citrix. Ведь пересылка данных по любой скорости все равно медленнее, чем с родного диска. Если сервера одинаковые раскидайте базы. Если один мощнее другой - все на него при загрузке ЦП до 40%.
Третье: если в серверах стоит RAID, очень часто не включают в BIOSе буферизацию записи - тормозит в разы.

P.S. Перечитал форум. Фраза: "..вопрос ... в том что медленно, но железо при этом не загружено" наводит на мысли. 1-действительно потери времени не на вычисление а на обмены.2-на одном сервере так было, пока не включили буферизацию. 3-проверьте на какую дату у вас установлены оперативные и бухгалтерские периоды. Их нельзя делать сильно вперед.

0

Второе узкое место: как я понял один сервер (Citrix) берет данные с другого (SQL). Если так сделали "для распределения нагрузки", то нелепо.

Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут.

0

Раз уж тема опять поднялась, то отвечу

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

2. Найдено временное решение.
Сервер под SQL у нас слабее, чем под Citrix.
Решили поставить SQL на сервер к Citrix. Поставили 2005. И перенесли на него одну базу (самую большую и интенсивно используемую).
Примерно через неделю проверили по журналу количество блокировок: оно сократилось в среднем более чем в 2 раза.
Пока на этом остановились.
В планах апгрейд сервера под SQL и попытка возврата базы на него.

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

0

Сообщение от Gman Вот и мне интересна актуальность 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:

0

Попробуйте ВК от ромикса "vkhook.dll" (найти можно на мисте) решает проблему загрузки процессоров при работе в терминале
+ рекомендую загружать при начале работы системы компоненту 1cpp.ru для вкллючения функционала turbobl. что ускоряет процессы создания объектов
и до кучи рекомендую почитать здесь: http://www.kb.mista.ru/article.php?id=136

0

Сообщение от Hryv Решили поставить SQL на сервер к Citrix. .... количество блокировок: оно сократилось в среднем более чем в 2 раза. .... В планах апгрейд сервера под SQL и попытка возврата базы на него.

Я правильно понял, теперь на одном сервере данные и хранятся, и к нему подключаются пользователи (значит обрабатываются)? Если, как я и советовал, Вы положили все на 1 сервер, убрав тем самым обмен между ними, то непонятно, зачет опять стремится к старым граблям? Да, если нарастить мускулы раза в два, то порочность решения уже на так будет видна.

Далее, кто-то написал: "Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут." Как человек практикующий и нигилист, абстрактных слов вроде "не живут" не понимаю. В чем конкретно проблема? Да, нагрузка на компьютер в целом высокая, ведь он читает/записывает данные, затем обсчитывает. Но нету глупого обмена по сети между серверами. А объем этот огромен, т.к. технология SQL в исполнении 1С 7.7 это только название - он мало чем отличается от файлового. Наконец, если именно программа SQL категорически не хочет с программой Citrix - использовать Terminal Server.

0

Сообщение от Дайнеко Далее, кто-то написал: "Нелепым и даже глупым было бы ставить на один сервер Цитрикс с Сиквелом - не живут они вместе, потому как ресурсы поделить не могут." Как человек практикующий и нигилист, абстрактных слов вроде "не живут" не понимаю. В чем конкретно проблема?

IMHO, проблема в том, что и Citrix Metaframe и MS SQL server (особенно он) при большой нагрузке занимаются тем, что "подгребают" под себя все доступные системные ресурсы. А идея "Citrix Metaframe на одном компьютере, а MS SQL server на другом" в том, чтобы на компе с MS SQL освободить (переложить на другой комп) часть ресурсов, которые необходимы для работы сервера терминалов.

0

Нужна оптимизация базы 1с средствами sql сервера Регламентные операции базы ms sql server