Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy

Именно так. С массивом работа производится последовательно, с небольшим ускорением относительно одиночного диска (обычно процентов 10-15, в редких случаях - до 30). А если у вас данные и лог на РАЗНЫХ устройствах (а RAID в данном случае оказывается одним устройством) - доступ к ним действительно распараллеливается.

Не именно и вообще не так Читать контроллеры могут со всех винтов разом, и писать на все, если процесс не ограничен авторами прошивки и уровнем RAID. И очень давно.

да нет, напротив, рекомендуется теми, кто с этим хоть когда-нибудь работал. Ибо на практике получается, что за сомнительное достоинство в виде продолжения работы сервера при вылете одного диска (а на средненьком контроллере это действительно будет сомнительная работа) мы платим падением быстродействия и общим снижением отказоустойчивости системы. Если нам действительно нужна отказоустойчивость - используют RAID1 - 10, но тут уже вопрос компромисса (надежность+производительность)/ стоимость.

Даааа.... Давайте уже, рвите и остальные шаблоны
Средненький контроллер ныне имеет считалку с тактовой в районе гигагерца. Если что, в совсем недавнем прошлом хайэндовые массивы обслуживались гораздо более дохлыми считалками. Кэш у "средненьких" контроллеров ныне - 256-512 МБайт. Посчитать, сколько страниц БД укладывается, можете ? ;)
Падение производительности - да, есть, ровно на производительность вот этого самого вылетевшего винта. Понятно, что при ребилде после замены падение производительности будет больше - но тут можно вручную отрегулировать приоритет ребилда на подавляющем большинстве "средненьких" контроллеров, раз уж так надо держать суровую нагрузку в это время.
Те, кто с этим на самом деле хоть когда-нибудь работал, еще и винты в горячем резерве (hot-spare) держат, дабы не употреблять корвалол ведрами с массивом под нагрузкой в критическом состоянии.
А если действительно нужна отказоустойчивость - просто считают стоимость простоя и применяют адекватные этой самой стоимости меры.
Вплоть до синхронной репликации данных всех критичных сервисов на удаленную площадку.
А уровень RAID выбирается исходя прежде всего из соотношения нагрузок на чтение и запись (1/5/10) , потребной отказоустойчивости (6), сочетания отказоустойчивости на большом количестве винтов с минимальным временем ребилда (50).
21 июл 09, 14:31    [7440510]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
Anatoly Podgoretsky
Member

Откуда:
Сообщений: 62917
iljy
Anatoly Podgoretsky
iljy
Anatoly Podgoretsky,

вы сказали от ОДНОГО до N. Выпадение двух дисков RAID5 тоже не позволяет восстановить. И кстати просто RAID5 при выпадении 2 дисков позволит восстановить данные только из последнего бакапа, а вариант с разбиением и выносом лога на отдельный RAID1 (RAID10) позволит восстановить данные полностью. Хотя конечно не онлайн, но тут уж извините

Я не точно выразился, возможно восстановление при выпадании от ДВУХ до N - как повезет.


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

Везение начинается с ДВУХ, а не с ТРЕХ - поскольку эти два могут оказать в одной паре "RAID-1"
21 июл 09, 14:45    [7440608]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
a_shats
iljy

Именно так. С массивом работа производится последовательно, с небольшим ускорением относительно одиночного диска (обычно процентов 10-15, в редких случаях - до 30). А если у вас данные и лог на РАЗНЫХ устройствах (а RAID в данном случае оказывается одним устройством) - доступ к ним действительно распараллеливается.

Не именно и вообще не так Читать контроллеры могут со всех винтов разом, и писать на все, если процесс не ограничен авторами прошивки и уровнем RAID. И очень давно.

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


да нет, напротив, рекомендуется теми, кто с этим хоть когда-нибудь работал. Ибо на практике получается, что за сомнительное достоинство в виде продолжения работы сервера при вылете одного диска (а на средненьком контроллере это действительно будет сомнительная работа) мы платим падением быстродействия и общим снижением отказоустойчивости системы. Если нам действительно нужна отказоустойчивость - используют RAID1 - 10, но тут уже вопрос компромисса (надежность+производительность)/ стоимость.

Даааа.... Давайте уже, рвите и остальные шаблоны
Средненький контроллер ныне имеет считалку с тактовой в районе гигагерца. Если что, в совсем недавнем прошлом хайэндовые массивы обслуживались гораздо более дохлыми считалками. Кэш у "средненьких" контроллеров ныне - 256-512 МБайт. Посчитать, сколько страниц БД укладывается, можете ? ;)

Вы вообще в чем меня пытаетесь убедить? Вы тему читали? У автора проблемы с очередью на запись именно на RAID5. Несмотря на всю вашу внутреннюю убежденность, что такого быть не может. И считалка тут абсолютно не причем.


А если действительно нужна отказоустойчивость - просто считают стоимость простоя и применяют адекватные этой самой стоимости меры.
Вплоть до синхронной репликации данных всех критичных сервисов на удаленную площадку.

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

А уровень RAID выбирается исходя прежде всего из соотношения нагрузок на чтение и запись (1/5/10) , потребной отказоустойчивости (6), сочетания отказоустойчивости на большом количестве винтов с минимальным временем ребилда (50).

именно. и RAID5 чаще всего является компромиссом. с еще одним фактором, про который вы опять же как-то ненавязчиво забыли упомянуть - ценой.
21 июл 09, 14:53    [7440684]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
Anatoly Podgoretsky,

ну и что? это потеря журнала, сами данные при это сохранились. хотя конечно данный вариант едва ли не самый геморройный.
21 июл 09, 14:54    [7440696]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
Anatoly Podgoretsky
Member

Откуда:
Сообщений: 62917
Я говорю об восстановление на физическом уровек, на уровне дисков, вынул сдохший - поставил новый и работаем дальше. Ты видимо говоришь о случае когда на этом массиве находится журнал и можно немно помучившись восстановить работу системы, но не данные на этом массиве.
В указаном мной случае теряется не только информация на подохших дисках, а вся на данном массиве, поскольку это аналогично выходу из строя одного единственного диска RAID-0

--
http://www.podgoretsky.com
21 июл 09, 15:06    [7440773]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy
Знает что такое случайный доступ? Так вот скуль в основном работает именно в таком режиме. Причем обращение идет к разным файлам. И вы хотите сказать, что RAID5 или любой другой разложит вам файлы по разным шпинделям и обеспечит к ним независимый параллельный доступ?Любые рекомендации по улучшению производительности дисковой подсистемы начинаются с предложения разнести журнал и данные.

Нет, откуда ж бедному инженеру знать такие тонкости
Подсказываю: ни SQL, ни операционная система не знают и не могут знать, как именно RAID-контроллер раскладывает блоки по дискам. И как их читает/пишет. И я не знаю. Разве что могу подозревать, исходя из общепринятых стандартов. А из них следует, что - да, блоки любого уровня RAID раскладываются по всем винтам драйв-группы. А уж как RAID-контроллер раскладывает их на самом деле зависит от фантазии писателей его прошивки, а она у них богатая и нездоровая
Чаще всего - да, контроллер пытается читать со всех винтов и писать, по возможности, на все разом. Но у разных контроллеров разных вендоров может быть иначе.
Что до
Любые рекомендации по улучшению производительности дисковой подсистемы начинаются с предложения разнести журнал и данные.

Это как раз рекомендации сделать из одной шкуры не одну, а десять шапок, как в известном мультфильме. Тоже можно (с).
Правильные рекомендации по улучшению производительности именно дисковой подсистемы начинаются с предложения увеличить количество винтов.
Вы вообще в чем меня пытаетесь убедить? Вы тему читали? У автора проблемы с очередью на запись именно на RAID5. Несмотря на всю вашу внутреннюю убежденность, что такого быть не может. И считалка тут абсолютно не причем.

Автору как раз я уже выше все написал и разобрал. И да, тему читал, и даже перед этим.
А вот Вы читали ? Мои посты, к автору обращенные, в смысле.
у автора существует определенная конфа, которую менять никто не будет. и речь идеть не о том, чтобы доставить туда еще десяток дисков, собрать в пару массивов и все будет зашибись, а о том, как наиболее эффективно использовать эту.

Ошибочная постановка задачи. В принципе ошибочная. Правильная - а потянет ли задачу автора имеющееся железо ? Ответ выше дан.
и RAID5 чаще всего является компромиссом. с еще одним фактором, про который вы опять же как-то ненавязчиво забыли упомянуть - ценой.

УффффффФФФФФ...
RAID5 не является "компромиссом", как и все остальные. Ну или можно сказать, что все уровни RAID являются компромиссом между какими-нибудь качествами.
Цена равного количества дисков в RAID5 или 10 будет совершенно одинаковой, хотите верьте, хотите проверьте
21 июл 09, 15:13    [7440815]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
Anatoly Podgoretsky,

в принципе да. данная система не является онлайн-отказоустойчивой, но является вполне надежной в смысле сохранности данных. просто показалось мне, что автору онлайн-восстановление не слишком критично, а вот производительности не хватает.
21 июл 09, 15:15    [7440830]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
Anatoly Podgoretsky
Member

Откуда:
Сообщений: 62917
Ну вот и договорились

--
http://www.podgoretsky.com
21 июл 09, 15:17    [7440846]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
Anatoly Podgoretsky
Ну вот и договорились

надеюсь осталось еще с бедным инженером договориться...

a_shats

Нет, откуда ж бедному инженеру знать такие тонкости
Подсказываю: ни SQL, ни операционная система не знают и не могут знать, как именно RAID-контроллер раскладывает блоки по дискам. И как их читает/пишет. И я не знаю. Разве что могу подозревать, исходя из общепринятых стандартов. А из них следует, что - да, блоки любого уровня RAID раскладываются по всем винтам драйв-группы. А уж как RAID-контроллер раскладывает их на самом деле зависит от фантазии писателей его прошивки, а она у них богатая и нездоровая
Чаще всего - да, контроллер пытается читать со всех винтов и писать, по возможности, на все разом. Но у разных контроллеров разных вендоров может быть иначе.

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


a_shats

RAID5 не является "компромиссом", как и все остальные. Ну или можно сказать, что все уровни RAID являются компромиссом между какими-нибудь качествами.
Цена равного количества дисков в RAID5 или 10 будет совершенно одинаковой, хотите верьте, хотите проверьте

Ценв - одинаковой, а вот реальная емкость - нет. Потому что 5- это 20% (+-) резервирование, а 1-10 - 100%. но при этом получается более высокая надежность и отказоустойчивость, да и быстродействие тоже побольше.
21 июл 09, 15:33    [7440959]     Ответить | Цитировать Сообщить модератору
 Re: Выбор дисковой системы  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy

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


a_shats

RAID5 не является "компромиссом", как и все остальные. Ну или можно сказать, что все уровни RAID являются компромиссом между какими-нибудь качествами.
Цена равного количества дисков в RAID5 или 10 будет совершенно одинаковой, хотите верьте, хотите проверьте

Ценв - одинаковой, а вот реальная емкость - нет. Потому что 5- это 20% (+-) резервирование, а 1-10 - 100%. но при этом получается более высокая надежность и отказоустойчивость, да и быстродействие тоже побольше.
21 июл 09, 15:38    [7440994]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy
как бы он их не раскладывал - ни один контроллер не сможет различить блоки журнала и блоки данных, ибо не его это задача.

Предлагаю поискать разное про алгоритмы кэширования и предвыборки (prefetch).
Относительно средненького контроллера опять же - насколько часто с MSSQL случаются операции ввода-вывода объемом 256-512 (на самом деле несколько мене, ибо сколько-то занимает ОС самого RAID, да и соотношение объемов кэшей записи и чтения на конкретных контроллерах конкретных производителей может настраиваться вручную или "гулять" по мере необходимости в разные стороны) МБайт за раз ?
Да-да, контроллер делает это у себя в кэше. Я уже не говорю про всякие там очереди команд ...
А приводит это к тому, что работа с tempdb, данными и журналом превращается в серию последовательных операций, и факт, что каждая из операций выполняется несколько быстрее, чем на одиночном диске, этого не компенсирует.

Вы не поверите, но очередь к дисковой подсистеме - это и есть последовательная очередь операций ввода-вывода От операционной системы.
А если без иронии - то на малом количестве дисков именно что каждая из нагрузок получает все IOps'ы от всех дисков, и выигрывает от этого. Подчеркиваю - при малом количестве дисков (до 10-12-16). Можно сделать и одну шапку, можно и 10 - но при этом ни одна из 10 на голову не налезет. Потому как шкуры (IOps'ов от винтов) осталось столько же.
И автор конечно может схватиться за железо и заняться апгрейдом контроллера, добить туда дисков и т.п., но лучше схватиться за голову и подумать, в чем же проблема на самом деле.

И в чем же ? Я-то думал - уже освещен этот вопрос...
Ценв - одинаковой, а вот реальная емкость - нет. Потому что 5- это 20% (+-) резервирование, а 1-10 - 100%. но при этом получается более высокая надежность и отказоустойчивость, да и быстродействие тоже побольше.

RAID5 - объем всех винтов минус объем одного.
RAID10 - объем половины дисков, состоящих в массиве. Потому как страйп зеркал (RAID0, состоящий из RAID1).
Никаких 20 или 100%.
21 июл 09, 15:53    [7441103]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
полухохол
Member [заблокирован]

Откуда:
Сообщений: 448
a_shats,

Вам дело говорят. Обычно для баз небольших размеров используют RAID1, для средних RAID 10 и только для энтерпрайз массивов RAID50 и 60 с маленьким размером страйпа.
RAID 10 используют только чтобы было удобнее админить базу, и не надо было возится с десятками файлов в файлгруппе. А 50 и 60 только для снижения общей стоимости дисковой подсистемы, скорости это не добавляет.

SQL начиная с 2008 уделывает любой контроллер по сортировке запросов в IO queue и по балансировке нагрузки на разные файлы в файлгруппе, если файлы лежат на разных LUN, он то точно знает какая операция будет следующая, и кроме того животное очень умное и балансирует планы выполнения так чтобы не просаживать отдельные устройства.
Для Оракла все тоже самое, только он нагрузку балансировать не умеет и очередь сортировать.
21 июл 09, 16:08    [7441241]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
полухохол
Member [заблокирован]

Откуда:
Сообщений: 448
a_shats,

И кроме того советую прочитать что такое full table scan и FFS индекса и multiblock read count, тогда вот этой фигни может писать не будете:

насколько часто с MSSQL случаются операции ввода-вывода объемом 256-512
21 июл 09, 16:11    [7441255]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
полухохол
a_shats
Вам дело говорят.

Где ?
Обычно для баз небольших размеров используют RAID1, для средних RAID 10 и только для энтерпрайз массивов RAID50 и 60 с маленьким размером страйпа.

Эхе-хе... выбранный уровень RAID вообще крайне редко зависит от размера базы. По уму.
А зависит - от соотношения нагрузок на запись и чтение.
RAID50 используется на совсем уж монструозного размера (сотни ТБ) объемах, ради быстрого ребилда.
RAID60 - выбор безнадежных параноиков


RAID 10 используют только чтобы было удобнее админить базу, и не надо было возится с десятками файлов в файлгруппе. А 50 и 60 только для снижения общей стоимости дисковой подсистемы, скорости это не добавляет.

Жесть... Это каким образом RAID50 и 60 снижают общую стоимость дисковой подсистемы ?
Сегодня день открытий какой-то.

SQL начиная с 2008 уделывает любой контроллер по сортировке запросов в IO queue и по балансировке нагрузки на разные файлы в файлгруппе, если файлы лежат на разных LUN, он то точно знает какая операция будет следующая, и кроме того животное очень умное и балансирует планы выполнения так чтобы не просаживать отдельные устройства.

Это крайне просто проверить, если в Вашем распоряжении есть RAID, HBA и винты.
Вкратце: любой - не уделает. "начиная с 2008" тоже хорошо сказано

Для Оракла все тоже самое, только он нагрузку балансировать не умеет и очередь сортировать.

Вы только ораклоидам этого не говорите
И - да, искреннее спасибо Вам и iljy за хорошее настроение и несколько добавленных к жизни минут.
21 июл 09, 16:21    [7441323]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
полухохол
a_shats,

И кроме того советую прочитать что такое full table scan и FFS индекса и multiblock read count, тогда вот этой фигни может писать не будете:

насколько часто с MSSQL случаются операции ввода-вывода объемом 256-512


Советую тупо взять перфмон и посмотреть.
А если у Вас база десятки-сотни гиг и сотни-тысячи пользователей, то обычно средненькому контроллеру возле нее не место.
21 июл 09, 16:22    [7441334]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
a_shats
iljy
как бы он их не раскладывал - ни один контроллер не сможет различить блоки журнала и блоки данных, ибо не его это задача.

Предлагаю поискать разное про алгоритмы кэширования и предвыборки (prefetch).
Относительно средненького контроллера опять же - насколько часто с MSSQL случаются операции ввода-вывода объемом 256-512 (на самом деле несколько мене, ибо сколько-то занимает ОС самого RAID, да и соотношение объемов кэшей записи и чтения на конкретных контроллерах конкретных производителей может настраиваться вручную или "гулять" по мере необходимости в разные стороны) МБайт за раз ?
Да-да, контроллер делает это у себя в кэше. Я уже не говорю про всякие там очереди команд ...

Это хорошо работает когда у вас идет основная работа с небольшим куском данных. К сожалению на реальной базе с приличной загрузкой такое счастье выпадает редко. Кеш на запись конечно позволит сгладить проблему, не спорю. Но - потребуются вложения в новый контроллер.
Вообще почти любую проблему можно решить увеличением мощности железа. Существуют разработки энергонезависимой оперативы, вот уж вообще сказка по производительности, и надежность неплохая. ;)


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

Вы не поверите, но очередь к дисковой подсистеме - это и есть последовательная очередь операций ввода-вывода От операционной системы.

вы не поверите, но операции из этой очереди, адресованные разным устройствам - могут выполняться параллельно.

А если без иронии - то на малом количестве дисков именно что каждая из нагрузок получает все IOps'ы от всех дисков, и выигрывает от этого. Подчеркиваю - при малом количестве дисков (до 10-12-16). Можно сделать и одну шапку, можно и 10 - но при этом ни одна из 10 на голову не налезет. Потому как шкуры (IOps'ов от винтов) осталось столько же.

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

Ценв - одинаковой, а вот реальная емкость - нет. Потому что 5- это 20% (+-) резервирование, а 1-10 - 100%. но при этом получается более высокая надежность и отказоустойчивость, да и быстродействие тоже побольше.

RAID5 - объем всех винтов минус объем одного.
RAID10 - объем половины дисков, состоящих в массиве. Потому как страйп зеркал (RAID0, состоящий из RAID1).
Никаких 20 или 100%.

Объем половины дисков - 100% резервирование (могу написать 50% если вам так проще). Для RAID5 порядка 1 диск из 5 - 20%. Т.е. на хранение полезной инфы расходуется разная часть купленного дискового пространства.

за минуты - пожалуйста, тем более что вы меня тоже изрядно позабавили. Меня всегда умиляла логика типа "сеть медленная? а давайте мы туда еще ведро оперативы фиганем!"
21 июл 09, 16:39    [7441430]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy
Это хорошо работает когда у вас идет основная работа с небольшим куском данных. К сожалению на реальной базе с приличной загрузкой такое счастье выпадает редко. Кеш на запись конечно позволит сгладить проблему, не спорю. Но - потребуются вложения в новый контроллер.

Вооооот. А далее уже рулит извращенность фантазии изобретателей алгоритмов кэширования: я уже тут упоминал о тестировании реальной оракловой базы, в ходе которого HDS AMS500 (уже устаревший массив, но таки mid-range) выдавал на-гора IOps в 4-5 раз больше, чем могли установленные в его винты. При кэше опять таки в кучу раз меньше оной базы и на самой неприятной нагрузке (наитолстейшие отчеты по всей базе).
Вообще почти любую проблему можно решить увеличением мощности железа. Существуют разработки энергонезависимой оперативы, вот уж вообще сказка по производительности, и надежность неплохая. ;)

К сожалению - не любую. Тут, напротив, пас софтовикам: самое эффективное решение проблем - соответствующее задаче железо плюс точение софта :)

вы не поверите, но операции из этой очереди, адресованные разным устройствам - могут выполняться параллельно.

Верю и даже догадываюсь - где именно Подсказываю: кэш у RAID-контроллера - он один.
С каким количеством драйв-групп работают запросы - пофигу, ибо оптимизация оных происходит именно в нем одном.
Да, когда винтов много, и объемы ворочаемых данных в сотни раз превосходят объем кэша контроллера - тогда да, рулит и педалит раскладка нагрузок по драйв-группам. Мало того, можно еще и чрез разные контроллеры эти драйв-группы молотить, если речь о двухконтроллерном внешнем RAID.
Но когда винтов - мало, контроллер - один, кэш - один - прирост производительности от извратов с раскладом даже теоретически отсутствует, а на практике может привести даже и к ухудшению производительности на конкретных нагрузках в конкретной конфигурации.
да поймите вы наконец - не все быстродействие сводится к потоку ввода-вывода. Операции случайные, и сбалансировать их, а тем более предсказать, лучше сервера - ни один контроллер не сможет.

Тут другая проблема - еще раз, сервер ничего не знает о том, как на самом деле расположены блоки данных и что на каких винтах. Потому сервер предсказать и сбалансировать может в очень ограниченных рамках.
за минуты - пожалуйста, тем более что вы меня тоже изрядно позабавили. Меня всегда умиляла логика типа "сеть медленная? а давайте мы туда еще ведро оперативы фиганем!"

Ну, это Вас в другую сторону уже понесло Я возражал против попытки сделать десять шапок из материала на одну - но и только.
21 июл 09, 17:13    [7441595]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
a_shats
iljy
Это хорошо работает когда у вас идет основная работа с небольшим куском данных. К сожалению на реальной базе с приличной загрузкой такое счастье выпадает редко. Кеш на запись конечно позволит сгладить проблему, не спорю. Но - потребуются вложения в новый контроллер.

Вооооот. А далее уже рулит извращенность фантазии изобретателей алгоритмов кэширования: я уже тут упоминал о тестировании реальной оракловой базы, в ходе которого HDS AMS500 (уже устаревший массив, но таки mid-range) выдавал на-гора IOps в 4-5 раз больше, чем могли установленные в его винты. При кэше опять таки в кучу раз меньше оной базы и на самой неприятной нагрузке (наитолстейшие отчеты по всей базе).

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

вы не поверите, но операции из этой очереди, адресованные разным устройствам - могут выполняться параллельно.

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

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

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

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


Ну, это Вас в другую сторону уже понесло Я возражал против попытки сделать десять шапок из материала на одну - но и только.

это не 10 шапок, а нормальное стремление распределить нагрузку.
21 июл 09, 17:29    [7441686]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy
это как раз не самая неприятная нагрузка, и очень даже наоборот - для дисковой подсистемы самое оно: мы читаем фактически поток данных. Только вот вы задумайтесь: если включить эти винты отдельно, да разложить по ним файловую группу, да позволить серверу грамотно ее набить - прирост мы может получить ничуть не хуже.

[бьется головой в стену]
Ну откуда, откуда мы получим прирост ??? Число операций ввода-вывода в секунду на случайном доступе, которое может выдать имеющееся количество винтов, никак не изменилось.
Откуда возьмем прирост ? Из пальца, с Марса или еще откуда ?
подсказываю - дело тут не в кеше, а в том, что запрос к разным группам может физически обрабатываться параллельно. Вместе с позиционированием головок и прочей сопутствующей машинерией.

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

Куда бы сервер не стремился - о действительном положении дел на дисковой он ничего не знает.
И не может знать. Об оптимизациях, производимых RAID-контроллером в его кэше - тоже.
это не 10 шапок, а нормальное стремление распределить нагрузку.

Понимаете, когда человек говорит, что может руками распределить нагрузку лучше, чем коллектив инженеров, работавший над разработкой RAID-контроллеров десятки лет и съевший всех собак и всю соль в округе на этом деле - это не то, чтобы недоверие вызывает
Словом - такие люди есть, но их очень немного, гораздо меньше, чем инсталляций SQL
21 июл 09, 17:44    [7441772]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
a_shats
iljy
это как раз не самая неприятная нагрузка, и очень даже наоборот - для дисковой подсистемы самое оно: мы читаем фактически поток данных. Только вот вы задумайтесь: если включить эти винты отдельно, да разложить по ним файловую группу, да позволить серверу грамотно ее набить - прирост мы может получить ничуть не хуже.

[бьется головой в стену]
Ну откуда, откуда мы получим прирост ??? Число операций ввода-вывода в секунду на случайном доступе, которое может выдать имеющееся количество винтов, никак не изменилось.
Откуда возьмем прирост ? Из пальца, с Марса или еще откуда ?

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

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

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

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

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

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

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

это не 10 шапок, а нормальное стремление распределить нагрузку.

Понимаете, когда человек говорит, что может руками распределить нагрузку лучше, чем коллектив инженеров, работавший над разработкой RAID-контроллеров десятки лет и съевший всех собак и всю соль в округе на этом деле - это не то, чтобы недоверие вызывает
Словом - такие люди есть, но их очень немного, гораздо меньше, чем инсталляций SQL

Понимаете, SQL-server также писал далеко не один человек, и работали они над распределением нагрузки не меньше. И информации для такого распределения у сервера заведомо больше.
Спор перестал быть конкретным. Соберите себе конфу как у автора и проверьте оба варианта.
21 июл 09, 18:14    [7441970]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
vino
Member

Откуда:
Сообщений: 1191
a_shats
...[бьется головой в стену]
Ну откуда, откуда мы получим прирост ??? Число операций ввода-вывода в секунду на случайном доступе, которое может выдать имеющееся количество винтов, никак не изменилось.
Откуда возьмем прирост ? Из пальца, с Марса или еще откуда ?

не нервничайте. Когда пропускная контроллера позволяет, то запросы к "разным группам винтов может физически обрабатываться параллельно"
Ведь тормоза, в основном, как раз из-за "позиционирования головок и прочей сопутствующей машинерии".
А при работе с логом нагрузка практически не требует случайного доступа!
От обычной нагрузки на файлы данных это, в основном, сильно отличается.
Так что пока винты сильно тормозят на случайном доступе, будет необходимость разнесения данных и лога в независимые дисковые массивы, пусть даже на одном контроллере.
a_shats
Куда бы сервер не стремился - о действительном положении дел на дисковой он ничего не знает. И не может знать...

Как раз, mssql собирает статистику о стоимости IO, так что ему, при наличии независимых файлов данных и достаточной вычислительной мощности, намного легче решать, как оптимизировать очереди к файлам. Поэтому и расположить файлы на разных массивах иногда разумнее, чем доверить это контроллеру RAID (какой бы умный он не был, у него нет информации о логической структуре и цене данных).
А насчет шапок забудьте, винчестеры стали слишком сложными устройствами и средняя их скорость мало кореллирует с максимальной, особенно при выключенном на запись кэше.
Хотя, повторюсь, многое зависит от кривости ПО RAID-контроллера
21 июл 09, 18:27    [7442038]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
полухохол
Member [заблокирован]

Откуда:
Сообщений: 448
a_shats,

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

Рейд 50 используется не ради быстрого ребилда, а для экономии до 30-40% денег. Вам надо набрать определенную емкость, а значит сколько то дисков и полок и стоек. Для RAID50 и 60 их просто надо меньше. Если проиводительность при этом приемлемая, то используют именно их.

Когда денег хватает то используют RAID10. RAID60 используется по причине того, что есть производители мидренж массивов, которые не поддерживают любые разновидности RAID5. NetApp например. Энтерпрайз массивов я таких не видел.

Про уделает-не уделает - 2008 уделает. В моем распоряжении несколько десятков мощных серверов включая стендбаи и тестовые и на некоторых из них контроллеров штук по 8. И такие эксперименты я проводил и провожу.

Про Оракл. Оракл НЕ балансирует нагрузку по IO. Он тупо аллоцирует экстенты по всем датафайлам в тейблспейсе циклически. Если стоит ASM то он старается наделать датафайлов от одного тэйблспейса на всех доступных устройствах. Это не балансировка, а фигня. MS SQL тут далеко от него оторвался, он честно балансирует нагрузку опираясь на статистику.


Вот кстати почему я всегда сам рассчитываю спецификацию серваков под БД, что под Оракл, что под MS SQL. Почти в любой конторе есть типа гуру которому только дай, он такого насчитает, что хоть стой хоть падай. Обычно в 1.5-2 раза дороже моего выходит, и работает медленнее раза в 2. Проверяли.
Нет чтобы книжку почитать по MS SQL, нафига, гуру же.
21 июл 09, 19:26    [7442235]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
iljy

да оттуда, что у нас операции независимые. и массив не будет метаться между данными, временной базой и логом. а на вашем примере - оттуда, что данные будут читаться со всех винтов параллельно. хотя конечно в вашем случае немного проиграем - интенсивность работы с логом у вас очень низкая, и один винт фактически выпадает, а если и к tempdb обращений нет (хотя врядли, но зависит от запросов) - то 2. Но у вас уж больно режим специфический.
У меня %) ?
Еще раз намекаю: от чего операции независимые ? От RAID-контроллера ?
подсказываю - дело тут не в кеше, а в том, что запрос к разным группам может физически обрабатываться параллельно. Вместе с позиционированием головок и прочей сопутствующей машинерией.
Это уже на религию похоже.
Еще раз подсказываю: RAID-контроллер, получив запрос на операцию ввода-вывода, производит ея сам. Никакая ОС, никакой SQL, никакой софт кроме родного его управления на этот процесс повлиять не может.
Да, при относительно большом количестве винтов эффективно разложить нагрузки по типу на разные драйв-группы. А при малом - разница будет в лучшем случае незаметна, в худшем - будет просто отобрана производительность винтов у основной задачи, да и все.
Понимаете, SQL-server также писал далеко не один человек, и работали они над распределением нагрузки не меньше.

Да ну ? Используйте гугл, выясните для себя, когда появились RAID-контроллеры и когда MSSQL
И информации для такого распределения у сервера заведомо больше.

Дааааа ? Намекаю: область применения RAID несколько шире, чем СУБД.
Спор перестал быть конкретным. Соберите себе конфу как у автора и проверьте оба варианта.
Вы бы мне объяснили еще, с какой радости я обязан собирать себе конфу, убить кучу рабочего времени и доказать или опровергнуть Ваши утверждения ?
Для себя-то я вопрос давно прояснил. О чем и пишу.
22 июл 09, 10:57    [7443887]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
a_shats
Member

Откуда: Москва
Сообщений: 814
полухохол
a_shats,
Выбранный уровень рейд напрямую зависит от размера базы. Оптимально конечно для любого размера RAID1, но админить начиная с нескольких десятков зеркал ее невозможно.
Какой ужос. А как же хайэндовые массивы-то админят, с сотнями-тысячами винтов ???
Рейд 50 используется не ради быстрого ребилда, а для экономии до 30-40% денег. Вам надо набрать определенную емкость, а значит сколько то дисков и полок и стоек. Для RAID50 и 60 их просто надо меньше. Если проиводительность при этом приемлемая, то используют именно их.
Неее, вот Вы мне детально расскажите - каким же это подсвешником RAID50 экономит 30-40 процентов денег. И с какого известного органа "для RAID50 и 60 их просто надо меньше".
Подсказываю: производительность дискового массива от его объема никак не зависит. На случайном доступе - зависит только от количества винтов.
Когда денег хватает то используют RAID10. RAID60 используется по причине того, что есть производители мидренж массивов, которые не поддерживают любые разновидности RAID5. NetApp например. Энтерпрайз массивов я таких не видел.
RAID DP != RAID60. Да и вообще сравнивать некорректно, ибо NetApp это RAID 4/RAID DP + WAFL.
Про уделает-не уделает - 2008 уделает. В моем распоряжении несколько десятков мощных серверов включая стендбаи и тестовые и на некоторых из них контроллеров штук по 8. И такие эксперименты я проводил и провожу.

Про Оракл. Оракл НЕ балансирует нагрузку по IO. Он тупо аллоцирует экстенты по всем датафайлам в тейблспейсе циклически. Если стоит ASM то он старается наделать датафайлов от одного тэйблспейса на всех доступных устройствах. Это не балансировка, а фигня. MS SQL тут далеко от него оторвался, он честно балансирует нагрузку опираясь на статистику.

Вот даже зарываться в вопрос не стану. После жести про RAID50 и RAID60 Ну и мериться длиной известного органа конфигурацией стендов тоже желания нет.
Вот кстати почему я всегда сам рассчитываю спецификацию серваков под БД, что под Оракл, что под MS SQL. Почти в любой конторе есть типа гуру которому только дай, он такого насчитает, что хоть стой хоть падай. Обычно в 1.5-2 раза дороже моего выходит, и работает медленнее раза в 2. Проверяли.

Ойжебожмой, так вот откуда берутся изобретатели мега-конфигураций, вызывающих мат и агрессию у любого вменяемого железячника
Нет чтобы книжку почитать по MS SQL, нафига, гуру же.
Где я писал, что гуру ? Цитату в студию. Про "почитать про MSSQL" - не скажу за конкретно MSSQL навскидку, но их whitepapers про сайзинг терминалки, например, вызывают просто демонический хохот и море пожеланий, чтоб их собственный офис поработал в терминалке на таких конфигах. Надеюсь, в гугле Вас не забанили ?
Хотя в последнее время начинают исправляться - их измерения от реалий уже не в десятки - всего в 5-6 раз отличаются
22 июл 09, 11:13    [7444024]     Ответить | Цитировать Сообщить модератору
 Re: Проблемы с MS SQL под Raid 5 SRCU-42L  [new]
iljy
Member

Откуда:
Сообщений: 8711
как же все-таки тяжко с вами гурами... плохо только что народ на вас ведется.
a_shats
iljy

да оттуда, что у нас операции независимые. и массив не будет метаться между данными, временной базой и логом. а на вашем примере - оттуда, что данные будут читаться со всех винтов параллельно. хотя конечно в вашем случае немного проиграем - интенсивность работы с логом у вас очень низкая, и один винт фактически выпадает, а если и к tempdb обращений нет (хотя врядли, но зависит от запросов) - то 2. Но у вас уж больно режим специфический.
У меня %) ?
Еще раз намекаю: от чего операции независимые ? От RAID-контроллера ?

у вас, у вас! "тяжелые отчеты", про которые вы говорили, - это практически последовательное поточное чтение. естественно RAID в таких условиях ведет себя отлично. А операции независимые - друг от друга. Т.е. обращения к журналу и к данным выполняются параллельно на разных физических устройствах.

подсказываю - дело тут не в кеше, а в том, что запрос к разным группам может физически обрабатываться параллельно. Вместе с позиционированием головок и прочей сопутствующей машинерией.
Это уже на религию похоже.
Еще раз подсказываю: RAID-контроллер, получив запрос на операцию ввода-вывода, производит ея сам. Никакая ОС, никакой SQL, никакой софт кроме родного его управления на этот процесс повлиять не может.

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

И информации для такого распределения у сервера заведомо больше.

Дааааа ? Намекаю: область применения RAID несколько шире, чем СУБД.

Намекаю - именно поэтому в данном конкретном случае SQL, оптимизирующий доступ конкретно под себя, имеет заведомо больше шансов получить производительную систему.

Вы бы мне объяснили еще, с какой радости я обязан собирать себе конфу, убить кучу рабочего времени и доказать или опровергнуть Ваши утверждения ?
Для себя-то я вопрос давно прояснил. О чем и пишу.

Да чтоб вы глупости перестали писать, раз уж читать не умеете. Может практические занятия помогут бедному инженеру.
22 июл 09, 11:15    [7444042]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 [2] 3   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить