IDE RAID

vvm13 · Сообщение **vvm13** » 29 янв 2003, 11:32

vvm13 писал(а): Запрос типа "SELECT COUNT(*) ... WHERE field like '%'", то есть простое последовательное сканирование.

Точнее,
SELECT COUNT(*) ... WHERE field like '%1%', такие запросы не оптимизируются.

a_shats · Сообщение **a_shats** » 29 янв 2003, 11:49

Не стану оспаривать цифры, но, исходя из принципов работы самого SQL-сервера, подобная методика может(и должна) дать при каждом запуске разные цифры. Очень разные.
Такие запросы не оптимизируются при условии,что нет индекса по выбранному полю (либо комплексного), включающего описанную в запросе часть данного поля.
Я не сильно разбираюсь в DB2

, но - в любом случае и для большинства серверов SQL- если явно не указан план запроса, то запрос оптимизируется автоматически, в соответствии с умолчаниями для оптимизатора запросов. Кроме того, при выполнении COUNT производится собственно выборка только одного - ключевого- поля, а не всей строки. Опять таки, кэши sql-сервера и файловый кэш ОС свои коррективы внесут...

В любом случае, получить приемлемую производительность для БД на IDE -массиве несравненно труднее (а когда база выезжает за 1-2 Гб - то, имхо, и невозможно), нежели на SCSI или FC. Имхо, конечно же.

vvm13 · Сообщение **vvm13** » 29 янв 2003, 12:03

Однако цифры по чтению были примерно одинаковыми. Разумеется, поле field неключевое и индекса нет. План единственный - полное сканирование всей таблицы, чтение блоками по prefetch size (256K).

Кстати, чтение "одного поля" из таблицы невозможно в принципе - чтение происходит страницами, на каждой из которых по нескольку записей, естественно, со всеми полями; индекса же нет. Кеширование ОС отсутствовало (raw devices). Кеш sql-сервера, он же буферный пул, как я сказал, был в 250 страниц, т.е. 1 мегабайт.

a_shats · Сообщение **a_shats** » 29 янв 2003, 12:44

Кстати, чтение "одного поля" из таблицы невозможно в принципе

Мда ?

А что делать, когда строка вылазит за пределы страницы ? Строки таблиц БД -то на страницы не выравниваются. Нигде.

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

vvm13 · Сообщение **vvm13** » 29 янв 2003, 13:02

Я не думаю, что здесь это оффтопик, потому что мы обсуждаем производительность RAID'а для конкретного приложения, поэтому должны знать особенности этого приложения.

Чтение DB2 производит страницами (по умолчанию - 4К, хотя можно делать табличные пространства с 8, 16 и 32К) или блоками, содержащими целое число страниц (так называемый префетчинг). Запись не может быть размером больше страницы. Правда, возможны overflow, когда несколько записей умещались на странице, а потом в результате UPDATE полей типа VARCHAR перестали, тогда заводится новая страница и делаются ссылки со старой. Значит, придется не одну страницу читать, а две. В свежезаполненной таблице такого быть не может, а если во время UPDATE когда-нибудь возникает, то исправляется REORG'ом.

Long varchar'ы и BLOB'ы я здесь игнорирую и за поля не считаю

a_shats · Сообщение **a_shats** » 29 янв 2003, 14:22

Заинтриговали Вы меня окончательно

Дело в том, что (повторяюсь) страница служит исключительно для привязки логической структуры БД к физической. А вот размер строки таблицы может быть изменяем в зависимости от формата и конкретных данных (тот же varchar аналогичен null-terminated string, например, и в БД пишется в виде строки без завершающих пробелов). Страница - это элемент, которым оперируют платформно-зависимые части "движка" БД. К логическому устройству БД, в т.ч. строкам, таблицам и пр. страница имеет весьма опосредованное отношение.
Потому - лезу за документацией и буду читать. Неправ-извинюсь, прав - прокомментирую со ссылкой.

vvm13 · Сообщение **vvm13** » 29 янв 2003, 14:49

Какой документации - Oracle?

В DB2 на странице не может быть более чем 255 строк, почему большие размеры страниц могут оказаться невыгодными (если таблицы "узкие"). Да, строки не обязаны быть фиксированого размера, но ни одна из них не может быть больше страницы. Под таблицу, как я помню, выделяется целое число экстентов (в одном экстенте данные только одной таблицы). Префетч обычно делается целым числом экстентов (а это задается администратором БД).

The overflow number indicates the number of rows that do not fit on their original pages. This can occur when VARCHAR columns are updated with longer values. In such cases, a pointer is kept at the row's original location. This can hurt performance, because the database manager must follow the pointer to find the row's contents, which increases the processing time and may also increase the number of I/Os.

т.е. строка целиком перенесена на другую страницу, а на старой остался указатель.

vvm13 · Сообщение **vvm13** » 29 янв 2003, 15:05

А вот про создание таблицы: The sum of the byte counts of the columns, including the inline lengths of all structured type columns, must not be greater than the row size limit that is based on the page size of the table space (SQLSTATE 54010). Refer to Byte Counts and Table 33 for more information.

Код: Выделить всё

Размер     Макс длина Макс колич
страницы   строки     колонок
4K         4005        500  
8K         8101       1012  
16K        16293      1012  
32K        32677      1012

a_shats · Сообщение **a_shats** » 29 янв 2003, 17:46

Прочитал DB2 Administration Guide: Performance, Chapter 2. Architecture and processes.
Я был не прав, но и Вы - тоже не совсем правы

Из прочитанного понял, что данные разных типов (содержимое полей) раскладывается в файлики с соотв. форматом.

. В том, что запись за пределы страницы не выходит - Вы правы. В db2 - есть такое дело. Извиняюсь.

vvm13 · Сообщение **vvm13** » 30 янв 2003, 11:18

Ну, данные необязательно хранятся в файликах.

Меня волнует другое - что я делаю не так? Одно я уже сообразил: какой-такой префетч в 1024 страницы может быть при буферном пуле 250??? От щедрот души сделал буферный пул в 1024*100 страниц (примерно 400 мег), размеры данных примерно в 1,8 гига. Результаты чтения все равно обескураживающи:

1 диск - 82 секунды
4 раздельных диска - 48 секунд (почему не 21?)
RAID0+1, 4 диска - 50 секунд
RAID0, 4 диска - 97 секунд (просто позор)

Буду копать дальше. Возьму не рекомендованные в руководстве num_ioservers (и num_iocleaners), а прогоню в цикле. Попробую потестироваться также под линухом.

vvm13 · Сообщение **vvm13** » 30 янв 2003, 13:11

Да, когда в DB2 поставил num_ioservers=1, и RAID 0 начал давать 50 секунд, при большем же значении - в районе 90 секунд. (В руководстве же сказано, что num_ioservers рекомендуется ставить в зависимости от количества физических дисков). Похоже, что я уперся в производительность не дисков, а контроллера, и результаты мне уже не улучшить ;-(.

Key · Сообщение **Key** » 16 фев 2003, 05:26

А что, никто не пользовал продукцию фирмы 3Ware? Весьма должен заметить недурственное оборудование именно для файловой помойки. У меня сервер для резервного копирования собран в следующей конфигурации:

3Ware Escalade 7850 (8-канальный)
8 дисков IBM IC35L120AVVA

Объем тома RAID-5 составляет около 800 Гб. Когда я гонял машину тестом WinBench у меня получилась скорость линейного чтения около 120 Мб/с в начале диска. Конечно этот тест не есть тест для дисковой подсистемы сервера, но цифра впечетляет. Сервер бегает до сих пор, ни одного отказа дискового массива с момента создания не наблюдалось.

[RAF]TAHKuCT

Кстати на фцентре есть описание контроллеров 3Ware... очень интересно. Причем пишут о том, что в этих контроллерах есть оптимизация под R5, позволяющая получать трансфер в 70метров.

Сообщение **Dmitry** » 28 фев 2003, 11:02

Ну не верю я в IDE, будет с RAID качать 1 человек - может и будет 70MB, а вот если 5 человек - то будет 5MB (все цифры от балды - просто по идеологии работы IDE). Тенденция на лицо.

[RAF]TAHKuCT

Задача профессионала - не верить, но проверить.

Правда есть инфа, что такой 8 канальный контроллер стоит под 600 бкс...

для интересующихся - http://www.fcenter.ru/articles.shtml?hdd/4338

IDE RAID

IDE RAID

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