прикупить дисковую стойку к серверу DL580 или заниматься оптимизацией?

[avzh]

Цитата:

Сообщение от omk

у меня тоже есть дилемма - прикупить дисковую стойку к серверу DL580 или заниматься оптимизацией.
стойка такая - http://h10010.www1.hp.com/wwpc/ru/ru/sm/WF...6-12312402.html
думаю десяток дисков в 5 зеркалах туда поставить
даст ли она ощутимого прироста в скорости работы сервера или нет? может кто использовал похожую?
диски там SATA, интерфейс U320. в самом сервере всего 4 диска можно поставить, от этого и пляшу.
но оптимизацией софта уже начали заниматься...

На производительность дисковых операций очень влияет размер кэша рэйд-контроллера и то, как он распределен (сколько для записи, сколько для чтения). Нужно выставить 100% на запись, или хотя бы 80%. Разумеется, должен быть BBWC.

[vesna dba]

Цитата:

Сообщение от azhukov

На производительность дисковых операций очень влияет размер кэша рэйд-контроллера и то, как он распределен (сколько для записи, сколько для чтения). Нужно выставить 100% на запись, или хотя бы 80%. Разумеется, должен быть BBWC.

А я вот с Вами не согласен!
К принятию такого решения необходимо подходить обоснованно.
Надо сначала провести мониторинг производительности дисковых операций.
Выяснить, каких операций у вас больше - на чтение или на запись. Исходя из этого уже управлять размерами кэша.
Приминительно к кэшу на запись - (если вы стойку используете под SQL базу данных) обязательно контроллер должен быть с батареями резервного питания, иначе при отключении электропитания от дисковой стойки вы сильно рискуете базой данных.
--
Например применительно к Аксате у нас (использ. дисковый массив HP MSA 1000) нагрузка на дисковую подсистему по чтению\записи (по очередям к дискам) соотношение где-то 80%\20%.
КЭШ - 2 модуля по 256Мб
Размеры кэша выставлены 50%\50%. Подумываю об изменении размеров в сторону увеличения размеров под чтение данных.

[avzh]

Цитата:

Сообщение от vesna dba

А я вот с Вами не согласен!
К принятию такого решения необходимо подходить обоснованно.
Надо сначала провести мониторинг производительности дисковых операций.
Выяснить, каких операций у вас больше - на чтение или на запись. Исходя из этого уже управлять размерами кэша.
Приминительно к кэшу на запись - (если вы стойку используете под SQL базу данных) обязательно контроллер должен быть с батареями резервного питания, иначе при отключении электропитания от дисковой стойки вы сильно рискуете базой данных.
--
Например применительно к Аксате у нас (использ. дисковый массив HP MSA 1000) нагрузка на дисковую подсистему по чтению\записи (по очередям к дискам) соотношение где-то 80%\20%.
КЭШ - 2 модуля по 256Мб
Размеры кэша выставлены 50%\50%. Подумываю об изменении размеров в сторону увеличения размеров под чтение данных.

Если у Вас большей частью читаются одни 256-512мб данных, то до обращения к дисковой системе вообще дело не дойдет, так как эти данные будут в кэше БД (Во всяком случае в Оракл). Кстати (автору топика), размер последнего очень важен, если время ввода-вывода не устраивает. Если же читаете не один 256 мб кусок данных, то чтения с дисков с 256 мб кэша рэйд-контроллера все равно не избежать. А для операций записи кэш дает очень сильное ускорение. Хотя, нужно просто попробовать и посмотреть, как будет лучше. У меня результат был в пользу увеличения "на запись".

[vesna dba]

Цитата:

Сообщение от azhukov

Если у Вас большей частью читаются одни 256-512мб данных, то до обращения к дисковой системе вообще дело не дойдет, так как эти данные будут в кэше БД (Во всяком случае в Оракл).

Дело не дойдет на уровне дисковой стойки.
Не факт что эти данные будут у вас в кэше сервера баз данных (это зависит напрямую от размера оперативной памяти, отданной под сервер баз данных).

У нас больше читаются последовательные кусочки по 2-3Гб
База данных размером > 70 Гб
Сервер БД - MS SQL Server 2000 EE, ОЗУ под него - 8Гб

Размер кэша на RAID контроллере действительно дает большой прирост в производительности дисковой стойки.
Но к его перераспределению стоит подходить обоснованно, после мониторинга и тестирования. В этом мы с вами солидарны.