Опыт оптимизации и контроля производительности в БД с 3000 пользователей

04.03.16

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта IE 2014 29-31 октября 2014 года. Меня зовут Сергей, являюсь руководителем отдела оптимизации и производительности систем в компании "Деловые линии". Цель этого доклада – поделиться информацией о нашем опыте работы с большой базой на платформе 1С, с чем пришлось столкнуться, как удалось обеспечить работоспособность. Уверен, что вам будет интересно, так как подобной информацией мало кто делится, да и про само существование таких систем их владельцы стараются не рассказывать, максимум про это «краем глаза» упоминают участвовавшие в проекте вендоры. **update от 04.03.2016 по вопросам из комментариев

Текущее состояние автоматизируемой системы

Для начала - несколько слов о системе и нагрузке на неё (*по состоянию на сентябрь 2014):

База – самописная.
Платформа – 8.2.

На текущий момент у нас в базе работает более 3000 пользователей. На слайде - количество работающих пользователей с учетом COM- и веб-соединений:

Консоль кластера

Суммарно за сутки записывается порядка миллиона объектов ссылочного типа. Из них:
- 700 тысяч – это документы (перепроведение существующих и запись новых).
- 300 тысяч – это справочники (также модификация существующих и запись новых).

Количество формирований отчетов в сутки составляет порядка 250 тысяч. Это многочисленные оперативные и аналитические отчеты.
Суммарная длительность запросов, выполняемых пользователями в базе за сутки, превышает 330 тысяч секунд (92 часа) – достаточно интенсивная нагрузка.

При этом компания продолжает развиваться, открываются новые подразделения, привлекаются новые сотрудники, новые клиенты.

Есть постоянная потребность по разработке и внедрению новых подсистем, по автоматизации бизнес процессов, по решению различных интеграционных вопросов.

Поэтому у нас и большой отдел разработки - более 40 человек программистов, а также аналитики, тестировщики, архитекторы, эксперты. В общей сложности более 100 человек.

Процесс оптимизации. Начало.

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

Начальные условия:

Платформа 8.1
Число пользователей в базе: 1000
Режим блокировок: атоматические
APDEX - отсутствует
Нагрузка ЦПУ сервера СУБД достигает 98%
Постоянные жалобы пользователей на "подвисания"
Количество разработчиков: 10
Обновления конфигурации БД: еженедельно

Основная задача, которую надо было решить – снизить загрузку CPU сервера SQL и обеспечить принципиальную работоспособность. Решали её разными способами, начиная с самого легкого – upgrade железа. Пока было куда "апгрэйдить" это помогало. Когда и топовое железо перестало помогать, тогда и началась оптимизация.

Что сделали на первом этапе:

Разработали план регламентных работ по перестроению и дефрагментации индексов.
Установили ЦУП и принялись за оптимизацию запросов.
Перешли на управляемые блокировки.
Внедрили APDEX (на мой взгляд – это обязательная штука, если, конечно, вы хотите знать что происходит с вашей базой).

На первое место в статистике ЦУПа вышли запросы обновления форм списков пары основных документов и справочника Контрагентов. Переделали их на формы поиска.
Основная суть – статичный список формируемый запросом (ПостроительОтчета), на форме блок предустановленных фильтров. Пользователь указывает отборы, жмет «Найти» и получает нужные данные. Это позволяет контролировать обязательные для заполнения поля поиска, избавиться от запросов при обновлении формы и скроллинге, а так же ограничить объем выводимой информации. Например, если мы хотим выводить не более 100 элементов, пишем в запросе "выбрать первые 101" и если запрос возвращает ровно 101 элемент, то пользователя просят уточнить отборы.

Конечно запросы из форм списков были не единственными, мы переписали досточно много запросов, а где то и архитектуру. Эта работа дала результат. Раньше, например, нагрузка на систему в понедельник и пятницу могла быть настолько высока, что приходилось отпускать домой некоторые отделы (менеджеров, колл-центр). А в результате проведенной оптимизации получилось снизить нагрузку в пятницу – проблем больше не было. Да и в понедельник мы тоже, со скрипом, но работали.

Второй этап оптимизации. "Разделяй и властвуй"

Тем не менее, мы прекрасно понимали, что расслабляться нельзя, надо действовать дальше, потому что количество пользователей к тому моменту опять выросло: их стало почти 2000. Штат разработчиков вырос до 20 человек, функционал наращивался очень быстро. И здесь нам помог случай и неудачный переход на 8.2 (8.2.13). Про переход на 8.2 можно многое рассказать, но так как тот опыт удачным не был, отмечу основную ошибку - не был проведен полноценный нагрузочный тест на 2000 рабочих мест.

Итак, не впадая в историзмы, у нас развивался свой сайт и от него поступал достаточно большой трафик запросов, которые "стучались" в боевую базу. Но эти запросы не требовали он-лайн данных и могли бы, например, подключаться к копии с актуальностью минус сутки. И у нас была подсистема репликации на планах обмена, которая разрабатывалась специально для перехода на 8.2 (на случай отката с 8.2 обратно на 8.1). Эта подсистема, используя план обмена, позволяет поддерживать в актуальном состоянии копию рабочей базы. Вот в эту копию мы и перенаправили часть соединений вэб сервисов. И заметили снижение нагрузки. Да, было понятно, что нагрузка должна несколько снизиться, но мы не рассчитывали, что ее падение будет настолько существенным. Сами запросы от сайта были достаточно маленькие, просто их поток был очень большим.

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

Провели пару экспериментов, убедились, что и результат запроса и табличный документы отлично сериализуются. В табличном документе, переданном по COM посредством сериализации/десериализации, работают даже расшифровки.
Разработали шаблон отчета, который позволяет передавать настройки отчета и получать его результат по СОМ соединению.
Улучшили подсистему репликации и добились актуальности данных в 2 – 3 минуты, что значительно расширило список перенаправляемых отчетов. Доработки в основном были нужны потому, что стандартный метод "ВыбратьИзменения" планов обмена создает большое колличество блокировок.
Переписали кучу отчетов, приведя их к единому стандарту.

Так образом, хоть и с оговорками и условностями, мы разделили базу на OLAP и OLTP:

OLTP – это рабочая база, где вносят первичку.
OLAP –это база, где формируются отчеты и куда перенаправляются запросы веб-сервисов. Или, например, в эту базу можно зайти разработчику, чтобы протестировать какой-то отчет, как он будет себя вести в боевой системе.

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

Нагрузка на CPU в этот период достигала 98%. Так же обращаю внимание на не линейный рост нагрузки, грубо говоря, 20%+30%=100%.

Очередное развитие отчетная база получила, когда вышел SQL Server 2012 и появилась технология AlwaysOn, которая позволяет средствами самой СУБД создавать и поддерживать несколько копий БД в актуальном состоянии (теперь у нас задержки всего лишь несколько миллисекунд). Сама по себе технология позволяет отказаться от репликации средствами 1С, но переписывать отчеты все равно придется.

Разделение базы стало для нас очень большим прорывом, потому что у нашей системы появился запас прочности (а у нас появились выходные).

Этот запас прочности помог нам начать большой проект по переходу на 8.2 с поддержкой ЦКТП от 1С. В прошлом году (*декабрь 2013) этот проект был удачно завершен, и этой весной (*весна 2014) мы перешли на релиз 8.2.19.

О ЦКТП осталось положительное впечатление. Советую всем, у кого "большая база": если вы планируете перейти на другую платформу либо хотите понять что будет, например, при двух кратном увеличении числа пользователей – обращайтесь в 1С, в рамках проектов ЦКТП достаточно оперативно устраняются и ошибки платформы и выявляются "узкие" места БД.

Инструменты для мониторинга и обнаружения проблем производительности.

Основные инструменты у нас:

ЦУП;
PerfExpert от SoftPoint;
zabbix;
Статистика SQLServer.

Статистика SQL сервера.

Расскажу подробно про статистику SQL, мы её активно используем.

dm_exec_query_stats - статистика производительности для кэшированных планов запросов.

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

SELECT TOP 100

  db.name,
  SUBSTRING(text,(statement_start_offset/2)+1,
  ((CASE statement_end_offset
      WHEN -1 THEN DATALENGTH(text)
      ELSE statement_end_offset
      END - statement_start_offset)/2)+ 1) AS [Текст запроса],
  execution_count [Количество выполнений],
  total_elapsed_time/1000000 [Длительность, сек],
  total_worker_time/1000000 [Процессорное время, сек],
  total_logical_reads [Логических чтений],
  total_physical_reads [Физических чтений],
  qp.query_plan [XML план запроса]
  FROM sys.dm_exec_query_stats
  OUTER APPLY sys.dm_exec_sql_text(sql_handle) dm_text
  left join sys.databasesdb on dm_text.dbid = db.database_id
  OUTER APPLY sys.dm_exec_query_plan(plan_handle) AS qp
WHERE
  last_execution_time>=DATEADD(minute,-180,getdate())
ORDER BY
  total_worker_time DESC--сортировка по нагрузке на процессор
  --total_logical_reads DESC --сортировка по логическим чтениям
  --execution_count desc --сортировка по количеству выполнений

dm_exec_requests это второе часто используемое динамическое представление - сведения о выполняемых в текущий момент запросах.

SELECT
  db.name,
  a.session_id,
  a.blocking_session_id,
  a.transaction_id,
  a.cpu_time,
  a.reads,
  a.writes,
  a.logical_reads,
  a.start_time,
  a.[status],
  case a.transaction_isolation_level
      when 1 then'ReadUncomitted'
      when 2 then'ReadCommitted'
      when 3 then'Repeatable'
      when 4 then'Serializable'
      when 5 then'Snapshot'
  end УровеньИзоляции,
  a.wait_time,
  a.wait_type,
  a.last_wait_type,
  a.wait_resource,
  a.total_elapsed_time,
  st.text,
  qp.query_plan,
  p.loginame [loginame сессии вызвавшей блокировку],
  p.program_name [Приложение сессии вызвавшей блокировку],
  p.login_time [Время входа сессии вызвавшей блокировку],
  p.last_batch [Время последнего запроса сессии вызвавшей блокировку],
  p.hostname [Host Name сессии вызвавшей блокировку],
  stblock.text [Текущий(!) запрос сессии вызвавшей блокировку]
FROM sys.dm_exec_requests a
  OUTER APPLY sys.dm_exec_sql_text(a.sql_handle) AS st
  OUTER APPLY sys.dm_exec_query_plan(a.plan_handle) AS qp
  LEFT JOIN sys.sysprocesses p
  OUTER APPLY sys.dm_exec_sql_text(p.sql_handle) AS stblock
  on a.blocking_session_id > 0 and a.blocking_session_id = p.spid
  LEFT JOIN sys.databases db
  ON a.database_id = db.database_id
WHERE not a.status in('background','sleeping')
ORDER BY a.cpu_time DESC

Сейчас, для определения причин высокой нагрузки на процессор, нам в 90% случаев хватает именно этих двух запросов к динамическим представлениям.

На слайде - недавний случай:

Резкое повышение нагрузки в 9 утра – народ пришел на работу. Посмотрев статистику кэшированных запросов обратили внимание на лидера по количеству логических чтений и план этого запроса. Причина была в отсутствии статистик для индексов документа. Выполнив обновление статистик этого документа проблему достаточно оперативно устранили.

По динамическим представлениям есть один нюанс, связанный с не повторяемостью текстов запросов использующих временные таблицы. Например, три одинаковых запроса, отличающихся только именем временной таблицы:

Проблема не так мала, как может показаться.

Во-первых, это накладные расходы на сервер т.к. СУБД воспринимает их как разные запросы и для каждого будет заново строить план запроса.

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

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

dm_db_index_usage_stats, dm_db_missing_index_groups, dm_db_missing_index_group_stats - сведения об отсутствующих индексах и частоте использования существующих индексов.

Запрос, выводящий 10 самых востребованных из отсутствующих индексов по мнению SQL:

SELECT TOP 10
  [ИмяТаблицы] = OBJECT_NAME(sys_indexes.object_id),
  [ИздержкиОтсутствия] = ROUND(migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans),0),
  [СреднийПроцентВыигрыша] = migs.avg_user_impact,
  [Поиск] = migs.user_seeks,
  [Просмотр] = migs.user_scans,
  [Использование] = (migs.user_seeks + migs.user_scans),
  [ДатаПоследнегоПоиска] = ISNULL(migs.last_user_seek, CAST('1900-01-01 00:0:00' AS datetime)),
  [ДатаПоследнегоПросмотра] = ISNULL(migs.last_user_scan, CAST('1900-01-01 00:0:00' AS datetime)),
  [ЧислоКомпиляций] = migs.unique_compiles,
  [СредняяСтоимость] = migs.avg_total_user_cost,
  [ОсновныеПоляИндекса] = CASE
      WHEN sys_indexes.equality_columns IS NULL
      AND sys_indexes.inequality_columns IS NULL THEN ''
      WHEN sys_indexes.inequality_columns IS NULL THEN sys_indexes.equality_columns
      WHEN sys_indexes.equality_columns IS NULL THEN sys_indexes.inequality_columns
      ELSE sys_indexes.equality_columns + ', ' + sys_indexes.inequality_columns
      END,
  [ДополнительныеПоляИндекса] = ISNULL(sys_indexes.included_columns,'')
FROM sys.dm_db_missing_index_groups AS mig
  JOIN sys.dm_db_missing_index_group_stats AS migs
  ON migs.group_handle = mig.index_group_handle
  JOIN sys.dm_db_missing_index_details AS sys_indexes
  ON mig.index_handle = sys_indexes.index_handle
ORDER BY [ИздержкиОтсутствия] Desc

(!)Обращаю внимание, что эта информация носит рекомендательный характер и бездумное её применение может навредить системе. Например, если вы удумаете создать индекс напрямую в СУБД и той структуры, которую выводит статистика, то помимо нарушения лицензионного согласения с 1С вы можете столкнуться с блокировками. Второй момент, который надо обязательно знать, на одну и ту же конструкцию запроса SQL может "захотеть" несколько вариантов индекса и слепо следуя совету вы насоздаете много лишнего.

Запрос, отображающий статистику по существующим индексам:

SELECT TOP 100
  [КоэффициентЗаполнения] = sys_indexes.fill_factor,
  [ИмяТаблицы] = OBJECT_NAME(sys_indexes.object_id),
  [ИмяИндекса] = sys_indexes.name,
  [Поиск] = (ISNULL(user_seeks,0) + ISNULL(user_lookups,0)),
  [Просмотр] = ISNULL(user_scans,0),
  [Использование] = (ISNULL(user_seeks, 0) + ISNULL(user_scans, 0) + ISNULL(user_lookups, 0)),
  [Издержки] = (user_updates + system_updates),
  [КоэффициентИспользования] = CASE WHEN (user_updates + system_updates) = 0 THEN (ISNULL(user_seeks, 0) + ISNULL(user_scans, 0) + ISNULL(user_lookups, 0)) ELSE CAST((ISNULL(user_seeks, 0) + ISNULL(user_scans, 0) + ISNULL(user_lookups, 0)) AS NUMERIC(15,3))/CAST((user_updates + system_updates) AS NUMERIC(15,3)) END,
  [ДатаПоследнегоПоиска] = ISNULL(index_stats.last_user_seek , CAST('1900-01-01 00:0:00' AS datetime)),
  [ДатаПоследнегоПросмотра] = ISNULL(index_stats.last_user_scan , CAST('1900-01-01 00:0:00' AS datetime)),
  [ДатаПоследнегоПовторногоПоиска] = ISNULL(index_stats.last_user_lookup , CAST('1900-01-01 00:0:00' AS datetime)),
  [ДатаПоследнегоИспользования] = CASE WHEN ISNULL(index_stats.last_user_seek, CAST('1900-01-01 00:0:00' AS datetime)) >= ISNULL(index_stats.last_user_scan, CAST('1900-01-01 00:0:00' AS datetime)) THEN ISNULL(index_stats.last_user_seek, CAST('1900-01-01 00:0:00' AS datetime)) ELSE ISNULL(index_stats.last_user_scan, CAST('1900-01-01 00:0:00' AS datetime)) END,
  [ДатаПоследнегоUserОбновления] = ISNULL(index_stats.last_user_update , CAST('1900-01-01 00:0:00' AS datetime)),
  [ДатаПоследнегоСистемногоОбновления]= ISNULL(index_stats.last_system_update , CAST('1900-01-01 00:0:00' AS datetime)),
  [Фрагментация] = (sys_indexes_physical_stats.avg_fragmentation_in_percent),
  [РазмерИндекса] = (avg_record_size_in_bytes * record_count / 1024 / 1024),
  [КоличествоСтрок] = sys_indexes_physical_stats.record_count,
  [СреднийРазмерЗаписиБайт] = sys_indexes_physical_stats.avg_record_size_in_bytes,
  [СистемныйТипИндекса] = sys_indexes.type_desc,
  [ЧислоФрагментов] = sys_indexes_physical_stats.fragment_count,
  [ЧислоСтраниц] = sys_indexes_physical_stats.page_count,
  [ЗаполненностьСтраниц] = sys_indexes_physical_stats.avg_page_space_used_in_percent,
  [СреднееЧислоСтраницФрагмента] = sys_indexes_physical_stats.avg_fragment_size_in_pages
FROM
  sys.indexes AS sys_indexes
  LEFT JOIN sys.dm_db_index_usage_stats AS index_stats
  ON sys_indexes.object_id = index_stats.object_id
  AND sys_indexes.index_id = index_stats.index_id
  LEFT JOIN sys.dm_db_index_physical_stats(null, null, null, null, 'LIMITED') AS sys_indexes_physical_stats /*для отображения размера индекса и количества строк значение 'LIMITED' надо заменить на 'DETAILED', запрос будет выполняться дольше*/
  ON sys_indexes.object_id = sys_indexes_physical_stats.object_id
  AND sys_indexes.index_id = sys_indexes_physical_stats.index_id
  AND sys_indexes_physical_stats.index_level = 0
  AND sys_indexes_physical_stats.alloc_unit_type_desc = 'IN_ROW_DATA'
WHERE
  sys_indexes.name IS NOT NULL -- Ignore HEAP indexes
  AND OBJECTPROPERTY(sys_indexes.object_id, 'IsMsShipped') = 0
ORDER BY
  [Использование],
  [Издержки] DESC

С помощью него можно определить какие индексы не используются, какие используются редко и имеют высокие издержки содержания.

Для наглядности покажу на примере обработки, в которую сведена информация из обоих запросов:

В справочнике «Сотрудники» SQL "хочет" индекс по полю «Подразделение». Издержки отсутствия достаточно высокие, а значит было много запросов, при составлении плана выполнения которых, SQL искал подобный индекс. Этот индекс легко создать – достаточно в конфигураторе, у соответствующего реквизита, установить свойство «Индексировать».

Второй пример несколько сложнее. SQL нужен индекс, состоящий из 2 основных полей «ДокументОснование», «Работа». И трёх реквизитов в качестве дополнительных полей. При этом реквизиты «ДокументОснование» и «Работа» уже проиндексированы сами по себе (проиндексированные поля подсвечиваются зеленым), но нужен именно составной индекс. Создать штатно это индекс нельзя. Создать непосредственно в СУБД - нарушение лицензионного соглашения.

Позиция 1С достаточно проста – если вам нужен составной индекс, значит надо переписать или доработать архитектуру.

Мое мнение, есть множество ситуаций, когда составной индекс дешевле обходится системе вместо архитектурных нагромождений. Дешевле как с точки зрения потребления дискового пространства, оперативной памяти так и временем транзакции при записи. Поэтому, если уважаемые разработчики платформы прислушаются и предоставят подобную возможность - это будет очень здорово.

ЦУП.

Центр управления производительностью из Корпоративного Инструментального Пакета от 1С. Его многие знают или, как минимум, слышали про него.

Назначение - сбор данных о ресурсоемких запросах, блокировках и deadlock.

Источник данных - технологический журнал, для анализа дэдлоков ЦУП - трассировки СУБД.

С ЦУПа мы начали, используем его и сейчас. Правда его пришлось самого оптимизировать и выделить для него мощный сервер.

Недостатки:

ресурсоемкость запроса определяется только на основании времени его выполнения;
требует доработок;

Достоинства:

есть полный контекст выполнения.

PerfExpert.

Назначение - сбор данных о ресурсоемких запросах, блокировках и дедлоках; накопление и отображение данных о состоянии системы.

Источник данных - трассировки СУБД, Perfomance Monitor.

Основное отличие – статистика по запросам накапливается из трассировок к СУБД и делится на 2 категории – запросы с длительностью более 5 секунд и запросы с количеством чтений больше 50000. При этом тексты запросов группируются корректно и разные имена временных таблиц не мешают этому. Консолидирует и отображает информацию по большому количеству счетчиков Perfomance Monitor, так же есть возможность подключать в качестве счетчика прямой запрос к СУБД, что позволяет, например, выводить график APDEX.

Недостатки:

нет полного контекста выполнения;
нельзя купить лицензию на бессрочное использование.

Достоинства:

наглядное отображение текущего состояния системы;
подробная информация о нагрузке на СУБД.

Zabbix.

Назначение - накопление и отображение данных о состоянии системы; уведомление о превышении показателя пороговых значений.

Используется как универсальное средство для различного рода уведомлений и сигнализаций. Например о высокой нагрузке на CPU, о снижении АПДЕКСа. О состоянии важных бизнес процессов, например уведомление о превышении порогового количества электронных писем в очереди на отправку.

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

Этот материал я дополнил той информацией, которую планировал рассказать на конференции, но не успел.

Спасибо за внимание!

*Доклад не корректировался с учетом "временного сдвига", в частности информация о числе пользователей, количестве записываемых объектов и т.п. уже изменилась (в большую сторону).

UPDATE по вопросам из комментариев

Размер БД. На текущий момент файл данных > 5Тб

Железо. Тут не экономим. СХД - перешли не так давно на SSD ибо на наших объемах становится критична скорость регламентных операций СУБД, время реструктуризации. Все железо очень близко описано в конфигурации тестового стенда проекта по ЦКТП: http://v8.1c.ru/expert/cts/cts-218-001.htm

Кластер 1С. В кластере один центральный сервер и 3 дополнительных. Сервера не виртуальные. Из "особенностей" только то, что у центрального сервера нет rphost'ов. Резервирование кластера настраивали, получили проблемы и письмо от ЦКТП с просьбой не экспериментировать (цитата: "Прошу подтвердить, что больше эксперименты с отказоустойчивостью на рабочей базе на версии платформы 8.2 проводится НЕ будут", во как))).

Отказоустойчивость. У нас всегда есть две "горячих" копии базы - отчетная база, куда данные попадают по обмену через СОМ, и база - реплика средствами AlwaysOn. Все три базы располагаются физически на разных серверах. Таким образом, при разрушении боевой базы достаточно изменить имя сервера СУБД в свойствах базы на кластере 1С и продолжить работу.

Вид интерфейса и форм. Изначально база разрабатывалась на 8.0, потом перешли на 8.1, соответственно работали в обычном режиме и на обычных формах. На 8.1 число одновременно работающих пользователей составляло 3000 сеансов, проблем с поведением кластера не испытывали. На текущий момент (после перехода на 8.2) стали появляться управляемые формы, режим работы по прежнему обычный и вряд ли изменится в ближайшей перспективе (уже проще написать с нуля).

Доставка приложения. Пользователи работают на терминальных серверах. Терминалки виртуализированы. На рабочих местах пользователей - тонкие клиенты (железки).

Текущие релизы: 8.2.19.130 и 8.3.6.2076. 8.3 используется для других баз на управляемом интерфейсе, работает стабильно.

Зачем одна большая БД. Единая система или распределенная - вопрос холиварный. Всегда будут доводы как за, так и против. Основной (и не единственный) аргумент за распределенку - несколько маленьких баз легче обслуживать, требуется менее дорогое железо, выше отказоустойчивость (разрушение единой базы много критичнее разрушения одного узла в связке). Т.е. основной профит будет, если в системе не будет ни одного большого узла. Самое простое - разделить территориально "по офисам продаж", но в этом случае мы не получаем нужный профит т.к. центральный узел все равно будет нужен в силу существования потребностей в сводной информации. Причем важна и скорость появления данных в этом едином узле (функциональное требование - минута,две). На выходе получим ровно такую критичность и ресурсоемкость работы центрального узла как и текущей БД, только появится "бонус" - грядка баз поменьше. Таким образом делить "по точкам продаж" можно ради освоения бюджета, не более. Но у нас есть понимание и желание поделить БД по функционалу, разрезав её на отдельные сервисы. Это реально и это уже происходит, но удовольствие дорогое и окончание разделения дело не ближайшей перспективы.

Обновления. Регламент примерно таков - обновление конфигурации раз в две недели, предварительно неделя тестов и code rewiev. Объемы доработок достаточно большие. Обновления делаются ночью, временное окно - 2ч. Если реструктуризация не успевает (замер по тестам) - разделяем обновление, если и после этого не успевает - либо согласуем большее время, либо переносим обновление на праздничные дни. В истории с реструктуризацией удивляет поведение платформы - большинство СУБД умеет добавлять (про удаление вообще молчу) колонку в существующую таблицу с данными, надо только указать значение по умолчанию и тогда тип колонки не будет содержать NULL. Вместо этого 1С направило силы на создание "шариковой ручки для космоса" и сделали фоновое обновление... В общем СУБД умеет делать быстро, а платформа - нет.

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

СУБД. Сейчас обновились до Microsoft SQL Server Enterprise 2014. В свойствах БД установлен уровень совместимости SQL 2012. Параллелизм отключен.

Обмен с отчетной базой. Выгрузка распараллелена по объектам метаданных - самые часто изменяющиеся типы вынесены в отдельные потоки, остальные - одним общим потоком. Схема обмена в общих чертах - план обмена (не РИБ) с авторегистрацией объектов. При выгрузке - запросом делаем выборку первых N (настраивается, сейчас N=20) записей из таблицы изменений, пробегаем выборку и устанавливаем разделяемые управляемые блокировки на элементы, которые планируем прочитать. Читаем сами объекты, сериализуем их и передаем по СОМ в базу приемник. В приемнике десериализуем и записываем. Если все успешно - в источнике очищаем регистрацию изменений и фиксируем транзакцию. В приемнике блокировки не устанавливаются т.к. никто кроме обменов данные в ней не модифицирует.

****************

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.

+329 –

См. также

Поиск и анализ длительных вызовов - CALL, SCALL

HighLoad оптимизация Технологический журнал Системный администратор Программист Бесплатно (free)

Обсудим поиск и разбор причин длительных серверных вызовов CALL, SCALL.

24.06.2024 5133 ivanov660 12

Что не так с методом ЗаполнитьЗначенияСвойств

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Метод очень медленно работает, когда параметр приемник содержит намного меньше свойств, чем источник.

06.06.2024 9255 Evg-Lylyk 61

[Замер] Кто самый быстрый в конфигураторе?

HighLoad оптимизация Механизмы платформы 1С Системный администратор Программист Стажер Платформа 1С v8.3 Бесплатно (free)

Сравним «Регистры сведений» с «Сервисами интеграции» и узнаем, кто быстрее!

28.03.2024 5003 dsdred 23

Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Бесплатно (free)

Анализ простого плана запроса. Оптимизация нагрузки на ЦП сервера СУБД используя типовые индексы.

13.03.2024 5094 spyke 28

Быстродействие типовой 1С

HighLoad оптимизация Программист Платформа 1С v8.3 Бесплатно (free)

Оказывается, в типовых конфигурациях 1С есть, что улучшить!

13.03.2024 7571 vasilev2015 20

Анализируем SQL сервер глазами 1С-ника

HighLoad оптимизация Инструменты администратора БД Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Обработка для простого и удобного анализа настроек, нагрузки и проблем с SQL сервером с упором на использование оного для 1С. Анализ текущих запросов на sql, ожиданий, конвертация запроса в 1С и рекомендации, где может тормозить.

2 стартмани

15.02.2024 12416 241 ZAOSTG 80

115

Переход на Clickhouse для анализа метрик

HighLoad оптимизация Системный администратор Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Принимать, хранить и анализировать показания счетчиков (метрики) в базе 1С? Почему бы нет? Но это решение быстро привело к проблемам с производительностью при попытках построить какую-то более-менее сложную аналитику. Переход на PostgresSQL только временно решил проблему, т.к. количество записей уже исчислялось десятками миллионов и что-то сложное вычислить на таких объемах за разумное время становилось все сложнее. Кое-что уже практически невозможно. А что будет с производительностью через пару лет - представить страшно. Надо что-то предпринимать! В этой статье поделюсь своим первым опытом применения СУБД Clickhouse от Яндекс. Как работает, что может, как на нее планирую (если планирую) переходить, сравнение скорости работы, оценка производительности через пару лет, пример работы из 1С. Все это приправлено текстами запросов, кодом, алгоритмами выполненных действий и преподнесено вам для ознакомления в этой статье.

1 стартмани

24.01.2024 5668 glassman 18

Удаление строк из таблицы значений различными способами с замером производительности

HighLoad оптимизация Программист Платформа 1С v8.3 Конфигурации 1cv8 Абонемент ($m)

Встал вопрос: как быстро удалить строки из ТЗ? Рассмотрел пять вариантов реализации этой задачи. Сравнил их друг с другом на разных объёмах данных с разным процентом удаляемых строк. Также сравнил с выгрузкой с отбором по структуре.

09.01.2024 14007 doom2good 49

Комментарии

Подписаться на ответы Инфостарт бот

Свернуть все

1. dmpas 418 05.08.15 20:05 Сейчас в теме

А можно узнать размеры базы и параметры оборудования?
А из КИПа кроме ЦУПа чем-нибудь ещё пользовались? ЦКК, например, нагрузочное тестирование?

6. Sergey.Noskov 1406 06.08.15 10:32 Сейчас в теме

(1) baton_pk,
На текущий момент файл данных >4Тб
По железу можно посмотреть в проекте ЦКТП http://v8.1c.ru/expert/cts/cts-218-001.htm не один-в-один, но очень близко.
Из КИП еще пользовались стандартным нагрузочным тестом, под определенные задачи он подходит. ЦКК не использовали, присматриваемся.

17. dmpas 418 06.08.15 19:01 Сейчас в теме

(6)

На текущий момент файл данных >4Тб

Я работаю с базами на порядок меньше (сотни гигов), но уже там возникают проблемы, как то:
1) резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются
2) обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.
3) данные: вычистить мусор, пересчитать итоги (на базе в 600 гигов это занимало 10 часов на MSSQL и 12 на Постгресе), конфу поменять, индексы добавить

как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?

PS. кстати, не пробовали dt-шку выгрузить ? :-D

34. Sergey.Noskov 1406 07.08.15 10:53 Сейчас в теме

(17) baton_pk,

резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются

Благодаря AlwaysOn и отчетной базе у нас всегда на готове 2 базы - копии. Но и ежедневное бекапирование делается, чуть дольше 3х часов идет.

обслуживание: на базе в каких-то жалких 300 гигов перестроение индекса занимает более 6 часов.

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

как вы живёте с таким объёмом? чем жертвуете? на чём не скупитесь? делите ли таблицы на части, разносите ли по разным дискам?

Не скупимся на СХД ;) Жертвуем реструктуризацией.

PS. кстати, не пробовали dt-шку выгрузить ? :-D

Попробую расскажу)

2. ivanov660 4577 05.08.15 22:29 Сейчас в теме

У меня есть несколько вопросов по архитектуре описываемой высоконагруженной системы:
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?

P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))

5. dj_serega 393 06.08.15 10:32 Сейчас в теме

(2) ivanov660, Присоединяюсь к вопросам.

10. Sergey.Noskov 1406 06.08.15 11:40 Сейчас в теме

(2) ivanov660,
1. RLS не используется. Разграничиваем двумя этапами - роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из "особенностей" только то, что у центрального сервера нет rphost'ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность - пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя - кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 - 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам "нет лишним таблицам" и "зачем нам регистр, если все есть в документе", поэтому все не просто.

Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))

3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)

Ответить

25. RustIG 1747 06.08.15 23:12 Сейчас в теме

(10) спасибо за подробности! смелый шаг!

111. nvv1970 30.10.17 20:15 Сейчас в теме

(10) управляемые формы позволяют разгрузить терминальные сервера, а сервер 1с наоборот - загрузить.

1с запретила делать резервирование серверов на 8.2. В 8.3 нет проблем с отказоустойчивостью?

112. Sergey.Noskov 1406 31.10.17 11:46 Сейчас в теме

(111)

В 8.3 нет проблем с отказоустойчивостью?

Так понимаю вопрос касается следующего проекта, уже по переходу на 8.3. Давайте с определением для начала разберемся, а то под отказоустойчивостью можно понимать разные вещи.
Если говорить про резервирование серверов (что и дает полноценную отказоустойчивость), то на 8.3.10 и ранее работает не очень хорошо (в последних релизах оно даже работает, но при включении заметна деградация в скорости работы), поэтому мы пока не используем. Тесты 8.3.11 показывают хорошие результаты, APDEX практически не отличается от режима без резервирования т.ч. надежда есть.
Если же говорить про отказоустойчивость в рамках стабильной работы (отсутствие без причинных вылетов, закрытия сеансов), то тут все хорошо, сейчас работаем на 8.3.10.

113. nvv1970 31.10.17 11:54 Сейчас в теме

(112) Спасибо за ответ. В терминологии могу быть неточен, сорри.
Про деградацию при использовании нескольких центральных серверов в теме. Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?
Меня больше интересовала позиция 1с, раз уж у вас с ними очень тесный контакт )

114. Sergey.Noskov 1406 31.10.17 12:42 Сейчас в теме

(113)

Если центральный один + несколько "вспомогательных" - то вопросов, как я понимаю, в части производительности не возникает?

тут все нормально, да.
За позицию 1С не скажу)) но в целом видно желание сделать все хорошо и красиво.

3. Red_Devil 181 06.08.15 10:03 Сейчас в теме

700 тысяч проведений в сутки??? Мы не знаем что со своими 100 пользователями в УПП делать а тут такое =0

4. dmpas 418 06.08.15 10:15 Сейчас в теме

(3) Red_Devil, выкиньте УПП, заведите отдел разработки в 40+ человек, запилите самописку, пригласите ЦКТП.

Ответить

8. Red_Devil 181 06.08.15 10:45 Сейчас в теме

(4) baton_pk, аа у них самописка, тогда конечно можно написать документ с 1 регистром =) Жаль в типовых такого не добьешься.

9. Sybr 242 06.08.15 10:56 Сейчас в теме

(8) Скорее всего в этой самописке регистров больше чем в типовой УПП.

13. Lostar 06.08.15 14:46 Сейчас в теме

(3) Red_Devil, ну так УПП ж. Ужасающе неоптимизированный продукт по производительности. Даже 5 пользователе могут рождать deadlock`и.

7. kolya_tlt 88 06.08.15 10:41 Сейчас в теме

можно узнать подробности при переводе на 8.2? с какими трудностями столкнулись, что не учли помимо тестирования?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?

11. Sergey.Noskov 1406 06.08.15 13:39 Сейчас в теме

(7) kolya_tlt, Переход на 8.2.13, тот который делали своими силами, провалился из-за поведения кластера 1С - он отказывался балансировать сеансы. Все пользователи оказались на одном сервере - самом мощном по железу. Плюс кластер постоянно "тасовал" сеансы между процессами. Конфигурацию готовили без совместимости, все программные "нюансы" выловили при тестировании логики. Вот список замечаний, который мы в то время для себя составляли:

-Работа с NULL в запросах при использовании конструкций вида ЕСТЬNULL("("+Таблица.Поле+")") // старый комент, возможно исправлено в свежей версии
-Проверить наличие везде проверки на ОбменДанным.Загрузка // для репликации
-Заменить вызова ОткрытьФормуМодально()
-Убрать третий параметр из вызовов ПравоДоступа()
-В процедуру обработчик события «ОбработкаЗаполнения» передается структура, в которой может и не быть поля Ссылка.
-Исправить формат булево по умолчанию на Истина и Ложь.
-Не работает формат даты с использованием YYYY
-Функция ТипЗнч() - не возвращает "...Ссылка...", «Документ..» и т.п., соответственно не работает код вида Найти(ТипЗнч(СсылочноеЗначение), «Справочник»)
-При не использовании Наименования или Кода справочника необходимо отключить его проверку - открыть СтандартныеРеквизиты на закладке объекта Данные и в свойствах нужного
реквизиты указать Проверка - Не использовать.
-Ошибка при выполнении кода вида: ТабДок.Вывести(ТабДокКопия.Область());
-Не работают запросы с условием вида &Контрагент В (Таблица.Получатель, Таблица.Отправитель, Таблица.Объект) если какое то из полей Таблица.Получатель, Таблица.Отправитель, Таблица.Объект - составного типа // всегда возвращается ЛОЖЬ
-Не работают запросы с условием вида ГДЕ Документ.ТабличнаяЧасть.Ссылка ЕСТЬ НЕ NULL // всегда возвращается ИСТИНА
-Для протокола POP3 не корректно работает метод ИнтернетПочта.ПолучитьЗаголовки(); // все заголовки с одинаковым идентификатором сообщения

Показать

Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу - спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч - приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.

18. kolya_tlt 88 06.08.15 20:39 Сейчас в теме

(11) 1. в итоге какая версия платформы вела себя достаточно стабильно для текущей работы?
2. чем и зачем заменяли ОткрытьФормуМодально?
3. что подразумевается под "Исправить формат булево по умолчанию"?

35. Sergey.Noskov 1406 07.08.15 11:02 Сейчас в теме

(18) kolya_tlt, Версия платформы - начиная с 8.2.19.83, сейчас обновились на 8.2.19.130

чем и зачем заменяли ОткрытьФормуМодально?

не актуальный комент, у нас в 8.1 была своя такая функция, поэтому пришлось переименовывать

что подразумевается под "Исправить формат булево по умолчанию"?

В конфигураторе, Администрирование - Региональные установки, в 8.2 по умолчанию стоит Да и Нет - части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1

37. kolya_tlt 88 07.08.15 11:08 Сейчас в теме

(35) а может быть актуализируете список ? :) по возможности конечно.
1. зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?
2. "Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)

39. Sergey.Noskov 1406 07.08.15 12:26 Сейчас в теме

(37) kolya_tlt, список актуальный, выкиньте пункт ОткрытьФормуМодально(), ну а формат булево по умолчанию - дело вкуса))

зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?

ОбменДанными.Загрузка нужна для корректной работы обменов. Ну и вообще наличие этой проверки в событиях ПередЗаписью, ПриЗаписи это уже стандарт.

"Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)

Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), "ДФ=dd.MM.YYYY")
Искали просто - глобальным поиском строку YYYY с учетом регистра.

12. DoctorRoza 06.08.15 14:44 Сейчас в теме

А вот мне стало интересно, ну что же это за контора то такая с такой базой? Энергетики или нефтяники что ли?

15. Bronislav 06.08.15 15:00 Сейчас в теме

(12) DoctorRoza, "Деловые линии" - транспортная компания.

16. Sergey.Noskov 1406 06.08.15 15:08 Сейчас в теме

(15) Bronislav, раскрыл интригу)) приятно было быть нефтяником ;)

14. Lostar 06.08.15 14:53 Сейчас в теме

Автору огромное спасибо! Очень востребованная тема. Столько боли прожито с производительностью. Почему-то в нашей стране считается, что оптимизация sql это вопрос программистов 1С, хотя 101% из них не обладают не то, что достаточными, но даже начальными знаниями в этом вопросе.

Отдельное спасибо за скульные запросы. Будем пробовать.

19. RustIG 1747 06.08.15 22:36 Сейчас в теме

(0) Со всем уважением к автору и к его докладу!
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...

38. Sergey.Noskov 1406 07.08.15 12:13 Сейчас в теме

(19) Rustig, (26) Rustig, (31) Rustig,

Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)

Спасибо за вопросы. Видел методичку, как по задаваемым вопросам понять настроение человека и что его беспокоит, видимо много багов и косяков вас окружает ;) но это так, не много не в тему..

База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
ЦФ-шник в студию - уверен, что косяков там достаточно....

Слишком много внимания косякам, конечно есть и ошибки и просчеты, есть экстренные хотелки бизнеса, а ля "должно работать завтра". Не ошибается только тот, кто ничего не делает.
Но что бы половина обновления - исправление ошибок, серьезно? Частота обновления и количество программистов приведено для понимания скорости наращивания функционала. Постоянное развитие базы - это наша специфика.

Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...

Управляемые формы не использовались, на 8.2 мы перешли только в прошлом году, т.ч. основная разработка велась на 8.0 и 8.1
Формы списков - обычные, запросы которые вышли в топ - платформенные вызываемые, например, при скроллинге и выводе списка.
Построитель - да, "не красиво", но личное мнение, что для высоко нагруженных систем будущее за статичными формами поиска (интерфейс SAP это подтверждает). И красивые возможности типа таких http://v8.1c.ru/o7/201401ls/index.htm без контроля по каким колонкам можно искать, по каким можно искать строго на равенство, по каким нельзя сортировать и т.п. - пугают потенциальным воздействием на систему.

в докладе нет анализа первопричины проблем

Есть конечно. Это и рост самой компании и потребностей в части функционала.

47. RustIG 1747 08.08.15 20:32 Сейчас в теме

(38) Вы точно уловили мое настроение! +

49. RustIG 1747 08.08.15 20:46 Сейчас в теме

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

52. a_titeev 32 08.08.15 22:24 Сейчас в теме

(49) Rustig, первый совет, с которого начинается книга Фаулера о распределенных системах звучит так - "не распределяйте системы! ну а если это по каким-то очень веским причинам невозможно, то для вас следующие 600 страниц текста". примерно так...

53. Sergey.Noskov 1406 10.08.15 10:04 Сейчас в теме

(49) Rustig,

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

Думали, точнее не так, правильнее сказать, что изначально именно так и было :)
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
"Распределенка" это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.

20. RustIG 1747 06.08.15 22:44 Сейчас в теме

Конечно запросы из форм списков были не единственными, мы переписали достаточно много запросов, а где то и архитектуру. Эта работа дала результат. Раньше, например, нагрузка на систему в понедельник и пятницу могла быть настолько высока, что приходилось отпускать домой некоторые отделы (менеджеров, колл-центр). А в результате проведенной оптимизации получилось снизить нагрузку в пятницу – проблем больше не было. Да и в понедельник мы тоже, со скрипом, но работали.

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

Штат разработчиков 20 человек. Сколько из них сертифицированы? Сколько из них с опытом свыше 3 лет программирования и консультирования? Вы извините , но 20 - ни о чем не говорит. А вот 20 профессионалов своего дела - уже впечатляет. :)

29. Sergey.Noskov 1406 07.08.15 07:56 Сейчас в теме

(20) Rustig, Статей и докладов на тему оптимизации запросов очень много. Не было смысла тратить время конференции, тем более сразу за мной на эту тему выступал Андрей Бурмистров.

Про команду - сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.

21. RustIG 1747 06.08.15 22:50 Сейчас в теме

(0) глава "Разделяй и властвуй" - очень поучительна!

22. RustIG 1747 06.08.15 22:57 Сейчас в теме

обращайтесь в 1С, в рамках проектов ЦКТП достаточно оперативно устраняются и ошибки платформы и выявляются "узкие" места БД.

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

28. Sergey.Noskov 1406 07.08.15 07:37 Сейчас в теме

(22) Rustig, Нет, выходит официальный релиз, никаких исключений.

23. RustIG 1747 06.08.15 23:06 Сейчас в теме

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

30. Sergey.Noskov 1406 07.08.15 07:58 Сейчас в теме

(23) Rustig, Где управляемые формы? И при чем тут ЦУП...

31. RustIG 1747 07.08.15 09:50 Сейчас в теме

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

76. ZLENKO 398 14.08.15 13:28 Сейчас в теме

(31) Rustig, "я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается..."

Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server - самые длительные запросы.

78. Sergey.Noskov 1406 14.08.15 14:15 Сейчас в теме

(76) ZLENKO, Монитор активности пользуется теми же динамическими представлениями (dm_exec_query_stats и dm_exec_requests) только более сложно агрегирует получаемые данные.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_...
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.

24. RustIG 1747 06.08.15 23:11 Сейчас в теме

регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.

ужас... механизм не то чтобы "не гибкий", а спорный в использовании....

32. kolya_tlt 88 07.08.15 09:56 Сейчас в теме

(24) Rustig, прошу аргументировать и предложить вариант

26. RustIG 1747 07.08.15 00:45 Сейчас в теме

(0), (17) 4 Тб - тоже ни о чем!
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом...
свертку давно делали?...
половину инфы можно удалить из рабочей базы - номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год.... кому они нужны в текущей рабочей менеджерской базе?....
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы.....
я уверен, что можно обойтись без цупа
ЦФ-шник в студию - уверен, что косяков там достаточно....

27. Fox-trot 163 07.08.15 07:34 Сейчас в теме

(26) Rustig,

ЦФ-шник в студию - уверен, что ....

мальчик, может тебе ключи от дома дать, где деньги лежат? (с) не_моё

33. dmpas 418 07.08.15 10:14 Сейчас в теме

(26) Rustig,

есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют

поверьте, это всё такая мелочь :)

Ответить

46. RustIG 1747 08.08.15 20:30 Сейчас в теме

(33) я не уверен, что мелочи.
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд... мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки - картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка....
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп... если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи...
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб....

51. dmpas 418 08.08.15 21:18 Сейчас в теме

(46) Rustig,

мы с вами на разных уровнях работаем

Не в этом дело. Просто ваш ответ был в контексте 4ТБ, а для 4ТБ что гиг, что двадцать - мелочи.

вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб

70 магазинов с файловыми базами 2-4 ГБ, в каждом магазине по две: на складе и в магазине. Падают часто. Так что, да, мне тоже придётся скоро оптимизировать и их работу тоже :).

(49) Rustig,

на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д.

нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две - это уже довольно эпохальное решение, а разбивать её на десяток - ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами - это немалые накладные расходы на обмен.

36. kolya_tlt 88 07.08.15 11:04 Сейчас в теме

(26) Rustig, вы поймите, у оптимизации есть 2 пути:
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь

ps косяки есть в любом цф-нике. вам зачем на них смотреть?

45. a_titeev 32 08.08.15 17:48 Сейчас в теме

(26) Rustig,

классификатор адресов сколько съедает места?
классификатор банков?

Вы точно сталкивались с большими базами?
(6) замечательно. Отличный опыт. Спасибо что поделились. Пожалуй перейму пару идей :)

48. RustIG 1747 08.08.15 20:42 Сейчас в теме

(45) ответил в (46)
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С - в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист...

55. RustIG 1747 11.08.15 13:18 Сейчас в теме

(26)

4 Тб - тоже ни о чем!

Беру свои слова обратно: ~~4 Тб - тоже ни о чем!~~
Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб... :))

58. dmpas 418 11.08.15 18:00 Сейчас в теме

(55) Rustig, аналогия в данном случае немного за уши притянута: для файловой базы ограничение в 4ГБ на одну внутреннюю таблицу - это ФИЗИЧЕСКОЕ ограничение, а 4ТБ для клиент-серверной - исключительно психологическое. База вполне может себе жить и пухнуть дальше до 40, 400, 4000. и если не заниматься доработками, связанными с реструктуризацией, то у платформы есть все возможности сделать так, чтобы пользователь не замечал разницы между большой базой и маленькой (речь, разумеется, не про типовые конфигурации :-D)

40. molodoi1sneg 17 07.08.15 14:20 Сейчас в теме

А бух. учет где ведется? Обмен?

41. Sergey.Noskov 1406 07.08.15 15:22 Сейчас в теме

(40) molodoi1sneg, Бух учет ведется в типовой, первичка грузится через обмен.

42. dmpas 418 07.08.15 16:09 Сейчас в теме

(41)
ооо! а вот тут-то самая вкусняшка начинается!
двусторонний обмен? коллизии? блокировки при обменах? размеры пакетов?

43. Sergey.Noskov 1406 07.08.15 16:25 Сейчас в теме

(42) baton_pk, неа, не начинается)) Обмен односторонний + закрытие периода, поэтому блокировок и коллизий нет.

44. genayo 07.08.15 20:43 Сейчас в теме

(41) А вот тут интересно, для типовых конфигураций применяли такие-же методики анализа проблем?

50. RustIG 1747 08.08.15 20:58 Сейчас в теме

(0) свяжу ваш кейс со статьей http://infostart.ru/public/387232/
так сказать на будущее

54. capitan 2507 11.08.15 10:39 Сейчас в теме

Два извечных вопроса интернета: Как? и Зачем ?
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит - хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.

59. Sergey.Noskov 1406 11.08.15 18:11 Сейчас в теме

(54) capitan,

И что удивительно практически всегда там находится SoftPoint.

В чем удивительность, поделитесь? Почему вас не удивляет наличие у нас ЦУП, SQL, Windows, Perfomance Monitor, а именно инструменты этой компании?

И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.

повторюсь, основная причина - рост компании, открытие подразделений в городах.
Изначально каждое подразделение работало в своей базе. Решение о слиянии баз было принято из-за предъявляемых бизнес процессами требований. Ну а извечные вопросы Как? и Зачем? все равно будут, да же если доклад посвятить теме "Опыт оптимизации и контроля производительности в распределенной системе из 100 узлов".

На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.

Далеко от реальности. Когда у вас работоспособность БД на условном нуле затевать проект логической модификации БД это равносильно профессиональному самоубийству. Сначала дайте бизнесу рабочую базу, а дальше продумывайте новую архитектуру, её плюсы и минусы, считайте бюджет и выходите на защиту проекта.

Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.

а про бумагу то мы и забыли..)))
Если серьезно, то это набор общих фраз характеризующих некую идеальную среду мироздания. Когда мы рассматриваем реальную ситуацию, то появляются множество нюансов и так просто не получается. Например, сам пользователь актуальные данные не читает, но те изменения, которые он вносит - очень важны для остальных (бухгалтер, вносящий факт оплаты), либо окажется, что в небольшом филиале один сотрудник совмещает несколько должностей и после разделения он будет вынужден работать в 2х - 3х базах.
Пример по реалтаймности. Наш Call центр обзванивает клиентов для информирования, что груз прибыл и его можно забрать. При этом регламентное задание, актуализирующее номера телефонов в обзвонщике, работает раз в 5 минут. Так вот, за эти 5 минут информация успевает устаревать (клиент как раз забирал груз в это время; менеджер заблокировал выдачу из-за проблем с оплатой). Оператор Call центра в таких случаях просто извиняется и вешает трубку. В процентном отношении это не большие цифры, но в количественном это сотни напрасных звонков за сутки. Т.е. несколько сот клиентов могли бы раньше узнать о том, что груз уже приехал и его можно забрать. Естественно, что частота работы регламентного была увеличена. И сейчас, когда вся информация в одной базе, а если говорить про распределенку таких случаев будет неминуемо больше.

И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30

так их не станет 30, их в сумме все равно будет 3000, а вот число серверов 1С и баз, безопасность которых по идее и надо контролировать, значительно возрастет.

Ответить

69. capitan 2507 12.08.15 22:09 Сейчас в теме

(59) видел ответы ,некоторые улыбнули :) но не буду вдаваться в полемику, поберегу время.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже - логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон - N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.

70. Sergey.Noskov 1406 13.08.15 12:37 Сейчас в теме

(69) capitan,
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.

Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?

Если мы говорим про физическое разрушение БД, когда в базу принципиально нет возможности даже войти, то время восстановления работоспособности менее минуты - достаточно в свойствах базы 1С изменить базу СУБД на отчетную или базу-реплику (AlwaysOn). Все 3 базы на физически разных СХД и физически разных серверах.

И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?

В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?

А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.

У вас либо есть защитный механизм, либо его нет. Если защита есть, то ей должно быть по фиг 30 у вас пользователей или 3000.

Вообще всегда интересны различные идеи и концепты, они позволяют "расширять сознание", поэтому если у вас есть какое то видение, как разом "побороть" все вышеописанные проблемы, напишите, любопытно.

71. Зеленоград 13.08.15 13:00 Сейчас в теме

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

В подобных целях видел регламентную очистку исполненных и закрытых заказов, дабы не попасть по числу объектов под неудобный класс ИС.

А сам на проверке с уверенным видом расказывал, что "архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют". Коллеги сдержались, проверяющие изумились, но отвязались.

72. Sergey.Noskov 1406 13.08.15 14:34 Сейчас в теме

(71) Зеленоград, Это я понял, я не понял при чем тут 3000 пользователей. Видимо надо уволить 2970 сотрудников компании, ведь с 30 пользователями все намного легче)

74. capitan 2507 14.08.15 11:40 Сейчас в теме

(70) самым великим мастером давать ответы далекие по смыслу от темы вопроса был конечно Михаил Сергеевич, долгой ему жизни. И задолго до него известна фраза Райкина - Хотите меня поставить в тупик своими вопросами - так я вас поставлю в тупик своими ответами.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
На самом деле, если ваша должность была сисадин или DBA, DBA кстати пишут фолианты об оптимизации серверов, вопросов бы не было. Я бы первый поставил +, написал бы здесь красавчеГ и откланялся.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.

75. Sergey.Noskov 1406 14.08.15 13:23 Сейчас в теме

(74) capitan,

Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.

Извиняюсь, что не понял вопрос. Для нас тестирование - это именно функциональные тесты.
Реиндексация делается средствами СУБД. Пересчет итогов - делается в режиме предприятия. Реструктуризация всей базы - не делается, при необходимости делается для конкретного объекта. Проверки логической и ссылочной целостности сами по себе (на всякий случай) смысла не имеют, у нас много "битых" ссылок в силу особенности реализации отдельных подсистем.
По реструктуризации и проверкам целостности - не возможность использования именно ТиИ ни как не мешает, все возникающие задачи решались своими силами.

Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.

Нахождение справочника контрагентов в одной базе с остальными объектами конфигурации само по себе ничего не нарушает. Персональные данные это четко обозначенная информация о физ лице. Если эта информация храниться в базе, её можно шифровать, очищать, хранить эти данные в "другой БД" и т.д. и т.п. Но я искренне не понимаю при чем тут 3000 пользователей, если в БД их только 30, то на закон можно и подзабить? или эту проблему будет проще решить? Мне видится что закон касается любой системы, распределенной или нет - без разницы.

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

Груз и принимается и выдается. Это только часть основного бизнес процесса, вокруг него много вспомогательных (информирование клиентов, анализ ожидаемого грузопотока, планирование состава машины и её маршрута - только часть из них).

На самом деле, если ваша должность была сисадин или DBA,...
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.

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

Про распределенку.
Если разговор зашел про недостатки больших баз, то всем (без сарказма - мне тоже) будет полезно увидеть как подобные проблемы решаются в распределенных системах и в чем их профит.
Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.

77. ZLENKO 398 14.08.15 13:30 Сейчас в теме

(75) "Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая."

Думаю аналогично.

79. genayo 14.08.15 15:59 Сейчас в теме

(77) На самом деле, часть из этих проблем решаема, приведу пример как это решено у нас (продуктовая дистрибуция), несколько филиалов:

1.Двух сторонние обмены и как следствие конфликты изменений.
Организован РИБ, в каждом филиале подчиненный узел. Вся НСИ вводится только в центральной базе, различные виды документов могут быть отредактированы либо только в центральной базе, либо только на филиале. Аналогично организован обмен с бухгалтерской программой. Конфликты изменений практически исключены.
2.Процесс обновления более трудоемок за счет увеличения количества баз.
На самом деле, это критично если баз больше 10-15, на меньшем числе увеличение трудоемкости малозначительно, причем, при желании, это все можно еще и автоматизировать.
3.Все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
В центральную базу переносится не вся информация из филиалов, а только те данные, которые нужны для построения сводных отчетов по всей компании. В нашем случае, например, только информация о продажах.
4.Увеличение парка серверов и баз данных, требуется больше серверных лицензий - в общем, это не очень большие затраты, если "размазать" их на все время эксплуатации железа.

Очевидно, что этот подход также имеет свои минусы, но вполне себе имеет право на жизнь.

Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор :) и бездумно брать этот пример и пытаться повторить не стоит...

80. Sergey.Noskov 1406 14.08.15 16:52 Сейчас в теме

(79) genayo,
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.

На самом деле, это критично если баз больше 10-15

Если говорить о комфортных 100 пользователях в одной БД, получится 30 баз))
При текущем анализе возможности функционального разделения базы (не территориального, именно функционального) рассматривался вариант минимум из 10 баз.

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

Регистр с информацией о продажах у нас один из лидеров по размеру. Второй лидер, информация о движении груза, так же будет нужен в центральной БД для построения статистических отчетов. Мы оценивали какой бы мог быть профит и получается, что самые объемные таблицы все равно будут нужны в центральной БД. Как вариант - переписать всё, сделав разную конфигурацию под центр и под филиал. Продумав логику хранения данных можно будет что то сэкономить. Долго и дорого, но возможно.

но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор

Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.

81. Sergey.Noskov 1406 14.08.15 17:18 Сейчас в теме

(79) genayo, не могу удержаться от off топа)

бездумно брать этот пример и пытаться повторить не стоит...

Бездумно - нет! Но пробовать и повторять - однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.

82. genayo 14.08.15 21:21 Сейчас в теме

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

83. Sergey.Noskov 1406 17.08.15 10:32 Сейчас в теме

(82) genayo,
Переход на 8.3 рассматривается. Интересны не столько программные "фишки", сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.

56. Xershi 1555 11.08.15 13:37 Сейчас в теме

Прошу поправить

на одину

60. Sergey.Noskov 1406 11.08.15 18:14 Сейчас в теме

(56) Xershi, исправил, спасибо

57. МихаилМ 11.08.15 13:41 Сейчас в теме

автор, как решили проблему долгой реструктуризации ? и удаления доп.индексов после реструктуризации

63. Sergey.Noskov 1406 12.08.15 12:16 Сейчас в теме

(57) МихаилМ,

автор, как решили проблему долгой реструктуризации ?

У нас ограничение от бизнеса - полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов - разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.

61. Painted 49 12.08.15 10:49 Сейчас в теме

Прямыми запросами к MS SQL не баловались? Или близость к 1С не позволяет? Или баловались, но вслух об этом не говорят?

64. Sergey.Noskov 1406 12.08.15 13:53 Сейчас в теме

(61) Painted,

Прямыми запросами к MS SQL не баловались?

Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали "прямые" запросы в базу-копию (раз в неделю разворачивали из бэкапа)

62. vec435 17 12.08.15 10:52 Сейчас в теме

а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?

65. Sergey.Noskov 1406 12.08.15 14:06 Сейчас в теме

(62) vec435,

а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?

Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.

66. genayo 12.08.15 16:39 Сейчас в теме

(65) Если не секрет, сколько у вас серверных ключей и сколько клиентских и каких, программных или аппаратных?

67. Sergey.Noskov 1406 12.08.15 17:46 Сейчас в теме

(66) genayo, Ключи программные. 4 серверных и 3500 пользовательских.

68. asved.ru 36 12.08.15 18:05 Сейчас в теме

А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании. RDS?
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?
Спасибо.

73. Sergey.Noskov 1406 13.08.15 15:41 Сейчас в теме

(68) asved.ru,

А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании.

Пользователи с базой работают терминально.

Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?

Показатели достаточно стабильны (исключение - время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 - 0,99.
Критичные отклонения - ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX'а была притирка - сопоставляли объем поступающих жалоб со значением показателя.

84. Irwin 562 17.08.15 11:18 Сейчас в теме

Можно узнать подробнее про процесс разработки?
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?

ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.

85. Sergey.Noskov 1406 17.08.15 14:48 Сейчас в теме

(84) Irwin, не все программисты работают на одну базу. У нас есть и типовые и несколько баз помельче. В этой базе, если не ошибаюсь, порядка 15 разработчиков.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы "придут" одному разработчику.

ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища

ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.

86. Slon1c 03.09.15 14:22 Сейчас в теме

Ничего удивительно ни в размере базы, ни в количестве пользователей нет. Наслышан об успешной оптимизации и рефакторинге кода от непосредственных исполнителей. На сегодняшний день очень много крупных компаний использующих 1С с объемами баз свыше 1 Тр и количеством пользователей от 500 (данные на одну базу). Есть компании в которых используются более 120 независимых баз между которыми осуществляется онлайн обмен. Реструктуризация больших таблиц средствами 1С - процедура долгая и утомительная. Даже при хорошем железе добавление нового реквизита в 1С с простым типом - несколько часов при объеме таблицы свыше 100 Гб и количестве записей от 80 млн. и более, естественно используются другие возможности. Это уже не говоря об удалении такого реквизита :), с проверкой логической и ссылочной целостностью базы. Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ? Используете data кластер от SoftPoin ? По заголовку запросов и происходит разделение (перенаправление) на различные сервера СУБД ? Как обошли отчеты в которых требуется создавать промежуточные временные таблицы ?

87. Sergey.Noskov 1406 05.09.15 17:41 Сейчас в теме

(86) Slon1c,
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная - добавление колонки в существующую таблицу SQL возможно только с типом "содержит NULL", это может привести к построению плана запроса с избыточными операциями.

Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ?

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

Используете data кластер от SoftPoin ?

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

101. starik-2005 3087 08.11.16 12:33 Сейчас в теме

(87) по поводу новых колонок с реструктуризацией, то достаточно быстрый вариант такой: переименовывается исходная таблица, предварительно создается скрипит CREATE для таблицы. После переименовывания таблица создается, проводится реструктуризация, после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи из переименованной исходной таблицы. В итоге и поля "без нуллов", и данные вставлены куда быстрее, чем штатными механизмами, ибо штатный механизм читает записи, потом проверяет на типы данных, и если тип изменился и теперь не содержится в поле, то он очищает данное поле, после чего уже очищенный вариант пишет в таблицу. Это ну о-о-о-о-о-чень долго...

102. Sergey.Noskov 1406 08.11.16 12:51 Сейчас в теме

(101) starik-2005,

после чего через INSERT INTO SELECT FROM ...в старую уже отреструктуризированную таблицу вставляются записи

не понял профит, именно эта операция самая длительная при типовой реструктуризации.
На сайте уже было одно из решений http://infostart.ru/public/536650/ и мы уже общались на эту тему.
Там, кстати, вы другое решение озвучивали

Потом переименовываю старую таблицу обратно и АЛЬТЕР КООЛОНКА/АЛЬТЕР ИНДЕКС создаю соответствующие колонки и индексы.

и оно больше похоже на правду ;)

103. starik-2005 3087 08.11.16 13:36 Сейчас в теме

(102) да, я оба варианта использую. Но в последнее время из-за лени, видимо, чаще именно вариант с копированием применяю. Последний раз данную процедуру буквально на днях применял - у клиента есть регистр с 6кк записей. Достаточно большой. В него добавили ресурс текстовой - строка 10 символов. В итоге система на тестовом стенде реструктуризировалась очень долго - не дождались (думаю, примерно неделя бы ушла). При том вставка заняла всего 3 часа. Но это железки обычные - не ваши.

Есть у меня мнение, что большинство не понимает, как работает реструктуризация. Если бы она просто копировала данные из одной таблицы в другую за раз (ins ert in to tb1 sel ect * fr om tb2), то это было бы просто шикарно и скорость такой реструктуризации многих бы удивила. Но 1С все делает не так. Она читает порцию из таблицы 1, потом обрабатывает ее (проверяет соответствие типов полей с метаданными - как часть механизма), потом эту порцию записывает в таблицу с суффиксом NG. После того, как все объекты обновлены, 1С в транзакции удаляет старые таблицы и переименовывает таблицы NG. Основное время реструктуризации занимает обработка данных платформой, ну и порционность вставки вносят свою лепту, ибо одно дело - один запрос на сервере выполняется, совсем другое - куча запросов + данные, метаемые с сервера SQL на сервер приложений и обратно. Один сетевой трафик чего стоит.

88. dablack 16.12.15 09:30 Сейчас в теме

Сергей, подскажите пожалуйста, вы описывали, что у вас достаточно много запросов со стороны сайта к web сервисам 1с. Хотелось бы узнать поподробнее, что используется IIS, Apache?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?

89. Sergey.Noskov 1406 25.12.15 13:18 Сейчас в теме

(88) dablack,
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись - настройка таймингов. Суть проблемы (упрощенно) - если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до "бесконечности". Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.

90. Sergey.Noskov 1406 25.12.15 18:32 Сейчас в теме

(88) dablack,
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
Специально никто переписывать обычного клиента не будет - работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.

>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли "выгрузить очередь для обзвона" и "найти клиента по номеру телефона и отобразить данные".

91. goodron 29.12.15 21:55 Сейчас в теме

Про это:
Виктор Богачев, Проект по нагрузочному тестированию 1С 8 для 5000 пользователей в одной ИБ
http://www.youtube.com/watch?v=0KN5DdkbS2g

92. zhichkin 1524 17.01.16 23:46 Сейчас в теме

Сергей, Вы пишете:

Улучшили подсистему репликации и добились актуальности данных в 2 – 3 минуты, что значительно расширило список перенаправляемых отчетов. Доработки в основном были нужны потому, что стандартный метод "ВыбратьИзменения" планов обмена создает большое колличество блокировок.

Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?

Оставьте свое сообщение

E-mail:

Автор:

Сергей Носков (Sergey.Noskov)

Рейтинг: 1406

Для получения уведомлений о новых публикациях автора подключите телеграм бот: Инфостарт бот

Публикация:

№ 378766

Создание 05.08.15 16:22

Обновление 04.03.16 17:05

Статистика:

Просмотры 73683

Загрузки 0

Рейтинг 329

Комментарии 119

Характеристики:

Код открыт Не указано

Рубрики HighLoad оптимизация

Кому Системный администратор ,
Программист

Тип файла Нет файла

Платформа Не имеет значения

Конфигурация Не имеет значения

Операционная система Windows

Страна Не имеет значения

Отрасль Не имеет значения

Налоги Не имеет значения

Вид учета Не имеет значения

Доступ к файлу Бесплатно (free)