Добрый день, Informix гуру.

Есть ли среди вас кто-нибудь, кто настраивал Informix специально под
дисковый массив?


Добрый.

По моему нужно делать совсем наоборот - дисковый массив настраивать под базу данных.



HPUX 11.11, IDS 9.21.HC4, дисковый массив Hitachi 9960

Проблема в том, что когда на соседнем сервере раскручивается большой
архив, в Informix'e checkpoint'ы сильно увеличиваются и прикладное ПО
начинает тормозить (что недопустимо).

Текущий onconfig приложу, если надо...


Конкретно с Hitachi 9960 работать не приходилось, но отзывы слышал
и не плохие.

Теперь по существу настройки:
У массива есть определенные характеристики скорости обмена
за период времени. Как правило это значение максимально при
максимальном значении блока(stripe) хранения или как он там называется в массиве. И какой у Вас размер блока ? 128К или больше?
Во всяком случае так рекомендуют вендоры (казлы).
(Устал уже им доказывать, что это вредно для
многопользовательской базы данных или чистого OLTP приложения)

При индексном поиске informix читает с диска блоками равными размеру страницы (4к в вашем случае) за одну дисковую операцию.
То есть если размер блока массива 128 К, а по индексу вы вычитываете 4К.
То 124К на каждой дисковой операции вы вычитываете наперед(ahead) в кеш массива. Прикиньте какова вероятность попадания следующей страницы по
индеку в эти 124К?
Через некоторое время наступит момент когда эта страница, найденная по индексу, или еще хуже часть индекса, будет вытеснена из кеша контроллера
вместе с так и не исползованными 124К. И контролеру ее придется перечитывать ее с диска опять. И чем больше у вас размер блока тем быстрее наступит этот момент и тем ниже эффективность использования кеша контроллера.
Учтите, что запись в массив производится тоже блоками, то есть
меняя одну страницу(4к) контроллер переписывает 128К на диске,
а если это RAID5 то для этих 128К нужно пересчитать и переписать контрольные значения.

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

2. Каждое приложение должно иметь свой том на дисковом массиве
а может и не один. Респект Денису Журавлеву.
Например: под индексы с малым блоком, под блобы с большим. У меня, в частности, есть таблицы, фрагментированные по 20 томам.


3.Для полных сканирований таблиц можно иметь большие блоки.

4. На практике(как правило) производительность (объем/кол.операций) для нескольких малых томов выше, чем для одного большого, засчет
распаралеливания очередей ввода/ввывода и многопоточности RISK
процессора на контролере.


С уважением, onstat-

p.s. Приветствуются дополнения и конструктивная критика.

Журавлев Денис

IMHO: Тут главное не перестараться, и не поставить слишком маленький. Страйп то у раида настраиваемый, но тут уже обсуждали что диск тоже оперирует блоками которые читает в свой кэш. Т.е. заставлять диск считать 100 байт бесмысленно, он все равно в свой кэш закинет ~кб(?).


Понятное дело ко всему нужно подходить взвешенно.
А перестараться тяжело, информикс читает кратно размеру
страницы то есть 2к или 4 к
за дисковую операцию. И никогда меньше.

С уважением onstat-

Daugavaonstat -
можно возразить. Даже при настроенном по умолчанию RA (Read Ahead), это далеко не так. Впрочем, перед этим говорилось про OLTP, в котором RA не играет большой роли.
Впрочем, у меня система близкая к чистому OLTP, и при этом страницы, прочтенные наперед, составляют примерно 80% от общего объема дискового чтения.

При индекстом поиске параметр влияет на упреждающее чтение
только индексного дерева.


RA_PAGES specifies the number of disk pages to attempt to read ahead
during sequential scans of data or index records. Read-ahead can greatly
speed up database processing by compensating for the slowness of I/O
processing relative to the speed of CPU processing.


При полном сканировании согласен, но это не наш случай.

С уважением, onstat-

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

-----------------------------------------------------------
Хочу есть. myinformix

Думаю onstat -P поможет товарищу.
Если бы база лежала на только своих томах, былобы проще.
Ищем самых грязных, по партнуму вычисляем объект,
выносим на самый ненагруженный том.
OFF: Сколько денег на покупке нового обрудования съэкономить можно?

с уважением, onstat-

P.S. I'm hungry too.