Архитектура ИТ-системы на базе 1С в крупной организации

Администрирование - Оптимизация БД (HighLoad)

94
В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

Добрый день. В данной статье я хотел бы очень крупными мазками обрисовать архитектуру ИТ системы на базе 1С в крупных (более 1 тысячи пользователей) организациях. Она не несет какой либо образовательной цели, это просто попытка показать – «а как у нас».

Часть 1. Архитектура.

Компания владеет крупной сетью магазинов. На текущий момент в сети где то 2700-3000 магазинов со средним количеством рабочих мест 2,4. Значительное количество операций, связанных с обслуживанием клиентов (продажа и замена сим карт, регистрация контрактов, подключение услуг новым абонентам), с товародвижением (приём и отгрузка товара, проведение инвентаризаций), все розничные операции (работа с кассовыми сменами, продажа товара, акционные механики) выполняются в 1С.

Ежедневное количество активных пользователей порядка 7000

количество чеков в пике достигает 300 в минуту, размер базы ~2.6 Тб.

Для обеспечения работоспособности системы создан кластер со следующей архитектурой:

Плюсы решения:

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

Возможность горизонтального масштабирования application кластера. Добавление нового кластера занимает примерно полдня, но для ускорения процесса в критических ситуациях возможен перевод сервера из тестового стенда в продуктив, на это уйдёт не более 10 минут.

Минусы решения:

Отсутствие полноценной отказоустойчивости. При падении одного из центральных кластеров примерно 50% пользователей получат недоступность системы, им потребуется перезайти в неё.

Особенности:

Дальнейшее я отношу к особенностям решения, а не к минусам, так как изменение архитектуры не может повлиять на ситуацию.

  1. Практически невозможно в течение дня безболезненно выгнать всех пользователей для срочного обновления. Даже если само обновление конфигурации займет 1 минуту процесс обновления выглядит следующим образом:
    • Установка блокировки базы (делается заранее)
    • Ожидание, пока все пользователи выйдут из базы (примерно 2-3 минуты с начала блокировки).
    • Остановка служб на серверах, где находятся сеансовые данные. (2-3 минуты)
    • Очистка сеансовых данных. (1 минута)
    • Непосредственно обновление конфигурации. (1 минута)
    • Запуск пользователей. (1 минута)
    • Стабилизация нагрузки после входа. (3-5 минут)

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

Причина - большой объем сеансовых данных, которые потребуется загрузить одномоментно, в случае если их не очистить (порядка 20 Гб). Практика показала, что система (именно 1С) не справляется с загрузкой такого объема данных за приемлемое время, в результате чего пользователи на протяжении 5-10 минут наблюдают окно с запуском конфигурации.

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

В ближайшее время мы планируем переход на 8.3.12, этим мы хотим закрыть вопрос с падением платформы на клиентах (порядка 2-3 тысяч дампов в день), а также попытаемся с помощью расширений не только исправлять дефекты, но и внедрять новый функционал.

  1. Зачастую проще оптимизировать нагрузку через создание индексов на уровне SQL, чем пытаться создать их средствами 1С или оптимизировать код. Напоминаю – так делать нельзя, так как это нарушение лицензионной политики 1С.
  2. Обязательно требуется замерять время обновления, так как несмотря на явный запрет разработчикам добавлять новые реквизиты в большие таблицы иногда всё-таки проскакивают изменения, требующие длительной реструктуризации.

 

 

Часть 2. Мониторинг.

Мониторинг мы разделяем на 3 части. 1-ый это стандартный ИТ-шный мониторинг, нагрузка на ЦПУ, занятое ОЗУ, диски, количество таймаутов и дедлоков в единицу времени и прочее-прочее, десятки их.

2 часть – доступность различных внешних ресурсов.

3 часть мониторинга — это бизнес-мониторинг, сюда мы относим:

  • Количество чеков в единицу времени.
  • Количество замен сим-карт в единицу времени.
  • Количество отправленных платежей в единицу времени.
  • Среднее время выполнения основных 7 операций.
  • Некоторые другие специфические параметры (например отношение ошибочных регистраций контракта к успешным, количество ошибочно подключенных услуг при биллинговых операциях и другие вещи, интересные только внутри компании).

Для сбора информации по 1 и 2 частям мониторинга мы используем конфигурацию «Центр контроля качества», через него же делаем рассылки про основные инциденты, такие как повышенная нагрузка на ЦПУ, появление дампов (падение служб rphost) и пр.

К первой части так же можно отнести сбор логов технологического журнала. Фактически это одно из основных средств для расследования проблем, а также источник данных для сбора части показателей (количество TTimeout и TDeadlock, таймауты и дедлоки на управляемых блокировках, зависание rphost (тут всё достаточно тонко, если будет нужно расскажу дополнительно), среднее (AVG) и общее (SUM) время вызова (CALL и SCALL). Вообще технологический журнал позволяет собирать огромное количество полезной информации, главное научиться парсить многогигабайтные текстовые файлы. У нас за это отвечает отдельный сервис на C#.

3 часть. Обычно в этой части принято считать apdex, как некий сводный показатель производительности системы, однако мы пришли к выводу что для нас наглядней смотреть просто на среднее время выполнения ключевых операций. Замеры выполняются стандартными средствами 1С и пишутся в регистр сведений, откуда уже читаются прямыми запросами и выводятся в дашборд. Сначала мы пытались изобрести велосипед в части дашбордов, но потом остановились на Grafana. Вот так выглядит график среднего времени выполнения операций за 1 день.

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

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

94

См. также

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. mifka186 6 02.07.18 17:01 Сейчас в теме
Все пользователи работают в единой базе?
Подключение к базе напрямую или по РДП?
Есть ли мониторинг того, что какой-то магазин не работает в системе (на точке нет интернета и тп)?
Alexander87; +1 Ответить
5. Repich 170 02.07.18 22:52 Сейчас в теме
(1) Да, все пользователи работают в одной базе.
Нет, RDP нет, тонкий клиент везде.
Мониторинг есть у сетевиков, то есть они видят, что канал пропал до точки. Мониторинга работоспособности 1С нет, хотя в целом сделать его не сложно, я уже думал об этом. Вопрос, что делать, если мы видим, что точка, которая с точки зрения мониторинга должна работать - не работает. Звонить выяснять, в чем дело? К сожалению ресурсов у нас не так много и свободных на текущий момент нет, хотя в целом, если предложить бизнесу идею - возможно он и готов будет оплатить.
75. buganov 49 05.07.18 11:16 Сейчас в теме
(5) почему не сделать на точках отдельные экземпляры базы и обменом сливать все в центральную?
76. Armando 1387 05.07.18 11:18 Сейчас в теме
2. genayo 02.07.18 17:12 Сейчас в теме
Вы работаете напрямую с вендором, как Деловые Линии, например?
6. Repich 170 02.07.18 22:53 Сейчас в теме
(2) Вы про 1С? Естественно у нас есть РКЛ, кроме того сейчас есть действующий договор с ЦКТП.
7. genayo 02.07.18 22:56 Сейчас в теме
9. Repich 170 02.07.18 23:00 Сейчас в теме
(7) КОРП конечно, мы полностью белые, а на обычные лицензии огромное количество ограничений, хотя они и просто лицензионные, а не программные.
12. genayo 03.07.18 06:54 Сейчас в теме
(9) Спасибо. Если можно, расскажите про КОРП лицензии, что реально дают на практике, чем лучше обычных, насколько качественнее и быстрее техподдержка для КОРП...
Dmitri93; pbabincev; A_Max; +3 Ответить
40. Repich 170 03.07.18 19:45 Сейчас в теме
(12)
Проще всего почитать на ИТС.
46. genayo 03.07.18 19:58 Сейчас в теме
(40) Там про практический опыт нет ничего, интересно, что из перечисленного там используется и как используется.
50. Repich 170 03.07.18 23:16 Сейчас в теме
(46)
Самое главное - возможность разделить требования назначения функциональности по разным серверам. Это видно на схеме, специально её привел.
Второе - техподдержка от партнёра франчайзи, но здесь главное что мы нашли правильного франча, а в самом франче - грамотного специалиста. Не всем так везет )
90. chng 20.07.18 17:36 Сейчас в теме
(50)
Самое главное - возможность разделить требования назначения функциональности по разным серверам

И фактически единственное полезное отличие.
Грамотный партнер и специалист у него к КОРП лицензиям отношения не имеет.
3. pbabincev 98 02.07.18 18:21 Сейчас в теме
Очень круто.
Но теперь надо подробнее.

Какое железо, какие хранилища данных.
Какая конфа.
Как ведете разработку, сколько разработчиков, аналитиков. Как тестируете.
Что за проблема с падением платформы на клиентах.
zaharknyaz; Alexander87; Evil Beaver; acanta; +4 Ответить
8. Repich 170 02.07.18 22:58 Сейчас в теме
(3)
Конфа - УТ 11, естественно переписанная вдоль и поперек.
Падение платформы - если вкратце - иногда при пробитии чека по эквайрингу падает платформа, в итоге имеем списанные у клиента деньги и не пробитый чек.
По железу, разработке и тестированию постараюсь ответить отдельной статьей. В двух словах не опишешь.
91. igo1 237 29.08.18 11:20 Сейчас в теме
(8) Есть решение такой проблемы, перед пробитием чека писать в текстовый документ данные, потом при старте проверять успешно закрылся чек или нет, если нет то погружать в БД.

такой лог спасал нас при работе не только на 1с.
4. Evil Beaver 5369 02.07.18 22:07 Сейчас в теме
Тема крайне интереса, здесь есть о чем поговорить и в плане обмена опытом и в плане похоливарить. Эксплуатация больших систем на 1С - тема плохо освещенная, к сожалению. Пишите еще.

Для затравки: у меня, например, многомашинный кластер привносил проблем больше чем пользы (версия 8.3.10), но была возможность нарастить вертикально - в рамках одной машины. Стабилизировать его в приемлемом качестве так и не удалось... В остальном похоже было, отчетность у вас круче, а с обновлением мы экспериментировали, делали автодеплой с фоновой реструктуризацией ради минимального простоя при частых обновлениях - даже работало :)
10. Repich 170 02.07.18 23:04 Сейчас в теме
(4)
Как раз 1С-овский кластер на текущий момент наиболее устойчивая и менее всего беспокоящая меня тема. Сейчас самое большое это невозможность распараллелить SQL и кривые руки разрабов, которые двумя строками говнокода убивают недели, затраченные на оптимизацию. Конечно эти две строки кода несложно исправить, но ведь их сначала надо найти. В общем стандартная война разработки и эксплуатации.
11. PerlAmutor 33 03.07.18 06:30 Сейчас в теме
(10) Как боретесь с зависшими сеансами, утечками памяти? Каким образом чистите сеансовые данные после обновления конфигурации? Нет ли превышения времени ожидания предоставления блокировок при таком количество пользователей?
15. Repich 170 03.07.18 07:48 Сейчас в теме
(11)
Зависшие сеансы это что? Клиентские сеансы? Я что то с таким не сталкивался, можно поподробней, как это выглядит?
Утечки памяти - перезапуск rphost при превышении предельного размера, но происходит это не часто. Дело в том, что у нас вся отчетность вынесена во внешнюю систему, в 1С можно строить отчеты, не превышающие при выводе 10 тысяч строк.
Сеансовые данные чищу ручками. Остановил все службы, удалил файлы. Можно скрипт конечно написать, руки никак не дойдут.
Превышение времени ожидания редко, но бывают. Примерно 1-2 раза в день. На это стоит отдельный счетчик, который сразу начинает верещать. Таймауты не связаны с кодом конфигурации, варианты, которые у нас были:
1. Пользователь запустил два сеанса и пытался одновременно в них провести один и тот же документ (там не пользователь, а робот был на самом деле). Научили его так не делать.
2. Слишком длительное обслуживание индексов. Оптимизировали скрипты и отключили обслуживание тех индексов, которые по нашему мнению не нужны.
3. Какая то проблема в SQL, в результате чего при автообновлении статистики таблица блокировалась зачастую на несколько минут. Отключили автообновление статистик в течение дня, только по ночам.
25. PerlAmutor 33 03.07.18 09:20 Сейчас в теме
(15)
Зависшие сеансы это что? Клиентские сеансы? Я что то с таким не сталкивался, можно поподробней, как это выглядит?

И сеансы и соединения. Например при отборе по ЖР, когда в качестве отбора указывается конкретная ссылка на объект ИС. ЖР зависает намертво, иногда настолько, что снятие сессии не обрывает соединение. В итоге невозможно обновить конфигурацию, даже если пытаться удалить соединение вручную, оно якобы удаляется и тут же появляется снова. Помогает только перезапуск rphost'ов.
После перезапуска rphost'ов по превышению размера потребляемой ОЗУ появляются сессии-фантомы. Пользователь выключил компьютер не дождавшись выхода из 1С, например программист 1С выключил компьютер будучи находившись в конфигураторе. После перезапуска rphost'ов его фантомная сессия восстанавливается и висит в консоли наряду с еще 50 фантомными сессиями.

(15)
Сеансовые данные чищу ручками. Остановил все службы, удалил файлы.

Наши администраторы не дают прямого доступа к серверу. Максимум что доступно - консоль администрирования 1С.
28. Evil Beaver 5369 03.07.18 11:55 Сейчас в теме
(15) Чудны дела, твои.... зависшие фоновые задания, сеансы и/или блокировки - известный бич, все его знают и в случае глюков сервера - чистят сеансовые данные. А вы говорите "не сталкивался". Поделитесь опытом, чтоль - как так пролучается у вас?
uri1978; barm; +2 Ответить
35. pbabincev 98 03.07.18 14:05 Сейчас в теме
(28)
Коллега, как вы чистите сеансовые данные?
36. Evil Beaver 5369 03.07.18 16:28 Сейчас в теме
(35) стоп сервера, очистка каталога сеансовых данных, старт сервера. В многомашинной среде - стоп всех машин, чистка всех каталогов, старт всех машин.
45. Repich 170 03.07.18 19:56 Сейчас в теме
(28)
Тут я пожалуй этот вопрос в отдельную статью выделю.
94. nvv1970 07.09.18 23:58 Сейчас в теме
(15) low priority locks - используете?
13. Art1387 4 03.07.18 07:08 Сейчас в теме
(10)Почему бы не нанять пряморуких разрабов? Или направить на курсы для 1с эксперта? Для контроля можно попросит сдать профа по технологическим вопросам. Думаю понимания и косяков будет меньше.
14. Repich 170 03.07.18 07:40 Сейчас в теме
(13) Ну про криворуких я конечно немного утрирую, в основном нормальные разработчики, просто они не думают большими масштабами. Простой пример - при проведении документа разработчик два раза передает контекст формы на сервер, оптимизировав и заменив только на 1 вызов мы серьезно улучшили производительность в дальних регионах, так как пинг там совсем не веселый и такая простая процедура, как передача контекста начинает занимать уже приличное время.
Второй пример - увлеченность разработчиками временными таблицами. Их привычка пихать их к месту и не к месту привела к тому, что у нас SQL начал проваливаться именно по этому показателю.
LordKim; systemevil; Sergey.Noskov; Armando; Evil Beaver; +5 Ответить
16. ladon 03.07.18 08:12 Сейчас в теме
(14)
Ну про криворуких я конечно немного утрирую, в основном нормальные разработчики, просто они не думают большими масштабами. Простой пример - при проведении документа разработчик два раза передает контекст формы на сервер, оптимизировав и заменив только на 1 вызов мы серьезно улучшили производительность в дальних регионах, так как пинг там совсем не веселый и такая простая процедура, как передача контекста начинает занимать уже приличное время.
Второй пример - увлеченность разработчиками временными таблицами. Их привычка пихать их к месту и не к месту привела к тому, что у нас SQL начал проваливаться именно по этому показателю.

Так ведь это и должно решаться техническим контролем выкладываемых изменений в рабочую базу. Если команда небольшая, достаточно одного специально обученного человека, и будет счастье.
18. pbabincev 98 03.07.18 08:51 Сейчас в теме
(16)
должно решаться техническим контролем выкладываемых изменений

Скажите пожалуйста, что должен включать в себя "технический контроль"?
Сотрудник, проводящий контроль релиза, должен проанализировать выполнение кода и спрогнозировать его неоптимальное использование?
Dem1urg; Evil Beaver; +2 Ответить
19. ladon 03.07.18 09:01 Сейчас в теме
(18)
Скажите пожалуйста, что должен включать в себя "технический контроль"?
Сотрудник, проводящий контроль релиза, должен проанализировать выполнение кода и спрогнозировать его неоптимальное использование?

Да. Часть проблем видно уже при просмотре кода (излишнее количество виртуальных таблиц, да и лишние вызовы сервера тоже могут быть замечены).
А то, что нельзя увидеть при беглом просмотре, можно отследить на этапе тестирования.
pbabincev; +1 Ответить
21. pbabincev 98 03.07.18 09:10 Сейчас в теме
(19)
"то, что нельзя увидеть при беглом просмотре, можно отследить на этапе тестирования"
Как можно отследить излишнее количество виртуальных таблиц на этапе тестирования?
24. ladon 03.07.18 09:18 Сейчас в теме
(21)
Как можно отследить излишнее количество виртуальных таблиц на этапе тестирования?

Конкретно этот момент можно увидеть ещё при беглом анализе кода. Когда запрос содержит большое количество виртуальных таблиц, можно на него обратить внимание.
Не нравится такой подход - можно при тестировании обращать внимание на время выполнения операций.
Можно отслеживать замеры производительности.
pbabincev; +1 Ответить
29. TODD22 17 03.07.18 11:58 Сейчас в теме
(21)
Как можно отследить излишнее количество виртуальных таблиц на этапе тестирования?

Виртуальных или временных?
33. pbabincev 98 03.07.18 12:36 Сейчас в теме
(29)
Да, тут в ветке идет обсуждение не виртуальных, а временных таблиц.
77. buganov 49 05.07.18 12:39 Сейчас в теме
(19) чем Вам виртуальные таблицы не угодили? Или все-таки временные?
83. ladon 05.07.18 15:48 Сейчас в теме
(77)
чем Вам виртуальные таблицы не угодили? Или все-таки временные?

Конечно же, временные. :)
30. Evil Beaver 5369 03.07.18 11:59 Сейчас в теме
(16) О да, мы пробовали выделять человека. Он взвыл через неделю. Выделили другого - продержался не сильно дольше. Пробовали проверять друг за другом по очереди или по просьбе - поехало, хотя и со скрипом. Ревью кода - нудная вещь, выжимает соки.
31. Armando 1387 03.07.18 12:19 Сейчас в теме
(30)
мы пробовали выделять человека. Он взвыл через неделю. Выделили другого - продержался не сильно дольше

Можно чуть подробней? Что конкретно изматывает?
Я делаю ревью, правда постфактум. Запускаю конфигуратор: Конфигурация - Хранилище - Обновить конфигурацию из хранилища.
Затем Конфигурация - Сравнить конфигурации. 1. Конфигурация базы данных, 2. Основная конфигурация. В диалоге сравнения анализирую внесенные изменения с момента последней проверки. Потом жму F7. На следующий день всё заново. Занимает не болше часа в день.
paybaseme; LordKim; +2 Ответить
34. pbabincev 98 03.07.18 12:38 Сейчас в теме
(31)
базы данных, 2. Основная конфигурация. В диалоге сравнения анализирую внесенные изменения с момента последне

Я тоже так делаю.
Но считаю что это малоэффективно, да и времени на это постоянно не хватает, из-за чего детально анализирую только код тех разработчиков, которые по моему мнению не имеют достаточно высокого уровня, чтобы писать оптимально. По крайней мере явные проблемы у ведущих зубров наблюдаются исключительно редко.
37. Evil Beaver 5369 03.07.18 16:34 Сейчас в теме
(31) Мы использовали git + atlassian crucible. Если бы мы заставляли смотреть код в Конфигураторе через "Сравнение" - у нас бы случаи самоубийств начались. А если замечание возникло - ногами идти к человеку и выдергивать из контекста?

В Crucible к строке кода можно оставить комментарий, автору строки придет письмо. Тут же из коробки переход к таск-трекеру, чтобы посмотреть, а что за задача решалась, и т.д.

Выматывало именно то, что нужно находиться в контексте решаемой задачи, при просмотре ее кода. Когда людей хватало - это решалось внутри команды и было хорошо. Потом кризисы-шмизисы, людей, способных анализировать код, стало меньше, а задач на них - стало больше. Ревью превратился в обузу и заглох.
o.nikolaev; +1 Ответить
32. ladon 03.07.18 12:24 Сейчас в теме
(30)
О да, мы пробовали выделять человека. Он взвыл через неделю. Выделили другого - продержался не сильно дольше. Пробовали проверять друг за другом по очереди или по просьбе - поехало, хотя и со скрипом. Ревью кода - нудная вещь, выжимает соки.

Человеку должно нравиться то, что он делает. Иначе от любой работы взвоет. Это бесспорно.
65. Sergey.Noskov 943 04.07.18 17:09 Сейчас в теме
(30)
Ревью кода - нудная вещь, выжимает соки.
О, да))
sergey.novikov; +1 Ответить
38. t.v.s. 88 03.07.18 18:07 Сейчас в теме
(4) К сожалению, фоновая реструктуризация и расширения не совместимы
17. pbabincev 98 03.07.18 08:41 Сейчас в теме
(0)

Расскажите, пожалуйста, еще:

Какой объем базы?
Сколько документов вводится в день?
По сколько записей в самых объемных таблицах? И какие это таблицы?
Как обслуживаете Журналы регистрации? В каком формате их используете (txt/sqlite)?
Каков размер индекса полнотекстового поиска?

Спасибо!


Повторю, тема очень интересная и проект реально крутой по объемам. Прямо очень интересно по-максимуму ознакомиться с опытом.

У меня на обслуживании РИБ. В одном только из узлов которой регистрируются по 5000 документов в день.
Естественно, мы порой встреваем в проблемы производительности. Объемы таблиц опять же не радуют. Сама база весит 500 Гб и растет довольно быстро.
Но пока всё еще руки не доходят "сделать нормально" с мониторингом и анализом ТЖ на текущие показатели. До кластера руки дошли вот только сейчас недавно, да и то - только после того, как сильно просели по производительности.
51. Repich 170 03.07.18 23:21 Сейчас в теме
(17)
Объем базы 2.6 Тб
Документов в день порядка 200 тысяч.
В самой объемной порядка 300 млн. Это самописный регистр сведений по состоянию сим-карт.
ЖР только для ошибок. Но для информации - первое, что делает любой специалист по оптимизации системы - включает старый формат журнала регистрации. Это уже обсуждалось тысячу раз. 1С никогда не признает официально, что ошиблась с sqlite. но это так.
Про индекс полнотекстового поиска не скажу, как то видимо не упирались в него, а может он отключен у нас, исследую вопрос.
53. Infactum 268 04.07.18 08:36 Сейчас в теме
(51) Что значит не признают проблему с sqlite?
Этот вопрос даже в профа по техническим вопросам включен помнится.
По дефолту старый формат не возвращают - это да.
58. Repich 170 04.07.18 14:59 Сейчас в теме
64. Armando 1387 04.07.18 15:19 Сейчас в теме
(53)
По дефолту старый формат не возвращают - это да.

При создании новой информационной базы в качестве формата по умолчанию используется последовательный формат журнала регистрации.
Источник: http://downloads.v8.1c.ru/content//Platform/8_3_12_1529/1cv8upd_8_3_12_1529.htm#b398b60e-9891-11e7-a3f7-0050569f678a
systemevil; +1 Ответить
71. Bonov 04.07.18 18:58 Сейчас в теме
(53) Уже вернули. В версии платформы 8.3.12 по умолчанию последовательный формат журнала регистрации.
20. morohon 03.07.18 09:08 Сейчас в теме
Добрый день.
Касательно долгой реструктуризации - не пробовали новый механизм? В настройке немного муторный и мало описанный в документации, но разработчики обещают ускорение в 4 раза в среднем.
https://wonderland.v8.1c.ru/blog/optimizatsiya-restrukturizatsii-bazy-dannykh/
systemevil; +1 Ответить
41. Repich 170 03.07.18 19:48 Сейчас в теме
(20)
Это одна из основных причин перехода на 8.3.12 (сейчас мы на 8.3.10), прямо сейчас уже разливается на точки новый движок, надеюсь перейти в течение 1-2 недель, обязательно попробуем.
47. morohon 03.07.18 20:18 Сейчас в теме
(41) не могли бы отписаться о результатах по возможности? Настроить получилось, но протестировать в реальной среде не получилось. Интересны результаты на крупных данных
22. morohon 03.07.18 09:11 Сейчас в теме
На курсах по Эксперту рассказывали про проблемы производительности из-за репликации сеансовых данных на нескольких серверах. Самому с крупными клиентами работать не приходится, поэтому хотел бы уточнить у Вас - сталкивались ли Вы с какими-либо проблемами производительности из-за репликации сервисов кластера?
42. Repich 170 03.07.18 19:49 Сейчас в теме
(22)
У нас отказоустойчивость в 0 установлена, к сожалению на текущем движке (8.3.10) есть критический дефект, не позволяющий на нашей площадке включить отказоустойчивость.
Evil Beaver; +1 Ответить
48. morohon 03.07.18 20:21 Сейчас в теме
(42) хм, понял. Довольно инетересно. Спасибо за ответ.

А можете в кратце написать про критический дефект? Или ссылку на багбоард?
59. Repich 170 04.07.18 15:00 Сейчас в теме
(48)
К сожалению он не опубликован на bugboard, так что не могу.
52. Evil Beaver 5369 04.07.18 08:08 Сейчас в теме
(42) и почти в каждой версии тот или иной дефект, а еще 8.4 с zookeeper как-то замерзла и не едет..
23. morohon 03.07.18 09:15 Сейчас в теме
Также вопрос - вы постоянно мониторите данные технологическим журналом? (ЦКК) Если да, то не сказывается это на производительности? При таком количестве пользователей событий CALL и SCALL будет невероятно много и какую-никакую загрузку это будет давать.
43. Repich 170 03.07.18 19:53 Сейчас в теме
(23)
Что вы, упаси господи, ЦКК к большому ТЖ подпускать нельзя ни в коем случае. ТЖ анализируется с помощью самописных механизмов на C#, затем в ЦКК загружаются в виде внешних счетчиков.
А так да, ТЖ собирается постоянно, проблем никаких нет, это прямая рекомендация от 1С - чтобы ТЖ работал непрерывно. Естественно пишется на отдельные диски, не на СХД, где находится база данных.
26. comol 3704 03.07.18 11:06 Сейчас в теме
А немного отвлеченный вопрос - почему централизованное решение? Я правильно понял что розница с торговыми точками? На всех торговых точках есть дублированный канал интернет и нужное сетевое оборудование?
44. Repich 170 03.07.18 19:55 Сейчас в теме
(26)
Мы с шефом уже участвовали в похожем проекте и предыдущее решение было сделано распределенным. Опыт показал, что централизованное решение в нашей ситуации будет проще в поддержке и более "вкусно" для бизнеса.
Да, это розница с магазинами.
На всех торговых точках есть дублированный интернет канал, так как специфика работы такова, что без связи работа магазина невозможна.
systemevil; o.nikolaev; +2 Ответить
80. FIGOR 05.07.18 15:02 Сейчас в теме
(44)
А от скорости каналов сильно зависите? Какова минимальная скорость канала для безпроблемной работы кассы в удаленной точке длительное время?
82. Repich 170 05.07.18 15:28 Сейчас в теме
(80)
Зависим скорее не от скорости канала, а от стабильности пинга и скорости света. На ДВ конечно операции выполняются немного медленней, чем в Москве. Примерно процентов на 30-50.
Сейчас у нас в регламентах прописано 4 Мбит, но это не только для 1С, для всего. Аварийный канал установили в 1 Мб. Для 1С в принципе достаточно будет и 512 Кбит.
LordKim; systemevil; +2 Ответить
27. serrembo 03.07.18 11:31 Сейчас в теме
(0) Интересно было почитать
39. headMade 140 03.07.18 19:31 Сейчас в теме
зависание rphost (тут всё достаточно тонко, если будет нужно расскажу дополнительно)

Можно поподробнее.
49. Repich 170 03.07.18 23:02 Сейчас в теме
(39)
Описал чуть подробней в отдельной статье, пример №3.
54. ZOMI 106 04.07.18 09:19 Сейчас в теме
Подобная архитектура просуществует до первого глобального сбоя или до череды инцидентов приводящих к простоям. Таков мой прогноз.

Хотелось бы, конечно, узнать название компании?
Какой штат 1С-ников?
55. pbabincev 98 04.07.18 09:26 Сейчас в теме
(54)
Подобная архитектура просуществует до первого глобального сбоя или до череды инцидентов приводящих к простоям. Таков мой прогноз.

А какую Вы могли бы предложить альтернативу?
56. ZOMI 106 04.07.18 10:02 Сейчас в теме
(55) Например (есть и др. варианты):

Розницу(разумеется переделанную под свои особенности) разворачиваем на точках(файловый вариант).

Делаем базу-шлюз(серверный вариант)( ведем там НСИ также) на которую, как на елку, навешиваем web-сервисы для обменов через json, например.

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

Актуальные розничные цены держим в базе-шлюзе забирая актуальные из ЦБ.

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


В базе-шлюзе держим инфу о версиях клиентов и инициируем обновления при необходимости.

Много, конечно нюансов, но сбой базы-шлюза или ЦБ никаким образом не отражается на клиентах (точках).
MeCrazyJunkie; +1 Ответить
57. Armando 1387 04.07.18 10:25 Сейчас в теме
(56) Это еще спорный вопрос, что лучше: пасти весь этот зоопарк с обменами или вовремя предотвращать инциденты.
LordKim; Дмитрий74Чел; +2 Ответить
61. Repich 170 04.07.18 15:03 Сейчас в теме
(57)
Мы пасли такой зоопарк на предыдущем месте работы, тоже около 2 тысяч магазинов. Обмены это была боль. Поэтому решили на текущем проекте эту боль избежать. Пока ни о чем не жалеем )
60. Repich 170 04.07.18 15:02 Сейчас в теме
(54)
Ну мы уже 3 года работаем. Что вы подразумеваете под глобальным сбоем?
Штат 1С-ников, 6 аналитиков, 12 разработчиков, 8 человек поддержка 2 линии, 22 человека поддержка 1 линии.
62. AlexZhukov 04.07.18 15:04 Сейчас в теме
(60) Олег, а ты в Цифрограде не работал?
70. Repich 170 04.07.18 18:20 Сейчас в теме
63. genayo 04.07.18 15:19 Сейчас в теме
(54) На самом деле тут считать надо, оба варианта имеют право на жизнь, вопрос бюджета...
66. Sergey.Noskov 943 04.07.18 17:25 Сейчас в теме
Ура! Крупные системы потихоньку начинают делиться опытом. Очень надеюсь, что будут последователи.
Олег, почему отказались от апдекса и перешли на среднее время? По идее апдекс более чувствителен к изменению времени операции.
67. Repich 170 04.07.18 17:36 Сейчас в теме
(66)
Давайте тут тоже отдельной статьей отвечу.
68. Sergey.Noskov 943 04.07.18 18:01 Сейчас в теме
Синхронная реплика AlwaysOn не доставляет хлопот?
Мы оставили только асинхронную из-за рисков увеличить время транзакции в основном узле.
69. Repich 170 04.07.18 18:18 Сейчас в теме
95. nvv1970 08.09.18 21:14 Сейчас в теме
(69) можете подробнее рассказать о схеме физических серверов?
Как между собой пересекаются WSFC+AG SQL и 1C-кластер? Это везде физически разные сервера? Или есть пересечения?
Хотелось бы для себя прояснить возможно ли вообще такое "пересечение", если у AG должно быть общее виртуальное имя, а у серверов 1С адреса должны быть разные.
98. Repich 170 10.09.18 15:40 Сейчас в теме
(95) К сожалению у меня нет ответа на ваш вопрос, я его даже не понял, что такое AG, WSFC и пр.
99. nvv1970 10.09.18 16:05 Сейчас в теме
(98) AG - availability groups (группы доступности), WSFC - Windows Server Failover Cluster.

Например, если взять два сервера, настроить failover, alwayson (например, с синхронной репликой). Они будут иметь одно имя подключения.
Теперь, например, на эти же сервера поставить два центральных 1с сервера.

Имеет место такое быть у вас? Или 1с и SQL у вас не встречаются на одном сервере? Или все исключительно на разных?

Проконсультируйте про мой пример: серверы 1с сохраняют свои уникальные имена? Они никак не пересекаются с SQL-ной отказоустойчивостью и не мешают друг другу? Или могу возникнуть вопросы?
100. Repich 170 10.09.18 20:57 Сейчас в теме
(99) Сервера 1С и SQL разнесены на физически разные машины. Серверы 1С каждый имеют свое уникальное имя, два из них центральные (по одному на ЦОД), отказоустойчивость выключена, остальные - соответственно не центральные. Всего app серверов на текущий момент 5. В ближайшее время будет выделен сервер лицензирования, пока он расположен на одном из центральных серверов, это самое узкое место, которое фактически сводит отказоустойчивость на нет.
SQL состоит из 4 машин, два в режиме Synchronous commit, еще два - Asynchronous commit. Первые две машины имеют единое кластерное имя, на которое откликается тот из серверов, который в данный момент является активной нодой.
101. nvv1970 11.09.18 09:31 Сейчас в теме
(100)
SQL состоит из 4 машин, два в режиме Synchronous commit, еще два - Asynchronous commit. Первые две машины имеют единое кластерное имя, на которое откликается тот из серверов, который в данный момент является активной нодой.
Из описаний в интернете и примеров применения технологии так и не понял: синхронные и асинхронные реплики распределяют между собой нагрузку? Балансировка между ними есть? Или только первичная нода все тянет, а вторичная - резерв для мгновенного переключения?
102. Repich 170 11.09.18 17:17 Сейчас в теме
(101) Распределения нагрузки нет, всё тянет первичная нода, вторичная - резерв.
Теоретически на асинхронные реплики можно посадить пользователей, которые только читают данные, но 1С к ней подключить без грязных хаков не получится, так как база read only, а 1С хочет писать во временные таблицы.
103. nvv1970 11.09.18 21:08 Сейчас в теме
(102) спасибо за ответ.
Про асинхронные реплики наслышан. Как к ним обращаться - в теме.
Про синхронные - грусть(.
72. OerlandHue 05.07.18 04:08 Сейчас в теме
Сеансовые данные это так называемый кэш сервера 1С? Находится в папке srvinfo?
74. Repich 170 05.07.18 08:32 Сейчас в теме
(72)
Да.
https ://its.1c.ru/db /metod8dev#content:5860:hdoc
78. buganov 49 05.07.18 12:46 Сейчас в теме
По поводу долгой реструктуризации огромных таблиц. Есть один финт, который позволит провернуть ее намного быстрее, но работает только при добавлении нового реквизита. На SQL реструктуризируемая таблица переименовывается, создается пустая с новым реквизитом и запускается реструктуризация. Т.к. данных нет, все происходит в считанные секунды, правда, потом средствами SQL необходимо перегнать данные из старой таблицы в новую. Сильное читерство, но иногда спасает, когда без вариантов.
79. FIGOR 05.07.18 14:49 Сейчас в теме
В свете разговоров по оптимизации запросов вопрос. Никто не пробовал написать оптимизатор запросов? Если бы такой продукт появился, вы бы его приобрели?
81. headMade 140 05.07.18 15:09 Сейчас в теме
84. aspirator23 371 07.07.18 14:21 Сейчас в теме
И все про себя подумали, но постеснялись спросить: Уж не Магнит ли это? -:)
86. genayo 07.07.18 17:38 Сейчас в теме
(84) Магнит симкартами торгует? Не знал...
93. Sиlьver 5 30.08.18 12:41 Сейчас в теме
(84) Возможно это Билайн. Как раз 3 года назад они людей набирали на проект внедрения розницы на 3 тыс магазинов и все должно было быть в единой базе.
96. Fox-trot 91 08.09.18 23:10 Сейчас в теме
(93) угадал :)
Прикрепленные файлы:
97. Repich 170 10.09.18 15:36 Сейчас в теме
(96) Приезжайте на конференцию. Еще и вживую увидите )
85. alex_sh2008 5 07.07.18 14:30 Сейчас в теме
(0)С какой пропускной способностью стоит сетевой пул между SQL серверами и серверами 1С и между серверами 1С и клиентами, 100Гб/с?
87. Repich 170 08.07.18 14:09 Сейчас в теме
Оставьте свое сообщение