IO

You are currently browsing the archive for the IO category.

По материалам технической статьи Майкрософт: A Case Study: Fast and Reliable Backup and Restore of a VLDB over the Network

Автор: Томас Грохсер (Thomas H. Grohser)
При содействии: Линдсей Аллен (Lindsey Allen)
Техническая экспертиза статьи: Sanjay Mishra, Lubor Kollar, Stuart Ozer, Thomas Kejser, Juergen Thomas, James Podgorski, Burzin Patel
Перевод: Александр Гладченко, Ирина Наумова
Редактура перевода: Алексей Халако
Дата издания: июнь 2009г.
Тематика статьи: SQL Server 2008

Резюме: Размер баз данных непрерывно растёт, так же, как и растут требования к надежности и доступности баз. Одновременно с этим как никогда важным становится требование быстрого и надежного восстановления данных. Этот документ посвящён проблемам проектирования устойчивого резервного копирования и решений по восстановлению очень больших баз данных (VLDB). В этой статье на реальном примере демонстрируется как лучше всего использовать функциональность SQL Server 2008 для осуществления резервного копирования и восстановления, которыми обладает SQL Server 2008, а также создание планов резервного копирования и восстановления VLDB по сети.

Читать статью в блоге Ирины Наумовой

Данный перевод был опубликован на сайте SQLCAT: http://sqlcat.com/cfs-file.ashx/__key/communityserver-components-postattachments/00-00-00-10-15/Fast-and-Reliable-Backup-and-Restore-of-a-VLDB-over-the-Network-RUS.zip

…и наконец моё любопытство возобладало, и я решил таки заглянуть, что же такого понаделел HP в TPC-H…

Не удивляйтесь, но поначалу я не предавал особого значения появляющимся с завидной регулярностью (раз в месяц) новым, ничем с виду не примечательным результатам. Но, когда появился третий из них, я заметил тенденцию, что они становятся с каждым разом немного ХУЖЕ и ДОРОЖЕ. Именно тогда мне стало любопытно, в чём там “порылась собака”…
Конечно, виною всему было то, как представлены результаты в сводной таблице: Complete TPC-H Results List – Sorted by Date Submitted
Просто, в представлении на сайте не видно главного изменения, поскольку испокон веков эта составляющая была неизменной и только в последние год – два ситуация начала выправляться к лучшему. На самом деле, HP в последнем из трёх своих результатов показал, как SAS диски могут оказаться более дорогим решением, чем SSD диски, при близкой производительности.
Вот несколько видоизменённое представление результатов, с детализацией по конфигурации дисковой подсистемы:

Ссылки на подробные описания тестов:

Результаты потрясающие! Оказывается решение на базе SSD получается чуть ли не в двое дешевле, чем на привычных нам SAS.
Похоже, гегемонии производителей жёстких дисков приходит долгожданный конец, а точнее, последний рудимент зари IBM PC, этот кошмарный механический монстр, самое слабое звено любого компьютера – HDD может уйти в небытие!

По материалам статьи: “Resolving PAGELATCH Contention on Highly Concurrent INSERT Workloads“.
Авторы: Thomas Kejser, Lindsey Allen, Arvind Rao и Michael Thomassy
При участии и с рецензиями: Mike Ruthruff, Lubor Kollar, Prem Mehra, Burzin Patel, Michael Thomassy, Mark Souza, Sanjay Mishra, Peter Scharlock, Stuart Ozer, Kun Cheng и Howard Yin
Перевод Александра Гладченко

Введение

Недавно, мы проводили лабораторные испытания в Microsoft Enterprise Engineering Center, при которых использовалась большая рабочая нагрузка, характерная для OLTP систем. Целью этой лабораторной работы было определить, что случится при увеличении числа процессоров с 64 до 128, при обслуживании Microsoft SQL Server интенсивной рабочей нагрузки (примечание: эта конфигурация была ориентирована на релиз Microsoft SQL Server 2008 R2). Рабочая нагрузка представляла собой хорошо распараллеленные операции вставки, направляемые в несколько больших таблиц.
Рабочая нагрузка масштабировалась до 128 процессорных ядер, но в статистике ожиданий было очень много кратких блокировок PAGELATCH_UP и PAGELATCH_EX. Средняя продолжительность ожидания была десятки миллисекунд, и таких ожиданий было очень много. Такое их количество оказалось для нас неожиданностью, ожидалось, что продолжительность не будет превышать несколько миллисекунд.
В этой технической заметке вначале будет описано, как диагностировать подобную проблему и как для разрешения подобной проблемы использовать секционирование таблиц.

Read the rest of this entry »

(на примере полки с 14 одинаковыми дисками)

Введение

В качестве утилиты для эталонного тестирования дисковой подсистемы используется разработанная Майкрософт программа SQLIO, подробное описание которой представлено в статье Эталонный тест дисковой подсистемы SQLIO. В методике используется ограниченный набор параметров вызова SQLIO. Давайте рассмотрим назначение параметров на примере:

sqlio -kR -s300 -b64 -f1 -i2000000 -o1 -t1 -R1 -LP -a0xf –BN Read the rest of this entry »

 

Одной из распространённых задач систем с высокой транзакционной загрузкой является определение того, достаточно ли производительна подсистема ввода-вывода, обслуживающая журнал транзакций. Часто «узким местом» становиться дисковая подсистема, используемая в качестве долговременного носителя для файла журнала транзакций обслуживаемой SQL Server базы данных. Одним из важных параметров дисковой подсистемы является время доступа к данным на диске. Современным дисковым подсистемам характерно время доступа порядка 1 – 5 ms. Проверить, какое время доступа у используемой для размещения файла журнала транзакций дисковой подсистемы можно с помощью административного динамического представления: sys.dm_os_wait_stats (Transact-SQL). Данные в этом представлении накапливаются с момента последнего запуска службы SQL Server, поэтому, рекомендуется очистить эту статистику. Сделать это можно следующей командой:

Одной из трудно оптимизируемых задач SQL Server является вставка. Не раз мне приходилось сталкиваться с ситуациями, когда уже и схема оптимизирована под вставку, и сайзинг файлов вставке не препятствует, а желаемой производительности массовой или не массовой вставки достичь не удаётся. Не хватает совсем немногого…

Разработчики SQL Server 2008 позаботились о том, чтобы предоставить нам с вами в распоряжение некую «палочку – выручалочку», которая призвана как раз снизить затраты на вставку, путём её не полного журналирования. Для этого предлагается задействовать на серверах флаг трассировки 610, который по моим наблюдениям действительно может немного облегчить вставку. Флаг, и его побочные эффекты, подробно описан тут: http://msdn.microsoft.com/ru-ru/library/dd425070(en-us).aspx

Ещё одна мера, в дополнение к включению флага трассировки 610, описана в документе вендора: http://technet.microsoft.com/ru-ru/library/cc917672(en-us).aspx. Там, среди прочего, подробно описано исследование того, что будет эффективней, вставка в таблицу с единственным некластеризованным индексом, или вставка в таблицу с единственным кластеризованным индексом. Кластеризация данных может дать выигрыш на вставке до 3%.

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

В тему:

Недавно Кевин Кляйн в очередной раз поднял тему выравнивания размеров кластера и блока, проблему, которая, казалось бы, давно хорошо всем известна, документирована и не обходит ни один из известных мне списков рекомендаций по оптимизации работы дисковой подсистемы сервера баз данных. Статья Кевина How to Improve Application and Database Performance up to 40% in One Easy Step получила довольно большой резонанс в профессиональной блог-сфере, точно также, как в былые времена об этом писалось множество статей, шумели в форумах или nntp-конференциях… Размышляя о причинах всеобщей забывчивости о подобных проблемах, я склонен к таковым в первую очередь отнести то, что, увы, всё меньше стало возможностей получения систематизированных знаний (так и не образовалось школ администрирования, а техническая литература практически умерла на территории бывшего СССР), и то, что современные модели организации инфраструктуры IT всё меньше способствуют творческому и разностороннему подходу к задачам администрирования серверного парка организации. Узкие специализации и большие, я бы даже сказал масштабные, нагрузки на специалистов поддержки жизнедеятельности центров обработки данных приводят к тому, что ускользают такие детали, как, например, выравнивание размеров кластера и блока… Жизнь показывает, что такие просчёты для серверов баз данных могут стоить до 40% потери производительности дисковых операций.

Давайте перейдём к сути проблемы и начнём с её описания. Сразу хочу отметить, что если вы для размещения файлов баз данных используете RAW-партиции, или это простые диски, не входящие ни в какой RAID-массив с собственным контроллером, то вам беспокоиться не о чем. Не выровненными могут быть только кластеры NTFS и блоки RAID-массива (пусть даже это RAID0 из одного диска). Когда форматируется раздел, вы выбираете размер кластера, который является по сути своей тем же самым, что и блок разметки дисков у RAID-контроллера. Наверняка, в форумах или в рекомендациях разных вендоров вам попадались слова, что размер блока и размер кластера желательно устанавливать одинаковыми, например, для баз данных SQL Server очень часто слышны рекомендации выбирать и там и там 64Кб. Однако, операционная система создает самый первый кластер (блок начальной загрузки) размером в 63Кб. Эта особенность NTFS означает, что каждый последующий кластер будет сдвинут на 1Кб на предыдущий блок. Т.е. кластеры окажутся смещёнными относительно границ блоков массива. Такая ситуация приводит к тому, что одна операция чтения или записи кластера будет затрагивать два сектора и будет приводить к удвоению числа запросов ввода-вывода.

Наиболее наглядно это показал Дэнни Черрай (Denny Cherry) в своей статье Optimize disk configuration in SQL Server. Вот рисунок из его статьи:

А вот выигрыш от выравнивания наиболее наглядно продемонстрировал в статье своего блога Линчи Шеа, которую вы можете посмотреть здесь.

Ещё один подробный тест производительности SQL Server со смещением или без опубликовал в своём блоге Илгиз Мамышев: Выравнивание кластеров NTFS и блоков RAID массива (детальный тест для SQL Server)

Обнаружить и устранить смещение кластеров относительно блоков можно с помощью утилиты из состава Windows Server 2003, которая называется DISKPART.EXE. В Windows 2000 она имела несколько укороченное имя DISKPAR.EXE и входила в состав Windows 2000 Resource Kit.

Существует несколько статей Майкрософт, которые подробно обсуждают эту тему: 

Ещё несколько примеров использования DISKPART.EXE для нужд SQL Server вы можете найти в этих статьях: 

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

Для того чтобы проверить существование сдвига, вы можете использовать следующий порядок использования утилиты DISKPART: Перейдите в командную строку и там, получив приглашение командной сроки, наберите и выполните команду: diskpart.exe. После этого вы должны увидеть приглашение запущенной утилиты DISKPART>. С помощью команды LIST DISK просмотрите список имеющихся дисков. Для того чтобы сделать текущим один из исследуемых дисков, введите команду SELECT DISK n, где n – номер выбранного диска по порядку операционной системы. После позиционирования диска, дайте команду LIST PARTITION, которая выведет на экран подробную информацию о разделах диска, включая начальное смещение.

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

    SELECT * FROM Win32_DiskPartition

Он, как и вызов команды LIST PARTITION, вернёт в числе своих результатов информацию о начальном смещении. Те цифры, которые вы увидите, необходимо будет разделить на величину размера сектора диска, например, так:

    32256 / 512 = 63

Если полученный результат деления будет такой, как в примере, а размер блока дискового массива равен 64, значит между кластерами и блоками существует смещение в 1 Кб. Для того, чтобы выровнять раздел, нужно удалить смещённый раздел, а потом для выбранного диска задействовать команду DISKPART> CREATE PARTITION PRIMARY ALIGN=64. Эта команда создает новый раздел со смещением первого кластера на 64КбБ, что позволяет выровнять границы кластеров и блоков и тем самым оптимизировать работу дисковой подсистемы. Опция ALIGN появилась в сервисном пакете Windows 2003 SP1.

« Older entries § Newer entries »