Performance impact of controller cache

Вопросы программирования БД, их оптимизации, резервирования и восстановления данных.

Модераторы: Trinity admin`s, Free-lance moderator`s

Ответить

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 10 июл 2008, 12:23

Vadik
А какая, извините, разница, какого размера у сиквела buffer pool - сравниваются-то три варианта распределения кэша одного и того же контроллера на одном и том же сервере (т.е. с одним и тем же buffer pool)?
Интересно с целью понять условия тестирования.
Какую запись может генерировать чистый table scan select - затрудняюсь представить
Я тоже. Но как ему может мешать кэш чтения, если отключить read-ahead тоже не пойму.
Пришла в голову мысль, что именно о влиянии read-ahead идет в итоге речь, а не о кэше.
У сиквела нет лога. Лог есть у БД, коих на сиквеле несколько.
Я знаю (с)  :D  Я имел в виду лог БД.
А то, что большой кэш на чтение ни в одном из сценариев ничего, кроме ухудшения результатов, ничего не дал, ни на какие мысли не наводит?
См. выше. "Тупой" read-ahead, а не собственно кэш.
Размер страницы Вы знаете - вот и посчитайте
А там (по третьей ссылке) и счетчики приведены, вообще-то. Хотя прямо на реальный размер блока они, конечно же не указывают ;)
А в чем криминал? Buffer pool больше размера кэша контроллера в 4 раза? В жизни не так? М.б., где-то (не на стенде - в production) трудятся сервера БД, у которых все наоборот - кэш контроллера равен или больше? Не встречал
Не в этом дело. Процитирую себя:
Теперь предлагаю вспомнить цифирь обратно    Вышеописанное означает, что тест работает примерно как IOMeter с отключенными Transfer Delay и Burst Length, т.е. кэш контроллера насмерть забивается
В таких условиях никакая мега-логика кэширования любого контроллера не поможет. Чрез него тупо прокачиваются не сравнимые  с его размером объемы, идет сплошной кэш-мисс, и все дела.
In the comments on Joe Chang’s blog at this site on Storage Performance for SQL Server, some statements were made concerning the performance impact of read cache in a disk controller.
А я утверждаю, что тут дело не в нем, а в сильно упрощенных алгоритмах read-ahead контроллера.

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 10 июл 2008, 13:08

a_shats писал(а): А я утверждаю, что тут дело не в нем, а в сильно упрощенных алгоритмах read-ahead контроллера.
Ок. Есть в пределах Солнечной системы контроллеры с продвинутым алгоритмом read-ahead, которые существенно выигрывают при увеличении доли кэша на чтение в используемых автором сценариях (вполне жизненных, по-моему)?
Я тоже. Но как ему может мешать кэш чтения, если отключить read-ahead тоже не пойму
Кэш чтения контроллера мешает (в лучшем случае - не помогает), когда из него, бедного, пытаются получить то, что даже в большем по размеру buffer pool не удержалось. Результат поиска (отрицательный) с большой долей вероятности известен заранее, а задержка-то добавляется гарантированно
Пришла в голову мысль, что именно о влиянии read-ahead идет в итоге речь, а не о кэше
Неа. О кэше :)

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 10 июл 2008, 13:47

Есть в пределах Солнечной системы контроллеры с продвинутым алгоритмом read-ahead
Есть - IBM DS8000, EMC DMX4...

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 10 июл 2008, 13:53

Ну почему - есть и попроще. И пример был.
Тестили IOMeter'ом по 2 полки Xyratex F5402E (24 винта) и HDS AMS500 (30 винтов), на первой 1 ГБ кэша на контроллер, на второй 2.
Так вот - сколько винты могли, столько они и дали, и можно сказать, что AMS500 даже отстала.
Тестили БД оракловую 10 ГБ объемом (т.е. тоже заведомо больше кэша), нагрузка в основном чтение (формирование отчета по этой базе), при пуле в  1 ГБ (т.е. был тест именно дисковой) - получили 16-18К IOps с 2 полок AMS500.  Xyratex не тестили на этой конкретной задаче.
Я более чем уверен, что тест по 3 ссылке, проведенной на дисковой типа той же AMS500 с хотя бы даже полкой винтов показал иные результаты.
То бишь read-ahead PCI-контроллеров read-ahead'у внешних серьезных машин lupus est  :D

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 10 июл 2008, 14:08

exLH писал(а):Есть в пределах Солнечной системы контроллеры с продвинутым алгоритмом read-ahead
Есть - IBM DS8000, EMC DMX4...
К сожалению, вторая часть моего вопроса
которые существенно выигрывают при увеличении доли кэша на чтение в используемых автором сценариях
при цитировании потерялась :(
a_shats писал(а):Ну почему - есть и попроще. И пример был
Сравнивали результаты с включенным и отключенным кэшем на чтение? Если нет - это опять разговор глухого со слепым :(

Аватара пользователя
exLH
Сотрудник Тринити
Сотрудник Тринити
Сообщения: 5061
Зарегистрирован: 11 фев 2004, 15:49
Откуда: Москва
Контактная информация:

Сообщение exLH » 10 июл 2008, 14:21

Vadik
при цитировании потерялась
Это не значит, что она потерялась в ответе.

a_shats
В системах "попроще" нормального префетча ожидать не стоит. Можно получить иометром что угодно - он все равно на кэш внимания практически не обращает (до тех пор пока явно туда нагрузку не загнать).

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 10 июл 2008, 14:28

exLH
Я выше про разницу между IOMeter и реальной задачей и написал :)
Vadik
Нет, не сравнивал - такой задачи не стояло. Но: согласитесь, что 16-18К IOps c 30 винтов 15К rpm без весьма продвинутых предвыборки и кэширования - нереально ?

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 10 июл 2008, 14:43

a_shats писал(а):Но: согласитесь, что 16-18К IOps c 30 винтов 15К rpm без весьма продвинутых предвыборки и кэширования - нереально ?
К read-ahead у меня претензий нет. Как кэш может помочь в сценарии, о котором говорит автор (table scan, т.е. как раз large sequential IO, данные в кэше контроллера не помещаются) я что-то в толк не возьму. Объяснил бы кто-нибудь подоступнее, на пальцах, без космических кораблей, бороздящих просторы космоса..
Впрочем, чувствую, не прийти нам к консенсусу в этой ветке. Ну да ладно
:beer:

Аватара пользователя
a_shats
Advanced member
Сообщения: 5010
Зарегистрирован: 27 авг 2002, 10:55
Откуда: Москва
Контактная информация:

Сообщение a_shats » 10 июл 2008, 14:45

Vadik
Как кэш может помочь в сценарии, о котором говорит автор (table scan, т.е. как раз large sequential IO, данные в кэше контроллера не помещаются) я что-то в толк не возьму.
По третьей ссылке тоже sequential I/O ? Или таки OLTP-нагрузка ?  :P
Опять-таки : согласитесь, что последовательное чтение в небольшое количество Outstanding I/Os - не самый частый случай в работе с БД ? Или не согласитесь ? :)

Vadik
Advanced member
Сообщения: 81
Зарегистрирован: 16 фев 2004, 22:49
Откуда: Moscow
Контактная информация:

Сообщение Vadik » 11 июл 2008, 11:17

a_shats писал(а):Опять-таки : согласитесь, что последовательное чтение в небольшое количество Outstanding I/Os - не самый частый случай в работе с БД ? Или не согласитесь ? :)
Отчего же, соглашусь :)

Ответить

Вернуться в «Серверы - ПО, Базы Данных и их использование»

Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей и 9 гостей