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

Опубликовал Sergey.Noskov в раздел Администрирование - Оптимизация БД (HighLoad)

Данная статья написана по материалам доклада, прочитанного на Конференции Инфостарта 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 железа. Пока было куда "апгрэйдить" это помогало. Когда и топовое железо перестало помогать, тогда и началась оптимизация.

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

  1. Разработали план регламентных работ по перестроению и дефрагментации индексов.
  2. Установили ЦУП и принялись за оптимизацию запросов.
  3. Перешли на управляемые блокировки.
  4. Внедрили 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) записей из таблицы изменений, пробегаем выборку и устанавливаем разделяемые управляемые блокировки на элементы, которые планируем прочитать. Читаем сами объекты, сериализуем их и передаем по СОМ в базу приемник. В приемнике десериализуем и записываем. Если все успешно - в источнике очищаем регистрацию изменений и фиксируем транзакцию. В приемнике блокировки не устанавливаются т.к. никто кроме обменов данные в ней не модифицирует.

См. также

Лучшие комментарии

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

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

3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)
Ответили: (25)
# Ответить
59. Sergey.Noskov 11.08.2015 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)
# Ответить
4. baton_pk 06.08.2015 10:15
(3) Red_Devil, выкиньте УПП, заведите отдел разработки в 40+ человек, запилите самописку, пригласите ЦКТП.
Ответили: (8)
# Ответить

Комментарии

1. baton_pk 05.08.2015 20:05
А можно узнать размеры базы и параметры оборудования?
А из КИПа кроме ЦУПа чем-нибудь ещё пользовались? ЦКК, например, нагрузочное тестирование?
Ответили: (6)
+ 2 [ ivanov660; qwed557; ]
# Ответить
2. ivanov660 05.08.2015 22:29
У меня есть несколько вопросов по архитектуре описываемой высоконагруженной системы:
1. Какое разграничение прав доступа используется? Используется ли RLS? Какое количество в среднем различных ограничений видов доступа на одного пользователя?
2. Какая структура кластеров 1С? Используется ли масштабирование средствами 1С? Используется ли резервирование средствами 1С, каков параметр отказоустойчивости?
3. Используется ли виртуализация?
4. Конфигурация на обычных формах?
5. Какова средняя сложность запросов отчетов? Сколько таблиц участвуют в соединениях, есть ли виртуальные?

P.S. Не могу представить, что 3500 пользователей могут одновременно работать в одной базе 1С не на управляемых формах. Но ожидаю, что подобной информацией автор поделится чтобы развеять мои сомнения, как следует из заголовка статьи )))
Ответили: (5) (10)
+ 2 [ JohnyDeath; dj_serega; ]
# Ответить
3. Red_Devil 06.08.2015 10:03
700 тысяч проведений в сутки??? Мы не знаем что со своими 100 пользователями в УПП делать а тут такое =0
Ответили: (4) (13)
# Ответить
4. baton_pk 06.08.2015 10:15
(3) Red_Devil, выкиньте УПП, заведите отдел разработки в 40+ человек, запилите самописку, пригласите ЦКТП.
Ответили: (8)
# Ответить
5. dj_serega 06.08.2015 10:32
(2) ivanov660, Присоединяюсь к вопросам.
# Ответить
6. Sergey.Noskov 06.08.2015 10:32
(1) baton_pk,
На текущий момент файл данных >4Тб
По железу можно посмотреть в проекте ЦКТП http://v8.1c.ru/expert/cts/cts-218-001.htm не один-в-один, но очень близко.
Из КИП еще пользовались стандартным нагрузочным тестом, под определенные задачи он подходит. ЦКК не использовали, присматриваемся.
Ответили: (17) (45)
# Ответить
7. kolya_tlt 06.08.2015 10:41
можно узнать подробности при переводе на 8.2? с какими трудностями столкнулись, что не учли помимо тестирования?
в чем он заключался, просто в конвертации? отказывались ли от совместимости?
в рамках проекта цктп какой франч участвовал ?
Ответили: (11)
# Ответить
8. Red_Devil 06.08.2015 10:45
(4) baton_pk, аа у них самописка, тогда конечно можно написать документ с 1 регистром =) Жаль в типовых такого не добьешься.
Ответили: (9)
# Ответить
9. Sybr 06.08.2015 10:56
(8) Скорее всего в этой самописке регистров больше чем в типовой УПП.
# Ответить
10. Sergey.Noskov 06.08.2015 11:40
(2) ivanov660,
1. RLS не используется. Разграничиваем двумя этапами - роли (предварительное разграничение) и регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.
2. В кластере один центральный сервер и 3 дополнительных. Из "особенностей" только то, что у центрального сервера нет rphost'ов (APDEX у пользователей, работающих на процессах центрального сервера, стабильно хуже чем на других серверах). Резервирование кластера не используем, рассматривали возможность - пугает большое количество негативных отзывов, поэтому надо делать тестирование на 3500+ юзеров. Сейчас отказоустойчивость обеспечивается количеством доп серверов (если один выходит из строя - кластер будет способен это пережить) и отсутствием процессов на центральном сервере.
3. Виртуализация только на терминальных машинах. Добавляли в кластер виртуальный сервер 1С, идентичный по железу, APDEX на нем был на 1 - 2% ниже.
4. Формы обычные, клиенты толстые)
5. Сложные запросы. Архитектура изначально строилась по принципам "нет лишним таблицам" и "зачем нам регистр, если все есть в документе", поэтому все не просто.

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

3000 пользователей у нас работали еще на 8.1 и все было отлично. Перефразируя классика, "роль управляемых форм в производительности сильно преувеличена" ;)
Ответили: (25)
# Ответить
11. Sergey.Noskov 06.08.2015 13:39
(7) kolya_tlt, Переход на 8.2.13, тот который делали своими силами, провалился из-за поведения кластера 1С - он отказывался балансировать сеансы. Все пользователи оказались на одном сервере - самом мощном по железу. Плюс кластер постоянно "тасовал" сеансы между процессами. Конфигурацию готовили без совместимости, все программные "нюансы" выловили при тестировании логики. Вот список замечаний, который мы в то время для себя составляли:

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


Привлечение ЦКТП изначально и обосновывалось необходимостью повысить стабильность работы платформы. Плюс мы решили вторую задачу - спрогнозировать поведение системы при двукратном увеличении количества пользователей (и производимой ими работы есессно).
Про франч - приводил ссылку на проект. Богачев Виктор (участвовавший эксперт) так же был на конференции и подробно рассказывал про это тестирование.
Ответили: (18)
+ 3 [ CratosX; Rustig; kolya_tlt; ]
# Ответить
12. DoctorRoza 06.08.2015 14:44
А вот мне стало интересно, ну что же это за контора то такая с такой базой? Энергетики или нефтяники что ли?
Ответили: (15)
# Ответить
13. Lostar 06.08.2015 14:46
(3) Red_Devil, ну так УПП ж. Ужасающе неоптимизированный продукт по производительности. Даже 5 пользователе могут рождать deadlock`и.
# Ответить
14. Lostar 06.08.2015 14:53
Автору огромное спасибо! Очень востребованная тема. Столько боли прожито с производительностью. Почему-то в нашей стране считается, что оптимизация sql это вопрос программистов 1С, хотя 101% из них не обладают не то, что достаточными, но даже начальными знаниями в этом вопросе.

Отдельное спасибо за скульные запросы. Будем пробовать.
# Ответить
15. Bronislav 06.08.2015 15:00
(12) DoctorRoza, "Деловые линии" - транспортная компания.
Ответили: (16)
# Ответить
16. Sergey.Noskov 06.08.2015 15:08
(15) Bronislav, раскрыл интригу)) приятно было быть нефтяником ;)
# Ответить
17. baton_pk 06.08.2015 19:01
(6) Sergey.Noskov,
На текущий момент файл данных >4Тб

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

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

PS. кстати, не пробовали dt-шку выгрузить ? :-D
Ответили: (26) (34)
+ 1 [ Rustig; ]
# Ответить
18. kolya_tlt 06.08.2015 20:39
(11) Sergey.Noskov, 1. в итоге какая версия платформы вела себя достаточно стабильно для текущей работы?
2. чем и зачем заменяли ОткрытьФормуМодально?
3. что подразумевается под "Исправить формат булево по умолчанию"?
Ответили: (35)
# Ответить
19. Rustig 06.08.2015 22:36
(0) Со всем уважением к автору и к его докладу!
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)
База самописная - это означает что с самого начала неоптимально и криво писалась прога?
Обновления еженедельно - из них половина это исправления текущих косяков разрабов?
Использовались ли управляемые формы? Что за формы списков были разработаны? Почему они тормозили? Наверное, налепили алгоритмов в процедуре ПриВыводеСтрок()....в итоге перешли на ПостроительОтчетов....дауншифтинг...
Ответили: (38)
# Ответить
20. Rustig 06.08.2015 22:44
Конечно запросы из форм списков были не единственными, мы переписали достаточно много запросов, а где то и архитектуру. Эта работа дала результат. Раньше, например, нагрузка на систему в понедельник и пятницу могла быть настолько высока, что приходилось отпускать домой некоторые отделы (менеджеров, колл-центр). А в результате проведенной оптимизации получилось снизить нагрузку в пятницу – проблем больше не было. Да и в понедельник мы тоже, со скрипом, но работали.


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

Штат разработчиков 20 человек. Сколько из них сертифицированы? Сколько из них с опытом свыше 3 лет программирования и консультирования? Вы извините , но 20 - ни о чем не говорит. А вот 20 профессионалов своего дела - уже впечатляет. :)
Ответили: (29)
# Ответить
21. Rustig 06.08.2015 22:50
(0) глава "Разделяй и властвуй" - очень поучительна!
# Ответить
22. Rustig 06.08.2015 22:57
обращайтесь в 1С, в рамках проектов ЦКТП достаточно оперативно устраняются и ошибки платформы и выявляются "узкие" места БД.


фирма 1с исправляет ошибки платформы исключительно для вас (в рамках договора цктп)? то есть вы остаетесь на том же релизе платформы, только с исправленными ошибками платформы? так что ли? при этом остальные компании исправления этих ошибок или получают с новыми релизами платформы, или не получают вовсе. правильно я вас понял?
Ответили: (28)
# Ответить
23. Rustig 06.08.2015 23:06
(0) ЦУП появился до управляемых форм.... Управляемые формы покамест тормозят и требуют дорогого железа..... неужели такой супер ЦУП не может выявить проблемы управляемых форм?....
какую помощь оказывает цуп? только лишь такую, что начинает контролировать разработку кривых запросов программистов....теперь их можно уволить - есть доказательства их некомпетентности ....
Ответили: (30)
# Ответить
24. Rustig 06.08.2015 23:11
регистр свойств пользователя для более детальной настройки. Механизм не гибкий, но у нас есть возможность продумать права на этапе разработки ТЗ и прописать в коде проверки на нужное значение свойства.


ужас... механизм не то чтобы "не гибкий", а спорный в использовании....
Ответили: (32)
# Ответить
25. Rustig 06.08.2015 23:12
(10) спасибо за подробности! смелый шаг!
# Ответить
26. Rustig 07.08.2015 00:45
(0), (17) 4 Тб - тоже ни о чем!
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков? Деловые линии работают по всей России и м.б. за рубежом...
свертку давно делали?...
половину инфы можно удалить из рабочей базы - номенклатура которая сто лет не используется, контрагентов, которые давно не существуют, документы прошлых закрытых периодов например за 2000 год.... кому они нужны в текущей рабочей менеджерской базе?....
есть архив, если надо оттуда все достанете, есть дублирующая база, из нее можно вытащить любые документы.....
я уверен, что можно обойтись без цупа
ЦФ-шник в студию - уверен, что косяков там достаточно....
Ответили: (27) (33) (36) (38) (45) (55)
# Ответить
27. Fox-trot 07.08.2015 07:34
(26) Rustig,
ЦФ-шник в студию - уверен, что ....

мальчик, может тебе ключи от дома дать, где деньги лежат? (с) не_моё
+ 2 [ Sibars; dgolovanov; ]
# Ответить
28. Sergey.Noskov 07.08.2015 07:37
(22) Rustig, Нет, выходит официальный релиз, никаких исключений.
# Ответить
29. Sergey.Noskov 07.08.2015 07:56
(20) Rustig, Статей и докладов на тему оптимизации запросов очень много. Не было смысла тратить время конференции, тем более сразу за мной на эту тему выступал Андрей Бурмистров.

Про команду - сильная команда, 7 экспертов (4 сертифицировались уже работая у нас). Но берем не за корочки вовсе, это не показатель.
# Ответить
30. Sergey.Noskov 07.08.2015 07:58
(23) Rustig, Где управляемые формы? И при чем тут ЦУП...
Ответили: (31)
# Ответить
31. Rustig 07.08.2015 09:50
(30) Сергей, я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается... в докладе нет анализа первопричины проблем, есть диагностический инструмент.... пусть мое мнение будет на ветке....
по поводу управляемых форм - это вопрос не к вам... это риторический вопрос ко всем кто работает с цупом и знаком с тормозами управляемых форм...
спасибо за доклад и статью, считаю ее полезным кейсом )) всего доброго
Ответили: (38) (76)
# Ответить
32. kolya_tlt 07.08.2015 09:56
(24) Rustig, прошу аргументировать и предложить вариант
# Ответить
33. baton_pk 07.08.2015 10:14
(26) Rustig,
есть много планов обменов, которые дублируют информацию....
классификатор адресов сколько съедает места?
классификатор банков?
номенклатура которая сто лет не используется, контрагентов, которые давно не существуют


поверьте, это всё такая мелочь :)
Ответили: (46)
# Ответить
34. Sergey.Noskov 07.08.2015 10:53
(17) baton_pk,
резервное копирование: долго делается, архивы занимают много места, в случае чего-то ужасного довольно небыстро разворачиваются

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

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

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

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

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

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

Попробую расскажу)
# Ответить
35. Sergey.Noskov 07.08.2015 11:02
(18) kolya_tlt, Версия платформы - начиная с 8.2.19.83, сейчас обновились на 8.2.19.130

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

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

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

В конфигураторе, Администрирование - Региональные установки, в 8.2 по умолчанию стоит Да и Нет - части пользователей не понравилось. Мы и цветовую схему настраивали максимально близко к 8.1
Ответили: (37)
# Ответить
36. kolya_tlt 07.08.2015 11:04
(26) Rustig, вы поймите, у оптимизации есть 2 пути:
1. отрезать лишние данные так как неоптимальный запрос их обрабатывает. отрезать можно тоже либо отказать от функциональной части, либо убрать старые данные
2. переписать неоптимальный запрос.
Думаю в проекты был выбран второй путь

ps косяки есть в любом цф-нике. вам зачем на них смотреть?
# Ответить
37. kolya_tlt 07.08.2015 11:08
(35) Sergey.Noskov, а может быть актуализируете список ? :) по возможности конечно.
1. зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?
2. "Не работает формат даты с использованием YYYY" не работает где? и как вообще такое искали в коде?)
Ответили: (39)
# Ответить
38. Sergey.Noskov 07.08.2015 12:13
(19) Rustig, (26) Rustig, (31) Rustig,
Обратная связь в виде вопросов. Это не критика, это уточнения деталей.
За тональность извините. :)

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

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

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

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

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

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

Есть конечно. Это и рост самой компании и потребностей в части функционала.
Ответили: (47) (49)
+ 1 [ Rustig; ]
# Ответить
39. Sergey.Noskov 07.08.2015 12:26
(37) kolya_tlt, список актуальный, выкиньте пункт ОткрытьФормуМодально(), ну а формат булево по умолчанию - дело вкуса))
зачем нужна "Проверить наличие везде проверки на ОбменДанным.Загрузка" ?

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

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

Ни в 8.2 не в 8.3 не работает, попробуйте выполнить Формат(ТекущаяДата(), "ДФ=dd.MM.YYYY")
Искали просто - глобальным поиском строку YYYY с учетом регистра.
+ 1 [ CratosX; ]
# Ответить
40. molodoi1sneg 07.08.2015 14:20
А бух. учет где ведется? Обмен?
Ответили: (41)
# Ответить
41. Sergey.Noskov 07.08.2015 15:22
(40) molodoi1sneg, Бух учет ведется в типовой, первичка грузится через обмен.
Ответили: (42) (44)
# Ответить
42. baton_pk 07.08.2015 16:09
(41) Sergey.Noskov,
ооо! а вот тут-то самая вкусняшка начинается!
двусторонний обмен? коллизии? блокировки при обменах? размеры пакетов?
Ответили: (43)
# Ответить
43. Sergey.Noskov 07.08.2015 16:25
(42) baton_pk, неа, не начинается)) Обмен односторонний + закрытие периода, поэтому блокировок и коллизий нет.
# Ответить
44. genayo 07.08.2015 20:43
(41) А вот тут интересно, для типовых конфигураций применяли такие-же методики анализа проблем?
# Ответить
45. a_titeev 08.08.2015 17:48
(26) Rustig,

классификатор адресов сколько съедает места?
классификатор банков?
Вы точно сталкивались с большими базами?
(6) Sergey.Noskov, замечательно. Отличный опыт. Спасибо что поделились. Пожалуй перейму пару идей :)
Ответили: (48)
# Ответить
46. Rustig 08.08.2015 20:30
(33) я не уверен, что мелочи.
мы с вами на разных уровнях работаем. это не плохо, это очень хорошо, особенно если я что -то полезное черпаю из ваших знаний.
это все мелочи, пока у вас есть деньги на железо, на штат сисадминов, на серверные субд... мне в своей практике приходится сталкиваться с файловыми базами, у них ограничение на 4 Гб. и тут я начинаю выдумывать всякие финтиплюшки - картинки и пдф-счета, договора выношу в другие базы (число баз для хранения картинок, образов, сертификатов и т.д. неограничено и постоянно растет), свертка-свертка-и еще раз свертка....
сейчас я понимаю, что о некоторых аспектах никто не задумывается, пока есть деньги на железо, на сисадминов, на лицензии серверов, на цуп... если вы скачаете кладр с официального сайта, получите файлы около 320 Мб. если закачаете часть регионов кладра в базу БП 2.0 получите увеличение базы на 1Гб и выше. просто задумайтесь, что для кого-то это уже не мелочи...
я понимаю, что в пон-к вы продолжите заниматься своими текущими задачами с базами 300 Гб, и продолжите строить планы, как их реиндексировать, понимаю, что вы возможно никогда не будете задумываться как поднять с колен файловую базу, которая весит 6,5 Гб....
Ответили: (48) (51)
# Ответить
47. Rustig 08.08.2015 20:32
(38) Вы точно уловили мое настроение! +
# Ответить
48. Rustig 08.08.2015 20:42
(45) ответил в (46)
сталкивался с базой 150Гб будучи в команде разработчиков, за производительность не отвечал, вел разработку подсистем.
в дальнейшем во фрилансе работал с клиентами, разрабатывал подсистемы на файл-серверных базах размеров 40-70 Гб. Приходилось консультировать клиентов как ускорить работу 1С - в моих руках не было цупа, только голова, оптимизация запросов, оптимизация бизнес-процессов и архитектуры новых подсистем.
при работе с файловыми базами сталкивался с падением производительности при достижении базы критического порога допустимых размеров. принимал активное участие в ликвидации последствий.
Я не системный администратор, я программист. и смотрю на данный кейс как программист...
# Ответить
49. Rustig 08.08.2015 20:46
(38) Сергей, у вас много точек продаж, по факту они работают с "потоковым" клиентом. Очень напоминает розницу. Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база, вся информация собирается в центральной базе и т.д. и тому подобное?
Ответили: (51) (52) (53)
# Ответить
50. Rustig 08.08.2015 20:58
(0) свяжу ваш кейс со статьей http://infostart.ru/public/387232/
так сказать на будущее
# Ответить
51. baton_pk 08.08.2015 21:18
(46) Rustig,
мы с вами на разных уровнях работаем

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

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

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

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

нафигнафигнафигнафиг! если есть возможность работать напрямую, лучше работать напрямую. разбить одну база на две - это уже довольно эпохальное решение, а разбивать её на десяток - ошибка и тоже довольно-таки эпичная. в статье от Старых, ссылку на которую вы тут привели, описано, что не всегда параллельность даёт нужную отдачу. в случае с базами - это немалые накладные расходы на обмен.
+ 1 [ Rustig; ]
# Ответить
52. a_titeev 08.08.2015 22:24
(49) Rustig, первый совет, с которого начинается книга Фаулера о распределенных системах звучит так - "не распределяйте системы! ну а если это по каким-то очень веским причинам невозможно, то для вас следующие 600 страниц текста". примерно так...
+ 5 [ Dach; dddxddd; Mi4man; sorb; Rustig; ]
# Ответить
53. Sergey.Noskov 10.08.2015 10:04
(49) Rustig,
Не думали представить всю вашу схему работы подразделений как сеть розничных точек продаж - на каждой точке своя небольшая база

Думали, точнее не так, правильнее сказать, что изначально именно так и было :)
Повторю фразу, которую сказал на конференции: те, у кого одна большая база думают над её разделение, а те, у кого распределенная система, думают над её слиянием. Потому что не бывает идеальной системы, минусы есть и там и там.
"Распределенка" это как раз из рубрики двусторонних обменов, коллизий и не актуальности данных. Сейчас движение в сторону функционального разделения.
+ 2 [ Sybr; Rustig; ]
# Ответить
54. capitan 11.08.2015 10:39
Два извечных вопроса интернета: Как? и Зачем ?
С периодичностью раз в полгода на различных евентах появляется человек с базой в десяток тысяч пользователей.
И что удивительно практически всегда там находится SoftPoint.
И ни разу докладчик не смог ответить на вопрос как и зачем оказалось такое количество пользователей в одной базе.
Кроме конечно желания генерального. Обычно он и говорит - хочу одну базу.
На самом деле, перед тем как глубоко мониторить SQL и программный код нужно провести аудит логического построения БД.
О чем и говорит уважаемый Rustig.
Нужно взять лист бумаги и в две колонки расписать пользователей, кому нужен реалтайм, а кому нет.
Кстати транспортная компания, это не онлайн торговля акциями на бирже. Здесь реалтайм ,если так можно выразиться помедленнее.
Кто работает 24/7, а кто 8/5.
Кто порождает данные, кто их изменяет, а кто их просто просматривает.
Кому какой период данных нужен.
После этого вы аккуратно разносите эту базу в пространстве и времени.
И все у вас взлетает.
И кстати это огромный плюс в безопасности ,т.к. одно дело следить за 3000 пользователей, а другое за 30.
Ответили: (59)
+ 1 [ Rustig; ]
# Ответить
55. Rustig 11.08.2015 13:18
(26)
4 Тб - тоже ни о чем!

Беру свои слова обратно: 4 Тб - тоже ни о чем!
Контекст изменился: 4 Тб это очень много, чтобы продолжать работать в том же духе и развивать систему. Кажется пора принимать серьезные меры по изменению ситуации. Проведу аналогию: для файловой базы критичен порог 4Гб, для файл-серверной пусть будет 4Тб... :))
Ответили: (58)
# Ответить
56. Xershi 11.08.2015 13:37
Прошу поправить
на одину
.
Ответили: (60)
# Ответить
57. МихаилМ 11.08.2015 13:41
автор, как решили проблему долгой реструктуризации ? и удаления доп.индексов после реструктуризации
Ответили: (63)
# Ответить
58. baton_pk 11.08.2015 18:00
(55) Rustig, аналогия в данном случае немного за уши притянута: для файловой базы ограничение в 4ГБ на одну внутреннюю таблицу - это ФИЗИЧЕСКОЕ ограничение, а 4ТБ для клиент-серверной - исключительно психологическое. База вполне может себе жить и пухнуть дальше до 40, 400, 4000. и если не заниматься доработками, связанными с реструктуризацией, то у платформы есть все возможности сделать так, чтобы пользователь не замечал разницы между большой базой и маленькой (речь, разумеется, не про типовые конфигурации :-D)
# Ответить
59. Sergey.Noskov 11.08.2015 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)
# Ответить
60. Sergey.Noskov 11.08.2015 18:14
(56) Xershi, исправил, спасибо
# Ответить
61. Painted 12.08.2015 10:49
Прямыми запросами к MS SQL не баловались? Или близость к 1С не позволяет? Или баловались, но вслух об этом не говорят?
Ответили: (64)
# Ответить
62. vec435 12.08.2015 10:52
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?
Ответили: (65)
+ 1 [ quick; ]
# Ответить
63. Sergey.Noskov 12.08.2015 12:16
(57) МихаилМ,
автор, как решили проблему долгой реструктуризации ?

У нас ограничение от бизнеса - полное время обновления не должно превышать 2ч. За 2 часа, на хороших дисках, успевает реструктуризироваться почти любой объект метаданных. Есть и объекты, которые за это время не успевают, их мало и чаще всего это что то из базового бизнес-процесса, который редко меняется.
Если надо больше двух часов - разделяем обновление по объектно, если и это не помогает, то эти изменения откладываются до больших праздников.
# Ответить
64. Sergey.Noskov 12.08.2015 13:53
(61) Painted,
Прямыми запросами к MS SQL не баловались?

Задач таких нет. Но раньше, в далекие времена 8.0 и когда веб сервисы плохо работали с большим количеством коннектов, то запросы сайта как раз и делали "прямые" запросы в базу-копию (раз в неделю разворачивали из бэкапа)
# Ответить
65. Sergey.Noskov 12.08.2015 14:06
(62) vec435,
а почему остались на 1С? может с таким штатом просмотреть что- то другое можно было?

Причин ровно две:
1. 1С справляется и при всех её недостатках она нам нравится.
2. Стоимость. Менять придется не только платформу, но и саму учетную систему, а это очень дорого и очень долго.
Ответили: (66)
+ 1 [ baton_pk; ]
# Ответить
66. genayo 12.08.2015 16:39
(65) Если не секрет, сколько у вас серверных ключей и сколько клиентских и каких, программных или аппаратных?
Ответили: (67)
# Ответить
67. Sergey.Noskov 12.08.2015 17:46
(66) genayo, Ключи программные. 4 серверных и 3500 пользовательских.
# Ответить
68. asved.ru 12.08.2015 18:05
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании. RDS?
Насколько стабильны показатели APDEX? Какое отклонение вы считаете заслуживающим реакции?
Спасибо.
Ответили: (73)
# Ответить
69. capitan 12.08.2015 22:09
(59) Sergey.Noskov, видел ответы ,некоторые улыбнули :) но не буду вдаваться в полемику, поберегу время.
Есть еще парочка вопросов:
1. Допустим сейчас вы полностью контролируете базу и всех 40 программистов, но предположим ваш сервер устал или что еще хуже - логический сбой БД.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?
Что в этот момент будут делать 3000 юзеров ?
И как вы собираетесь например тестировать БД, в 1С это не лишняя операция?
2. Есть такой закон - N 152-ФЗ. Пока вы работаете с юрлицами все неплохо, но как только в вашей базе появляется физ. лицо вам надо соответствовать.
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.
Ответили: (70)
# Ответить
70. Sergey.Noskov 13.08.2015 12:37
(69) capitan,
Вопросы выводят в плоскость почему одна большая БД плохо (может показалось?). Абсолютно согласен с тем, что у этой архитектуры есть недостатки. И у распределенной системы они так же есть. Наша практика показала, что с точки зрения бизнес процессов иметь единую базу выгоднее. Этот опыт никому не навязывается, просто показываю, что это реально.
Есть ли у вас понимание и Service Level Agreement с отделами за какое время вы восстанавливаете работу?

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

В рамках ЦКТП тест был на 5000 пользователей. Что должно этому мешать?
А у вас каждый из 3000 пользователей имеет на физическом уровне доступ к БД, значит от справочника например контрагентов его отделяет только пароль.

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

Вообще всегда интересны различные идеи и концепты, они позволяют "расширять сознание", поэтому если у вас есть какое то видение, как разом "побороть" все вышеописанные проблемы, напишите, любопытно.
Ответили: (71) (74)
# Ответить
71. Зеленоград 13.08.2015 13:00
(70) Sergey.Noskov, Капитан имеет в виду формальные проверки на соответствие (много мата пропущено) фз 152, к жизни не имеющего никакого практического отношения, но позволяющего за.. утомить, в общем - любого оператора персданных.

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


А сам на проверке с уверенным видом расказывал, что "архивов у нас нет, всё отлажено и работает без сбоев, поэтому процедуры удаления ПДн после отзыва согласия на обработку не нужны и отсутствуют". Коллеги сдержались, проверяющие изумились, но отвязались.
Ответили: (72)
# Ответить
72. Sergey.Noskov 13.08.2015 14:34
(71) Зеленоград, Это я понял, я не понял при чем тут 3000 пользователей. Видимо надо уволить 2970 сотрудников компании, ведь с 30 пользователями все намного легче)
# Ответить
73. Sergey.Noskov 13.08.2015 15:41
(68) asved.ru,
А как производится доставка приложения? Не все же 3000 пользователей у вас сидят в одном здании.

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

Показатели достаточно стабильны (исключение - время выполнения регламентных операций), в основном диапазон значений колеблется в нтервале 0,98 - 0,99.
Критичные отклонения - ниже 0,9. При 0,95 уже режим повышенного внимания. Но опять таки это наша специфика из-за большого количества пользователей. Грубо говоря APDEX 0,97 означает, что более 3% пользователей работают вне комфортной скорости. 3% это 90 пользователей, т.е. потенциально это 90 жалоб. Поэтому после внедрения APDEX'а была притирка - сопоставляли объем поступающих жалоб со значением показателя.
# Ответить
74. capitan 14.08.2015 11:40
(70) Sergey.Noskov, самым великим мастером давать ответы далекие по смыслу от темы вопроса был конечно Михаил Сергеевич, долгой ему жизни. И задолго до него известна фраза Райкина - Хотите меня поставить в тупик своими вопросами - так я вас поставлю в тупик своими ответами.
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.
Что касается требований ФЗ №152 - тут я адресую к гуглу. Рано или поздно вас об этом спросят и лучше иметь представление о том, что вы нарушаете.
Что касается видения - ваша структура в точь точь похожа на любого крупного ретейлера, за той разницей - что на пунктах выдачи вы товар принимаете, а не продаете.
На самом деле, если ваша должность была сисадин или DBA, DBA кстати пишут фолианты об оптимизации серверов, вопросов бы не было. Я бы первый поставил +, написал бы здесь красавчеГ и откланялся.
Но вы то руководитель отдела оптимизации и производительности систем, вам надо знать больше, чем то что одна база удобна в плане бизнес процессов.
Ответили: (75)
− 1 [ artbear; ]
# Ответить
75. Sergey.Noskov 14.08.2015 13:23
(74) capitan,
Тестирование - имелось в виду зайти в конфигуратор и запустить тестирование и исправление (?) информационной базы.

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

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

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

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

Про распределенку.
Если разговор зашел про недостатки больших баз, то всем (без сарказма - мне тоже) будет полезно увидеть как подобные проблемы решаются в распределенных системах и в чем их профит.
Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая.
Ответили: (77)
# Ответить
76. ZLENKO 14.08.2015 13:28
(31) Rustig, "я не пользуюсь цупом. Вокруг цупа и других инструментов анализа производительности субд много шума. я прихожу к клиенту, исправляю кривые запросы или архитектуру базы, или логику - решение точечное - производительность увеличивается..."

Придерживаюсь аналогичного мнения. С ЦУП приходится повозиться чтобы его запустить и постоянно натыкался на глюки ЦУП. Быстрее всего текущую картину можно получить по Монитору активности в MS SQL Server - самые длительные запросы.
Ответили: (78)
# Ответить
77. ZLENKO 14.08.2015 13:30
(75) Sergey.Noskov, "Мои доводы против распределенки:
- двух сторонние обмены и как следствие конфликты изменений;
- увеличение парка серверов и баз данных;
- требуется больше серверных лицензий;
- процесс обновления более трудоемок за счет увеличения количества баз.
При этом все равно появляется центральная база - с меньшим количеством пользователей, но такая же большая."

Думаю аналогично.
Ответили: (79)
# Ответить
78. Sergey.Noskov 14.08.2015 14:15
(76) ZLENKO, Монитор активности пользуется теми же динамическими представлениями (dm_exec_query_stats и dm_exec_requests) только более сложно агрегирует получаемые данные.
Можно посмотреть в хранимку tempdb.dbo.#am_get_querystats_...
Сталкивались с тем, что монитор активности сам создаёт нагрузку, особенно если интервал обновления маленький и он открыт у нескольких человек.
# Ответить
79. genayo 14.08.2015 15:59
(77) На самом деле, часть из этих проблем решаема, приведу пример как это решено у нас (продуктовая дистрибуция), несколько филиалов:

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

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

Автор конечно молодец, очень интересный кейс, но по моему личному мнению 3500 пользователей в одной базе - это несколько перебор :) и бездумно брать этот пример и пытаться повторить не стоит...
Ответили: (80) (81)
# Ответить
80. Sergey.Noskov 14.08.2015 16:52
(79) genayo,
Спасибо за опыт. Все имеет право на жизнь, и у всего есть как минусы так и плюсы.

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

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

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

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

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

Главное то, что кластер 1С справляется с этой задачей. У многих есть опасения именно это момента.
# Ответить
81. Sergey.Noskov 14.08.2015 17:18
(79) genayo, не могу удержаться от off топа)
бездумно брать этот пример и пытаться повторить не стоит...

Бездумно - нет! Но пробовать и повторять - однозначно стоит! Сейчас для этого есть все инструменты и даже поддержка от 1С (ЦКТП). Чем больше будет подобный кейсов, тем лучше.
Ответили: (82)
# Ответить
82. genayo 14.08.2015 21:21
(81) У меня есть аргументы против такой точки зрения, но тема то конечно не про это, поэтому здесь их высказывать не буду. Позволю себе еще один вопрос вдогонку - вы хотя-бы гипотетически рассматриваете переход на 8.3, или вы считаете, что без новшеств, добавленных в 8.3 можно прожить (себе я тоже кстати этот вопрос задаю, однозначного ответа у меня пока нет...)?
Ответили: (83)
# Ответить
83. Sergey.Noskov 17.08.2015 10:32
(82) genayo,
Переход на 8.3 рассматривается. Интересны не столько программные "фишки", сколько оптимизация платформы и возможности кластера. Например в платформе изменена работа с временными таблицами (создается кластерный индекс и сам индекс не удаляется после выполнения запроса), наличие физических таблиц срезов. А в кластере привлекает возможность разделения функций по отдельным серверам.
# Ответить
84. Irwin 17.08.2015 11:18
Можно узнать подробнее про процесс разработки?
Какие проблемы возникают с таким большим количеством людей разработчиков в одной базе (у вас ведь одно хранилище или вы пользуетесь другими средствами совместной разработки)?
Как планируется время на выполнение задачи с учетом того, что (мое предположение) часто нужные объекты бывают захвачены другими разработчиками (а ведь еще есть тестирование)?

ИМХО, увеличение количества программистов, работающих в одной базе, с определенного момента должно экспоненциально увеличивать время разработки при использовании хранилища. Наверное, есть то число, после которого уже увеличение количества разработчиков бессмысленно. Хотелось бы услышать Ваше мнение по этому поводу.
Ответили: (85)
+ 2 [ artbear; baton_pk; ]
# Ответить
85. Sergey.Noskov 17.08.2015 14:48
(84) Irwin, не все программисты работают на одну базу. У нас есть и типовые и несколько баз помельче. В этой базе, если не ошибаюсь, порядка 15 разработчиков.
Работаем через хранилище. Снижение конкуренции за объекты достигается разделением кода на логические блоки (функциональные подсистемы) и их выносом в отдельные модули. Для особо популярных объектов разделение вплоть до того, что каждая печатная форма в своем модуле. Плюс есть специализация разработчика, т.е. задачи в рамках одной подсистемы "придут" одному разработчику.

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

ИМХО, как и при работе пользователей, количество блокировок при разработке зависит от архитектуры конфигурации.
# Ответить
86. Slon1c 03.09.2015 14:22
Ничего удивительно ни в размере базы, ни в количестве пользователей нет. Наслышан об успешной оптимизации и рефакторинге кода от непосредственных исполнителей. На сегодняшний день очень много крупных компаний использующих 1С с объемами баз свыше 1 Тр и количеством пользователей от 500 (данные на одну базу). Есть компании в которых используются более 120 независимых баз между которыми осуществляется онлайн обмен. Реструктуризация больших таблиц средствами 1С - процедура долгая и утомительная. Даже при хорошем железе добавление нового реквизита в 1С с простым типом - несколько часов при объеме таблицы свыше 100 Гб и количестве записей от 80 млн. и более, естественно используются другие возможности. Это уже не говоря об удалении такого реквизита :), с проверкой логической и ссылочной целостностью базы. Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ? Используете data кластер от SoftPoin ? По заголовку запросов и происходит разделение (перенаправление) на различные сервера СУБД ? Как обошли отчеты в которых требуется создавать промежуточные временные таблицы ?
Ответили: (87)
# Ответить
87. Sergey.Noskov 05.09.2015 17:41
(86) Slon1c,
Удивительного нет, для того и доклад готовился, дабы меньше удивлялись. Чем больше примеров будет, тем лучше для сообщества.
Реструктуризацию используем только типовую, причин несколько, но основная - добавление колонки в существующую таблицу SQL возможно только с типом "содержит NULL", это может привести к построению плана запроса с избыточными операциями.
Насколько понимаю - большинство информации находится в документе, регистры задействованы минимально. Это так ?

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

Дата кластер действительно отличная штука, ей бы добавить признание от самой 1С и совместно создать мощный инструмент. На текущий момент оптимизация кода дала такой эффект, что мы можем работать и без отчетной базы и без дата кластера, но обе технологии повышают запас прочности и надежность системы в целом (плюс "горячий" бэкап), поэтому и остаются в строю.
# Ответить
88. dablack 16.12.2015 09:30
Сергей, подскажите пожалуйста, вы описывали, что у вас достаточно много запросов со стороны сайта к web сервисам 1с. Хотелось бы узнать поподробнее, что используется IIS, Apache?
Какое примерно к-во запросов в минуту/час ? С какими проблемами в этой связке столкнулись?
Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Ответили: (89) (90)
# Ответить
89. Sergey.Noskov 25.12.2015 13:18
(88) dablack,
>Хотелось бы узнать поподробнее, что используется IIS, Apache?
Apache.
>Какое примерно к-во запросов в минуту/час ?
Запросов к веб серверам, со слов их админа, порядка 1500/минуту.
>С какими проблемами в этой связке столкнулись?
Работает достаточно надежно. Основное, с чем боролись - настройка таймингов. Суть проблемы (упрощенно) - если запрос выполняется дольше указанного в настройках веб сервера тайм аута, то число коннектов от веб сервера к базе увеличивается. Увеличиваться может до "бесконечности". Для объективно долго выполняющихся сервисов увеличивали тайминг + оптимизация кода и запросов.
# Ответить
90. Sergey.Noskov 25.12.2015 18:32
(88) dablack,
>Не рассматривали в перспективе (после перехода на 8.3 конечно) в качестве альтернативы обычного клиента 1с, для тех пользователей которым нужен ограниченный функционал, что то построенное на вебе, например http://www.oknosoft.ru/metadata/ ?
Специально никто переписывать обычного клиента не будет - работа ради работы (да простят меня фанаты тонкого клиента и управляемых форм). Остальное будет рассматриваться в рамках запрашиваемой функциональности, если по условию задачи лучшим выходом будет metadata, то в эту сторону и будем смотреть.

>И еще вопрос, делалась ли у вас какая либо интеграция 1с с телефонией ?
Тут все просто. Самописная dll для работы через API CISCO. 1с тут играет роли "выгрузить очередь для обзвона" и "найти клиента по номеру телефона и отобразить данные".
# Ответить
91. goodron 29.12.2015 21:55
Про это:
Виктор Богачев, Проект по нагрузочному тестированию 1С 8 для 5000 пользователей в одной ИБ
http://www.youtube.com/watch?v=0KN5DdkbS2g
+ 1 [ Sergey.Noskov; ]
# Ответить
92. zhichkin 17.01.2016 23:46
Сергей, Вы пишете:
Улучшили подсистему репликации и добились актуальности данных в 2 – 3 минуты, что значительно расширило список перенаправляемых отчетов. Доработки в основном были нужны потому, что стандартный метод "ВыбратьИзменения" планов обмена создает большое колличество блокировок.

Вопрос:
Уточните, пожалуйста, какие именно блокировки имелись ввиду? Какие транзакции ожидали освобождения этих блокировок? Конкретно каким образом удалось решить эту проблему? Неужели отказались от использования этого метода? А что использовали взамен?
Ответили: (93)
# Ответить
93. Sergey.Noskov 18.01.2016 16:02
(92) zhichkin,
Мешали в основном блокировки, возникающие из-за подобных запросов:
UPDATE T1 SET _MessageNo = @P1
FROM _DocumentChngR18294 T1
WHERE T1._NodeTRef = @P2 AND T1._NodeRRef = @P3 AND T1._MessageNo IS NULL

Этот запрос присваивает номер сообщения всем новым записям в таблице регистраций изменений. Проблемы возникали в случаях:
1. эскалации блокировок при большом числе записей в таблице;
2. при программной регистрации изменений (код ПланыОбмена.ЗарегистрироватьИзменения(...)) когда от момента регистрации и до фиксации транзакции выполняются какие либо длительный процедуры;
3. при модификации в одной транзакции нескольких объектов (например при проведении документа надо перепровести другой док, либо вызвать явную запись регистра), фактически это частный случай п.2;
4. кривые планы запросов из-за частой модификации таблицы - записи то добавляются, то удаляются, таблица регистрации изменений часто может быть пустой - есть риск, что план запроса построится для пустой таблицы и, как следствие, получим закешированный план со сканом кластерного индекса.

Как сделано, схематично: выборка запросом порции (обычно 100 элементов) измененных элементов для конкретного объекта метаданных, далее устанавливается упр блокировка на эти данные и считываются объекты из БД. Осталось их сериализовать и передать по СОМ в базу-приемник, затем удалить регистрацию изменений и снять блокировку.
Ответили: (94)
+ 1 [ Dpotapov; ]
# Ответить
94. zhichkin 18.01.2016 23:38
(93) Sergey.Noskov,
Спасибо за подробный ответ!
Интересный способ решения проблемы. Мы в своё время пошли более сложным путём, но исключили блокировки таблицы регистрации изменений на 100%. Для этого был создан регистр сведений, который имел измерение версии. Таким образом полностью исключается конкуренция между читателями и писателями. Правда возникают другие нюансы, например, увеличение объёма данных. Кроме этого из нескольких изменений одного и того же объекта нужно уметь получить одно результирующее.
# Ответить
95. WellMaster 04.05.2016 09:52
Прочитал с удовольствием. Познавательно. Спасибо.
# Ответить
Внимание! За постинг в данном форуме $m не начисляются.
Внимание! Для написания сообщения необходимо авторизоваться
Текст сообщения*
Прикрепить файл