Как фрагментация на неправильно отформатированных томах NTFS влияет на Exchange

Artikel
03/09/2011

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

Для начала вот некоторые проблемы, которые вы можете увидеть:

• Отказ базы с сообщением «Недостаточно памяти» (Databases failing with an Out of Memory condition )
• Чрезвычайно медленное применение логов к копиям в кластере CCR/SCR (Большая длина очередей) (Extremely slow log replay times on CCR/SCR replica copies (High replay queue lengths))
• Очень большое число операций ввода/вывода на одном LUN/томе (High amount of split I/O’s occurring on any given LUN/Volume. )
• Сильное замедление операций RPC вплоть до недоступности сервиса Information Store (Slowly rising RPC requests until the Information Store service goes unresponsive)

Примеры

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

Event Type:         : Error
Event Source:      : MSExchangeIS
Event Category:     : None
Event ID     : 1160
Description:
Database resource failure error Out of memory occurred in function JTAB_BASE::EcUpdate while accessing the database "CCRName\SGName".

Windows 2003 based error
Event Type:        Error
Event Source:    ESE
Event Category:                General
Event ID:              482
Description:
MSExchangeIS (9228) DBName: An attempt to write to the file "F:\Data\DBName.edb" at offset 530157682688 (0x0000007b6fdc4000) for 8192 (0x00002000) bytes failed after 0 seconds with system error 1450 (0x000005aa): "Insufficient system resources exist to complete the requested service. ". The write operation will fail with error -1011 (0xfffffc0d). If this error persists then the file may be damaged and may need to be restored from a previous backup.

Windows 2008 based error
Log Name:      Application
Source:        ESE
Event ID:      482
Task Category: General
Level:         Error
Description:
Information Store (8580) DBNAme: An attempt to write to the file "F:\Data\DBName.EDB" at offset 315530739712 (0x0000004977190000) for 32768 (0x00008000) bytes failed after 0 seconds with system error 665 (0x00000299): "The requested operation could not be completed due to a file system limitation ". The write operation will fail with error -1022 (0xfffffc02). If this error persists then the file may be damaged and may need to be restored from a previous backup.

Что же это за ошибка Insufficient system resources exist to complete the requested service? Объяснение будет позже.

Вот пример очень большого количества операций Split I/O (пурпурная линия), приведших к очень большому числу запросов RPC (зеленая линия) вплоть до того, что сервер перестал отвечать. В этом примере мы пытались увеличить размер базы данных и не смогли по причине, которую я вскоре объясню.

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

Эта конкретная проблема не является очевидной и требует объяснения происходящего на нескольких уровнях, а также требует некоторого разъяснения терминологии прежде, чем мы продолжим. На самом нижнем уровне база Exchange располагается на разделе NTFS, который настраивается, когда сервер впервые конфигурируется. Для выполнения этой первоначальной настройки существуют конкретные руководства о том, как правильно разбить и отформатировать тома https://technet.microsoft.com/en-us/library/bb738145(EXCHG.80).aspx для Exchange 2007 и https://technet.microsoft.com/en-us/library/ee832792.aspx для Exchange 2010. Два наиболее важных фактора – это выравнивание раздела (partition alignment) и размер блока NTFS (NTFS Allocation unit size).

Ниже приведена таблица рекомендаций для использования с Exchange:

Описание	Рекомендуемое значение
Storage Track Boundary	64 Kбайт или больше (рекомендуется 1 Мбайт)
NTFS allocation unit/cluster size	64 Кбайт (дисик с базами данных и журналами)
RAID Stripe size	256 Кбайт и больше (используйте рекомендации производителя системы хранения)

NTFS allocation unit size

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

• Прочитайте две первых секции (NTFS Architecture and NTFS Physical Structure) How NTFS Works в https://technet.microsoft.com/en-us/library/cc781134(WS.10).aspx
• Прочитайте раздел The Four Stages of NTFS File Growth в https://blogs.technet.com/b/askcore/archive/2009/10/16/the-four-stages-of-ntfs-file-growth.aspx

Теперь, когда мы рассмотрели, что собой представляет File Attribute List (ATTRIBUTE_LIST), и как файлы на самом деле хранятся на диске, мы можем объяснить, почему это так важно в нашей ситуации. Предположим, что мы имеем диск, отформатированный с размером блока 4К или 4096, который является размером по умолчанию в Windows 2003 для любого раздела больше, чем 2 Гбайт. В случае, когда размер страницы ESE в Exchange 2007 равен 8К, нам нужно будет сделать две операции записи для одной страницы. Эти операции записи могут быть, а могут не быть последовательными (contiguous) по своему характеру и могут вызвать распределение информации по разным частям диска, и это и есть причина начала фрагментации больших файлов на диске. Т.к. File Attribute List (FAL) растет за пределами MFT вместе с размером файла базы, размер FAL будет последовательно расти, чтобы соответствовать фрагментации и общему увеличению размера файла базы.

Для каждого файла NTFS имеет ограничения на общий размер этого списка атрибутов и может иметь около 1,5 млн фрагментов. Это не абсолютный максимум, но это то значение, около которого могут возникнуть проблемы. Размер FAL никогда не будет уменьшаться и будет постоянно расти с течением времени. Максимально поддерживаемый размер ATTRIBUTE_LIST составляет 256K или 262144. Если бы вы достигли этого верхнего предела, то вы бы не смогли больше увеличить размер вашей базы, и мы бы делали намного больше маленьких операций ввода-вывода и намного больше операций поиска, чтобы найти нужную нам информацию. Вот откуда происходит ошибка «Недостаточно памяти» («out of memory») вместе с ошибкой «Insufficient system resources exist to complete the requested service» . API управления файлами вызовет ошибку ERROR_FILE_SYSTEM_LIMITATION в Windows 2008 или более поздних версиях и ERROR_INSUFFICIENT_RESOURCES в более ранних версиях Windows до момента достижения абсолютного максимума. Ошибка недостатка памяти является ошибкой более высокого уровня, чем ошибка вызванная NTFS, которая не смогла увеличить размер FAL. Вот почему эта ошибка не является очевидной, и почему в конечном счете она была найдена Эриком Норбергом во время многих бессонных ночей и Дейвом Голдманом во время долгих отладочных сессий.

Этому вопросу фрагментации посвящено статья A heavily fragmented file in an NTFS volume may not grow beyond a certain size https://support.microsoft.com/kb/967351.

Этот сценарий чаще всего встречается на серверах с маленьким размером кластера NTFS равным 4К, большими базами, которые вдвое превышают рекомендованный максимум в 200 Гбайт, и малым доступным местом на диске. Сочетание этих трех факторов может привести к очень плохой ситуации.
Размеры кластера NTFS могут быть получены выполнением команды fsutil, как показано ниже, для любого раздела:

В Exchange 2007 вы можете проверить, попадаете ли вы в описанную ситуацию, загрузив и выполнив Contig.exe от Sysinternals по ссылке https://technet.microsoft.com/en-us/sysinternals/bb897428.aspx.

C:\>Contig.exe -a f:\data\DBName.edb

Contig v1.55 - Makes files contiguous
Copyright (C) 1998-2007 Mark Russinovich
Sysinternals - www.sysinternals.com

f:\data\DBName.edb is in 1.46698e+006 fragments

Summary:
Number of files processed : 1
Average fragmentation : 1.46698e+006 frags/file

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

Для Exchange 2010 SP1 вы можете вывести те же сведения аналогично contig.exe, с помощью eseutil.exe, как показано ниже.

C:\>eseutil /ms f:\data\DBName.edb

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 14.01
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
Error: Access to source database 'f:\data\DBName.edb' failed with Jet error -1032.

File Information:
File Name: f:\data\DBName.edb
Volume Name: Drive2
File System: NTFS
Cluster Size: 4096 bytes
Attribute List Size: 180 KB
Extents Enumerated: 1157172
Operation terminated with error -1032 (JET_errFileAccessDenied, Cannot access file, the file is locked or in use) after 0.78 seconds.

Несмотря на ошибки из-за того, что база находится в режиме онлайн, мы смогли получить нужную информацию. Если запустить локально на сервере Eseutil, то она позволяет вам увидеть реальный размер FAL, размер кластера NTFS и как много экстентов было создано для этого файла, благодаря чрезмерной фрагментации. Так мы можем сделать вывод, что размер кластера NTFS равен 4К, размер FAL 180 Кб и число фрагментов превышает 1.1 миллиона. Общее правило не иметь размер FAL больше 150 Кб и иметь достаточно свободного места на диске.

Эта фрагментация также проявляется на копиях CCR/Replica, т.к. файлы логов передаются и затем применяются к данной базе. В конечном итоге применение логов будет медленным, и вы можете иметь большие очереди применения логов из-за чрезмерного числа операций Split I/O. Даже с быстрыми дисками, правильно сконфигурированным размером кластера NTFS и правильно выровненными разделами дисков, вы будете все еще видеть эту проблему. Вы должны устранить корень этой проблемы, чтобы успешно избавиться от нее.

Так как же вам решить проблему? Есть несколько способов:

1. Если вы определили, что только одна база подвержена этой проблеме, то быстрейший способ решения проблемы заключается в следующем:

a. Размонтировать базу
b. Сделать копию базы на другой диск, где достаточно места. Важно: это не может быть тот же самый диск, т.к. нам необходимо записать этот файл последовательно на другой диск. Это простое копирование выполнит дефрагментацию файла.
c. Удалите исходную копию файла базы.
d. Скопируйте базу обратно в исходное место
e. Применение этого метода не решит проблему в долгосрочной перспективе, если размер кластера NTFS мал.

2. Если проблема на кластере CCR/SCR, то вы имеете несколько шагов для ее исправления в долгосрочной перспективе.

a. Чтобы устранить проблему размера кластера NTFS на неактивном узле или SCR target на любой томе, например F:, используйте следующую команду, чтобы отформатировать диск с размером блока 64Кб, который рекомендуется для оптимальной производительности:

Format F: /q /y /fs:ntfs /v:VolumeName /a:64K

Замечание: Эта команда удаляет любые файлы расположенные на диске F:, так что убедитесь, что на этом диске нет иной информации кроме базы и лог файлов. Я надеюсь, что вы выделили отдельные диски исключительно для Exchange и не используете для других приложений. Если так, то это делает наш процесс восстановления много проще.
b. Проверьте, то наш диск отформатирован правильно выполнив следующую команду:

c. Как только диск отформатирован, выполните повторное заполнение баз данных, которые ранее существовали на диске.

Вы можете спросить себя: "Если файл настолько фрагментирован, то почему я не могу просто выполнить автономную дефрагментацию (offline defrag)"? Ответ заключается в том, что если вы выполняете дефрагментацию самого файла, то вы имеете высокую вероятность раздутия размера FAL, т.к. мы заставляем фрагменты перемещаться, что вызывает рост размера FAL. Это главная причина того, почему для Exchange не рекомендуется выполнять дефрагментацию на томах, которые содержат файлы баз. Единственный способ удалить FAL из файла – это скопировать файл на другой диск, удалить исходный файл и затем скопировать файл обратно в исходное место. Когда это сделано, этот записанный файл не содержит фрагментов. Жизнь снова прекрасна.

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

Обратите внимание, что по-прежнему не рекомендуется запускать программы дефрагментации диска на томах сервера Exchange, но существуют случаи, когда уровень фрагментации файлов может вызвать значительное снижение производительности на сервере просто из-за способа, которым данные записываются на диск. Если оптимальные и/или рекомендуемые параметры не используются при создании тома, эта проблема фрагментации файла может возникнуть гораздо быстрее. Большинство файлов Exchange используются и заблокированы, так что запуск любых программ дефрагментации диска в этой ситуации не поможет. При необходимости решить эту проблему единственный путь – перевести все ресурсы Exchange в оффлайн, чтобы ни один из файлов не использовался, и затем дефрагментировать диск, чтобы сделать файлы снова последовательно записанными.

В Exchange SP1 и более поздних версиях была добавлена логика, которая позволяет определять момент, когда FAL может быть исчерпана (80% от максимума), и генерировать соответствующее событие. События NTFS при этом не регистрируются. Следующее событие является примером того, что должно было бы быть записано в журнал событий ля проблемной базы во время ее обслуживания в онлайне:

Log Name: Application
Source: ESE
Event ID: 739
Task Category: General
Level: Error
Description:
Information Store (5652) EXSERVER MBX Store 001: The NTFS file attributes size for database 'C:\DB\DB001\PRIV001.EDB' is 243136 bytes, which exceeds the threshold of 204800 bytes. The database file must be reseeded or restored from a copy or backup to prevent the database file from being unable to grow because of a file system limitation.

Разумные размеры томов и баз в значительной мере защитят вас от фрагментации (чем больше конкурирующих файлов, которые расширяются/создаются на томе, тем больше будет фрагментация на этих файлах).

Freigeben über

Как фрагментация на неправильно отформатированных томах NTFS влияет на Exchange

Примеры

NTFS allocation unit size

Рекомендации

Zusätzliche Ressourcen