За последнее время мы часто сталкивались с массовым перемещением документов, например, с файловых серверов на SharePoint. Одна из самых частых жалоб пользователей при таких задачах заключается в том, что загрузка бывает очень медленной, особенно если загружается большое количество документов. Я думаю, настало время поговорить о производительности при таких масштабных загрузках. Это нехарактерный сценарий для бизнеса — большинство организаций не выполняет подобных действий слишком часто, но здесь есть несколько ключевых моментов, о которых стоит рассказать.
Ниже перечислено несколько самых распространенных причин снижения производительности при массивных загрузках.
1. Модель восстановления базы данных контента (настройка SQL Server) установлена по умолчанию в режим полного восстановления. Хотя это безусловно самая подходящая настройка для производственной среды, поскольку позволяет выполнять восстановление с помощью журнала транзакций, она может замедлять загрузку контента при перемещении документов. Можно установить более простой режим восстановления, при котором будет происходить усечение контента в журнале транзакций каждый раз, когда база данных проходит контрольную точку. При этом важно помнить о двух вещах. Во-первых, верните процесс восстановления на уровень Full, когда перенос закончится. Во-вторых, имейте в виду, что этот режим означает, что точка восстановления базы данных может быть такой же недавней, как и последняя копия базы данных, поэтому, вероятно, вы захотите выполнить резервирование до того, как начнете перемещение. Кстати, для этого есть и другие причины.
2. Индексирование поиска, если оно вдруг запустится, потребляет ресурсы, которые вам могут понадобиться на серверах WFE и SQL Server для выполнения процесса перемещения файлов. Убедитесь, что задания поиска запланированы на выполнение должным образом, либо приостановлены во время массовой загрузки файлов.
3. Антивирусное программное обеспечение, если оно сканирует каждый документ при его загрузке либо напрямую базу данных и хранилище BLOB, может значительно затормозить производительность системы. Принимая во внимание, что все ваши документы были просканированы, когда были загружены в исходное место, вероятно, нет необходимости выполнять эту операцию еще раз, когда вы просто перемещаете эти документы в SharePoint.
4. Хранилище BLOB может влиять на производительность в лучшую или худшую сторону. Я не раз писал о хранилище BLOB и масштабируемости базы данных контента. Различные BLOB (бинарные большие объекты) являются двоичным неструктурированным куском данных, который как документ хранится в SQL Server в таблице AllDocStreams базы данных контента. Различные BLOB можно хранить раздельно, используя EBS или RBS, это будет означать, что вы храните их не вместе с базой данных контента, а база данных получает указатель на этот документ. Когда вы храните BLOB раздельно, вы снижаете количество записей в базе данных. По умолчанию, когда вы загружаете документ, он сначала записывается в журнал транзакций, а потом подтверждается его попадание в базу данных. Это две записи для каждого документа. Раздельное хранение BLOB дает концептуальное преимущество в производительности. Однако данный метод зависит от производительности хранилища, в которое вы перемещаете BLOB, а также от производительности провайдера EBS или RBS (программного обеспечения, управляющего взаимодействием EBS/RBS, которые являются интерфейсами Microsoft API, и платформой хранения BLOB). Например, если вы раздельно храните BLOB в «облачном» хранилище наподобие того, которое есть у Amazon или Rackspace, то производительность наверняка пострадает. Однако если вы раздельно храните эти объекты на высокопроизводительной системе, то при таком сценарии производительность в случае массовых загрузок значительно улучшится.
5. Рост базы данных. Установленные по умолчанию размер и настройки увеличения базы данных SQL не подходят для большинства баз данных SharePoint, особенно для тех, которые содержат BLOB. Установите размер своей базы контента примерно таким же, какой хотите загрузить. Продумайте, какой объем пространства потребуется для метаданных. Таким образом, при загрузке SQL Server не заставит базу данных «растягиваться» — объем для хранения уже предусмотрен. Кстати, замечу, что увеличение и размер базы данных влияют на производительность, по мере того как ваша среда масштабируется. Существует несколько рекомендаций, которые помогают определить подходящую настройку. Я рекомендую задать исходный размер, который совпадает с ожидаемым размером контента (включая метаданные и BLOB, которые хранятся в SQL Server) на протяжении первых месяцев работы, и 10-процентное увеличение этого размера. Но будьте осторожны: существует очень много переменных в этом исчислении, которые зависят от варианта использования.
6. Производительность хранилища может влиять на загрузку. Подумайте над креативными решениями: например, перемещением базы данных, в которую вы осуществляете загрузку, на отдельные диски, в отдельный экземпляр SQL Server или на отдельный сервер SQL Server во время загрузки. Затем переместите все это в «конечную точку» после завершения загрузки. Помните, что вы можете выполнить процесс перемещения в лаборатории, а потом перенести базу данных контента в производственную среду. Просто отсоедините и затем присоедините вновь базы данных контента.
7. Внешний веб-сервер (WFE) может быть «бутылочным горлышком». Поразмыслите над загрузкой на внешний веб-сервер, который не сильно нагружается пользователями (хотя обычно узкое место приходится на сторону SQL Server), вы можете выполнить перенаправление с помощью DNS или настройки балансировки нагрузки.
8; Причина может быть в соединении WFE и SQL Server. Используйте специальную высокоскоростную сеть (GbE или 10GbE) между серверами WFE и SQL Server. Примените объединение адаптеров, если сетевые платы поддерживают этот режим.
9. Клиентская сторона может быть узким местом, так как иногда требует загрузки того, что не поддается балансировке нагрузки. Подумайте о запуске процесса перемещения прямо на WFE или на нескольких клиентах, что зависит от вашей инфраструктуры.
10. Исходный сервер может замедлять работу. Просмотрите все предыдущие пункты и выясните, откуда забираются файлы. Например, следует ли выполнять загрузку с файлового сервера? Нужно ли перемещать или копировать файлы на диски, которые являются локальными для WFE с целью достижения максимальной производительности процесса загрузки? Такой вариант двухступенчатого процесса загрузки может помочь осуществлять перемещение в течение заданного времени.
Надеюсь, эта статья подскажет вам несколько идей для выполнения сценариев массовой загрузки. Конечно, еще очень многое можно рассказать о производительности, и SQL Server в том числе. Я хотел бы поблагодарить моего коллегу Рэнди Уильямса за помощь в написании данной статьи и предложить вам ознакомиться с его разработками по оптимизации SQL для SharePoint по адресу http://www.slideshare.net/hawaiianmetal/optimizing-sql-server-2008-for-blazing-fast-sharepoint-sites.
Дэн Холм (danh@intelliem.com) — директор консалтинговой службы Intelliem, которая проводит консультации для предприятий, внедряющих SharePoint, Office, Windows и Active Directory