Share via

Мониторинг и настройка производительности

  • Статья

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

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

  • Определение базовых планов производительности

  • Наблюдение и настройка в целях достижения или превышения базовых планов

Конфигурация

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

Вопросы настройки сервера и сети

  • Обеспечьте применение на каждом компьютере адекватной подсистемы ввода-вывода и правильное размещение файлов базы данных.

    Как правило, скорость чтения и записи изменений на диск важнее по сравнению со скоростью передачи данных по сети, поэтому очень важно иметь достаточно производительную подсистему ввода-вывода. Рекомендуется использовать несколько дисковых массивов RAID и предусмотреть по одному выделенному массиву на сервере для базы данных tempdb, пользовательских баз данных и журналов транзакций. База данных tempdb, пользовательские базы данных и журналы транзакций должны быть созданы на основе отдельных файловых групп. Если обнаруживается, что одна или несколько пользовательских таблиц создают узкое место в обработке данных, то следует предусмотреть перемещение их в отдельные файловые группы.

  • Для компьютеров в топологии синхронизации рассмотрите возможность добавления памяти.

    Это особенно важно для тех серверов, которые участвуют во многих параллельных сеансах синхронизации. Сеансы синхронизации обычно связаны с применением продолжительных транзакций, поэтому важно предусмотреть существенный объем памяти, непосредственно адресуемый для базы данных сервера. Что касается SQL Server, рассмотрите возможность использование параметра /3GB для 32-разрядных систем или перехода на 64-разрядную систему. Дополнительные сведения см. в разделе «Адресное пространство процесса» электронной документации SQL Server.

  • Задайте минимальный и максимальный объем памяти, выделенный для базы данных сервера.

    Например, по умолчанию в компоненте Database Engine предусмотрено динамическое изменение требований к памяти с учетом доступных системных ресурсов. Чтобы исключить случаи отсутствия доступной памяти во время операций синхронизации, используйте параметр min server memory, чтобы задать минимальную доступную память. Во избежание размещения на диске страниц системной памяти можно также установить максимальный объем памяти с помощью параметра max server memory. Дополнительные сведения см. в электронной документации по SQL Server.

Проектирование базы данных и приложений

  • Следуйте рекомендациям по разработке баз данных.

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

  • Установите для базы данных подходящие значения времени ожидания блокировки и времени ожидания запроса.

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

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

    • Обновление таблицы только в одном узле.

    • Фильтрация данных таким образом, чтобы только один узел обновлял определенный набор строк. Например, в клиент-серверном режиме работы можно секционировать данные по горизонтали в разрезе клиентов, чтобы каждый клиент изменял только относящийся к нему «срез» данных, например контактную информацию о заказчиках в Вашингтоне.

  • Используйте фильтрацию продуманно.

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

  • Осмотрительно используйте логику приложения в триггерах и запросах синхронизации.

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

  • Используйте хранимые процедуры для выполнения команд базы данных.

    В Sync Framework используется несколько запросов для выборки и применения изменений данных и метаданных в течение сеанса синхронизации. Если вы создаете эти запросы вручную, инкапсулируйте их в хранимых процедурах. Это, как правило, позволяет достичь более высокой производительности и повысить удобство сопровождения, а также может способствовать улучшению защиты приложения. Если для конкретного приложения требуется встроенный код SQL вместо хранимых процедур, обязательно применяйте метод Prepare() ADO.NET для всех команд. Благодаря этому производительность встроенного кода SQL повышается.

  • Используйте массовое применение изменений

    Sync Framework использует для применения операций вставки, обновления и удаления к базам данных SQL Server 2008 и SQL Azure возвращающие табличное значение параметры. Эта функция обеспечивает возможность применения нескольких изменений к базе данных за один вызов хранимой процедуры. Это позволяет значительно повысить производительность и сократить число циклов приема-передачи между клиентом и сервером при применении изменений. Если массовое применение невозможно, то Sync Framework возвращается к применению по одному элементу. Если массовое применение изменений нежелательно, передайте значение false в аргументе SqlSyncScopeProvisioning..::..SetUseBulkProceduresDefault перед провизионированием базы данных, и тогда процедуры массового применения создаваться не будут.

  • Синхронизируйте только данные, которые требуются в каждом узле.

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

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

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

    • Orders и OrderDetails

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

    • Pricing

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

    • Products

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

Примечание

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

  • По отношению к DbSyncProvider следует использовать SelectTableMaxTimestampsCommand для оптимизации перечисления.

    Запрос, который задан для этого свойства, выбирает максимальную отметку времени из каждой базовой таблицы или таблицы отслеживания. Эта отметка времени используется для определения того, имеются ли уже в назначении для каждой таблицы все изменения из источника. Если в назначении уже имеются изменения, платформа Sync Framework зачастую может избежать выполнения запросов перечисления, что повышает производительность.

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

    По умолчанию платформа Sync Framework передает изменения на каждый узел в виде отдельного объекта DataSet. Пока изменения применяются к узлу, этот объект хранится в памяти. Такое поведение по умолчанию вполне применимо, если компьютер, на котором применяются изменения, располагает достаточным объемом памяти, а соединение надежное. Однако для некоторых приложений удобнее, если изменения разделены на пакеты. Пакетирование вводит дополнительные издержки, но может фактически способствовать повышению производительности некоторых приложений. Дополнительные сведения см. в разделе Как доставить изменения в пакетах (SQL Server).

  • Разнесите по времени расписания синхронизации.

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

  • Используйте подходящие расписания очистки метаданных.

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

Базовые планы

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

  • Задержка. Время, которое требуется для распространения данных между узлами в топологии.

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

  • Параллелизм. Количество узлов, которые могут одновременно синхронизироваться с конкретным узлом. Эта величина часто определяет количество клиентов, которые могут синхронизироваться с конкретным сервером.

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

  • Потребление ресурсов. Аппаратные и сетевые ресурсы, используемые в результате осуществления синхронизации.

В зависимости от конкретного приложения, некоторые из этих показателей производительности могут быть более или менее важны, чем другие. Например, может оказаться допустимым иметь относительно низкую пропускную способность, при условии что обеспечивается поддержка высокого уровня параллелизма. Устанавливая базовый план, следует учитывать, что платформа Sync Framework не предназначена для использования в качестве межсерверной системы с низкой задержкой и высокой пропускной способностью, подобно системе репликации транзакций SQL Server. Она предназначена для синхронизации клиента с сервером и клиента с клиентом, которая поддерживает приложения вне сети и приложения для совместной работы.

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

Наблюдение и сопровождение

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

  • События синхронизации

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

    • События в расчете на каждую таблицу на каждом поставщике. SelectingChanges, ChangesSelected, ApplyingChanges и ChangesApplied.

    • События в расчете на каждый сеанс на каждом поставщике. SyncProgress

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

  • Приложение SQL Server Profiler

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

  • SQL Server Management Studio

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

  • Системный монитор

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

    • Счетчики при работе с SQL Server. Диспетчер памяти. Например, можно проверить, используется ли в SQL Server доступная память, сравнив показатели «Память целевого сервера» и «Общая память сервера».

    • Счетчики при работе с PhysicalDisk. Например, значения «Средняя длина очереди чтения диска» и «Средняя длина очереди записи на диск» помогут выяснить источник ограничения производительности синхронизации — подсистема ввода-вывода или недостаток памяти в компьютере. Если значения длин очередей выходят за разумные рамки, рассмотрите возможность добавления памяти и модернизации или добавления дисков.

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

    • Счетчики при работе с SQL Server. Транзакции. Например, значения «Транзакции моментальных снимков» и «Размер хранилища версий» могут использоваться для определения того, вызывают ли запросы перечисления изменений большое увеличение размера tempdb. В запросах перечисления изменений используются транзакции моментальных снимков, а информация о версии снимка хранится в базе данных tempdb. Наличие большого хранилища версий означает, что может потребоваться изменение размеров базы данных tempdb.

    • Счетчики при работе с SQL Server. Блокировки. Например, значения «Время ожидания блокировки» и «Количество взаимоблокировок» могут использоваться для определения того, вызывает ли конкуренция проблемы при параллельном выполнении операций в базе данных.

  • Отслеживание синхронизации

    Платформа Sync Framework предусматривает применение отслеживания, которое осуществляется на основе класса TraceListener. Отслеживание может использоваться для сбора информации о сеансах синхронизации, которая может оказаться полезной для мониторинга и устранения неполадок в работе. Но следует учитывать, что отслеживание связано с дополнительными издержками, поэтому должно использоваться прежде всего в процессе разработки. Дополнительные сведения см. в разделе Трассировка процесса синхронизации (этот раздел в основном посвящен DbServerSyncProvider, но содержащаяся в нем информация применима также к другим поставщикам).

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

  • В зависимости от степени дефрагментации, реорганизовывайте или перестраивайте индексы на базовых таблицах и таблицах метаданных.

  • Обновляйте статистические данные индексов.

  • Очищайте метаданные синхронизации.

См. также

Другие ресурсы

Рекомендации по разработке и развертыванию приложений