Performance impact of controller cache

[a_shats]

Здесь обсуждаем эту статью:
http://sqlblog.com/blogs/linchi_shea/ar ... tions.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... -i-os.aspx
http://sqlblog.com/blogs/linchi_shea/ar ... loads.aspx

Начало - в этой ветке.

[a_shats]

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]

А я утверждаю, что тут дело не в нем, а в сильно упрощенных алгоритмах read-ahead контроллера.

Ок. Есть в пределах Солнечной системы контроллеры с продвинутым алгоритмом read-ahead, которые существенно выигрывают при увеличении доли кэша на чтение в используемых автором сценариях (вполне жизненных, по-моему)?

Я тоже. Но как ему может мешать кэш чтения, если отключить read-ahead тоже не пойму

Кэш чтения контроллера мешает (в лучшем случае - не помогает), когда из него, бедного, пытаются получить то, что даже в большем по размеру buffer pool не удержалось. Результат поиска (отрицательный) с большой долей вероятности известен заранее, а задержка-то добавляется гарантированно

Пришла в голову мысль, что именно о влиянии read-ahead идет в итоге речь, а не о кэше

Неа. О кэше

[exLH]

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

[a_shats]

Ну почему - есть и попроще. И пример был.
Тестили 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]

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

К сожалению, вторая часть моего вопроса

которые существенно выигрывают при увеличении доли кэша на чтение в используемых автором сценариях

при цитировании потерялась

Ну почему - есть и попроще. И пример был

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

[exLH]

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

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

[a_shats]

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

[Vadik]

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

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

[a_shats]

Vadik

Как кэш может помочь в сценарии, о котором говорит автор (table scan, т.е. как раз large sequential IO, данные в кэше контроллера не помещаются) я что-то в толк не возьму.

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

[Vadik]

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

Отчего же, соглашусь