Производительность дисковой подсистемы и SQL Server 2000

Сообщение gs » 17 мар 2006, 15:20

Видите какая фишка. У Вас данные были на двух томах, на которых очередь соответственно была 17 и 4. Сейчас один том с очередью 4, винтов стало ненамного больше. Собственно уже существенно лучше. Но мало, т.к. очередь практически постоянная. Видимо надо еще больше винтов

Кстати, почему бы не сделать два луна и не выдать их через два контроллера? Суммарный объем кэша станет больше.

А как по субьективным ощущениям?

Sergey Petrov

Очереди: было 17, стало 4 в среднем; передачи данных: было 602, стало 298; чтения: было 7 637 289, стало 6 041 298; записи: было 1 836 472, стало 1 069 210. Данные все привожу "по среднему", потому что тип нагрузки примерно одинаков (ночной период без особых временных изменений, дневной тоже). Вывод: дисковые очереди снизились при сохранении пропускной способности. Чем объяснить уменьшение disk transfers/sec - не знаю.

Сообщение gs » 17 мар 2006, 15:34

А программеры не порулили часом?

Sergey Petrov

Насчёт программеров не знаю - надо у них спросить. Но вроде радикально ничего не менялось. Насчёт LUNов - у нас по совету сотрудников Trinity был создан один большой массив RAID10, на котором нарезаны 2 логических драйва (первичным для них стоит имеющийся контроллер, Write caching with mirroring отключён). Второй контроллер нам просто не дали при комплектации стойки. Я звонил на этот счёт - Геннадий сказал, что он, в принципе, не нужен.

То есть, и без него будет работать. Хорошо б, конечно, второй, но и так можно. На тестирование. Сергей Селезнёв обещал появиться на этой неделе, но так и не появился. Очевидно, я должен сам был о себе напомнить. Надеюсь, что на следующей неделе, которая обязательно будет лучше текущей (;)), мы встретимся. [/list]

Сообщение **Stranger03** » 17 мар 2006, 17:59

Sergey Petrov писал(а):Насчёт программеров не знаю - надо у них спросить. Но вроде радикально ничего не менялось

Мммм, в данной конфигурации второй контроллер вам действительно не нужен. Второй контроллер вам будет привезен вместе с сервером, хммм.

Сообщение **Stranger03** » 17 мар 2006, 18:03

Ведь у нас с вами был разговор о том, что существующая дисковая система переживает не лучшие времена. Вот потому вам и была второй раз предоставлена дисковая стойка раньше. Изначально мы планировали предоставить стойку с сервером вместе.
Приехать к вам в понедельник должен был Петр, но по каким-то причинам его поездка отменилась (я в это время был в Москве). По письму Дмитрия Мозгового наша помощь вам в данном вопросе не нужна, теперь я вижу, что все-таки нужна?

Sergey Petrov

Видите ли, Геннадий, помощь Петра была бы нам необходима, если бы я самостоятельно не смог смонтировать стойку, проинсталлировать софт и сделать систему рабочей. Вопрос в том, чтобы сделать систему ещё более производительной. В прошлый понедельник мне удалось связаться с Вашим сотрудником Сергеем Селезнёвым, только что вернувшимся из поездки в Лондон (кажется). Я попытался задать ему свои вопросы - только для подтверждения того факта, что я всё сделал правильно и мои действия не обернутся для системы непоправимыми последствиями. Он мне ответил, что всё вроде в порядке, но лучше он сам приедет к нам со вторым контроллером, установит его, настроит систему на работу с двумя контроллерами и на этом всё. К сожалению, я сам не связался с Сергеем во вторник (на по телефону, ни по ICQ), а он тоже не вышел на связь. А теперь ещё и сервер к нам приедет на следующей неделе. Интересно, спасут ли нас дальнейшие системные навороты?.. Пока не уверен.

Сообщение **CyberDrake** » 20 мар 2006, 11:12

Прошу прощения за мой неприезд, произошла организационная накладка, видимо мы с Геннадием непраильно поняли друг друга.
Если планируется только один логический диск, то добавление второго контроллера повысит отказоустойчивость, но не даст прироста производительности, так как запросы к логиескому диску обрабатываюстя одним контроллером. При этом контроллера-владельца логического диска можно сменить вручную. Кстати можно попробовать сделать на массиве два логических диска, которые следует объединить в stripe средствами ОС, тогда при работе будут задействованы 2 контроллера, что в ряде случаев дает значительный прирост производительности, но опять же это надо тестировать на конкретной задаче.

Сообщение **Stranger03** » 20 мар 2006, 11:21

Sergey Petrov писал(а):Видите ли, Геннадий, помощь Петра была бы нам необходима, если бы я самостоятельно не смог смонтировать стойку, проинсталлировать софт и сделать систему рабочей. Вопрос в том, чтобы сделать систему ещё более производительной.

Разве не это мы с вами пытались сделать до сих пор? Можете ли вы мне позвонить или вылезти в аську для решения наших вопросов? Думаю нам с вами достаточно созвониться,

.

Сообщение **Stranger03** » 20 мар 2006, 12:14

И еще Сергей, у нас с Сергеем Селезневым был реальный пример на задаче один в один похожей с вашей задачей. Почему я вам рекомендовал сделать один логический диск, ровно потому, что на нашем примере разбивка массива на три группы под данные, логи и индексы приводила к понижению производительности в 3 раза. В данном же случае хоть очередь к дискам и большая, но все-таки меньше, чем в случае 320-го контроллера. Разве нет?

Sergey Petrov

В принципе, единственное, что хотел выяснить - правильность выбора опций при инсталляции и инициализации стойки.
А именно, опцию "Enable write caching without batteries" я отключил, поскольку батарейка есть, опция " Enable write caching with mirroring" включена.
Далее, при инициализации логических драйвов в винде я указал тип драйва "dynamic" (он вроде позволяет динамически увеличивать размер тома) и в свойствах тома установил "Policies\Enable advanced performance", что позволяет системе понадеяться на батарйку и писать данные на диск побыстрее. Хотя, в принципе, наверное эта опция имеет на нас мало влияния, поскольку у нас превалирует чтение, а не запись.
Сейчас всё в принципе работает, но хотелось бы знать, может я что-то не так или не до конца сделал? Обращаюсь к Вашему опыту.

Ещё один немаловажный момент - нам предстоит очередное тестирование. На этот раз с сервером от IBM. Если дисковый массив с уже имеющимися на нём данными просто перевести на новый сервер - возможно ли это сделать так, чтобы заново не перезаливать все данные и как это чисто технически будет осуществлено? Сколько времени займёт? Мы просто цепляем тома к операционке и аттачим базу?

Теперь об одном логическом драйве - в принципе, всё возможно и мы можем попробовать в новой конфигурации с новым сервером не разбивать имеющееся пространство на несколько логических драйвов, а создать один большой и уже на нём размещать все данные. Что в таком случае делать с файловыми группами в SQL Server? Перевести все файлы данных в одну или оставить как есть (сейчас наши основные данные разбиты на 2 файловые группы для разнесения по разным логическим томам)? Теоретически разницы для базы никакой, а вот практически...
Думаю, последний вопрос надо обсудить и с нашим программистом.

Насчёт снижения дисковых очередей - результат налицо. Насколько приемлем тот уровень, который присутствует сейчас? Какое пороговое значение для этого параметра с нашей стойкой? По общей производительности приложения - мало что изменилось (как ни странно). Может, затык ещё в чём-то? Как его можно выявить?

Сообщение **Stranger03** » 20 мар 2006, 12:49

Sergey Petrov писал(а):В принципе, единственное, что хотел выяснить - правильность выбора опций при инсталляции и инициализации стойки.

Как только что сказал Селезнев, все правильно сделали,

.

Ещё один немаловажный момент - нам предстоит очередное тестирование. На этот раз с сервером от IBM. Если дисковый массив с уже имеющимися на нём данными просто перевести на новый сервер - возможно ли это сделать так, чтобы заново не перезаливать все данные и как это чисто технически будет осуществлено?

Это можно спокойно сделать не перезаливая базы. Технически выглядит, как если бы вы вытащили диск и подключили к другому серверу. Эту процедуру вам поможет сделать Сергей Селезнев.

Сколько времени займёт? Мы просто цепляем тома к операционке и аттачим базу?

Именно так, правда в настройках стойки видимо надо будет подправить циферки, какие - знает Серега,

Теперь об одном логическом драйве - в принципе, всё возможно и мы можем попробовать в новой конфигурации с новым сервером не разбивать имеющееся пространство на несколько логических драйвов, а создать один большой и уже на нём размещать все данные. Что в таком случае делать с файловыми группами в SQL Server? Перевести все файлы данных в одну или оставить как есть

Здесь сложно сказать. По заверениям Майкрософт надо делать отдельные группы, под данные, логи, индексы. Но вот когда мы делали по рекомендациям, все было плохо. Надо пробовать и тестно сотрудничать с программистами.

производительности приложения - мало что изменилось (как ни странно). Может, затык ещё в чём-то? Как его можно выявить?

Давайте дождемся сервера и решим вместе. Я приеду с Серегой к вам, там обсудим, как лучше сделать. Затык может быть как в процессорах, сетевых очередях. К слову, посмотрите что там с сетью, какой показатель network utilization.

Sergey Petrov

Параметр Network Inteface\Bytes Total/sec порядка 1 500 000 при гигабитной карте и сети.

Сообщение **Stranger03** » 20 мар 2006, 15:58

Sergey Petrov писал(а):Параметр Network Inteface\Bytes Total/sec порядка 1 500 000 при гигабитной карте и сети.

Не, поставьте на сервере "Нетворк Монитор", запустите его на сетевом интерфейсе, интересны параметры Network Utilization и ошибки в канале. Если первый параметр в пиках больше 30-ти, это плохо. Если не превышает 10-ти, 15-ти, то нормально.

Sergey Petrov

Сейчас %Network Utilization = 1, Network Card (MAC) Error statistics все по нулям.

Производительность дисковой подсистемы и SQL Server 2000

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