Производительность дисковой подсистемы и SQL Server 2000
Модераторы: Trinity admin`s, Free-lance moderator`s
- gs
- Сотрудник Тринити
- Сообщения: 16650
- Зарегистрирован: 23 авг 2002, 17:34
- Откуда: Москва
- Контактная информация:
Видите какая фишка. У Вас данные были на двух томах, на которых очередь соответственно была 17 и 4. Сейчас один том с очередью 4, винтов стало ненамного больше. Собственно уже существенно лучше. Но мало, т.к. очередь практически постоянная. Видимо надо еще больше винтов
Кстати, почему бы не сделать два луна и не выдать их через два контроллера? Суммарный объем кэша станет больше.
А как по субьективным ощущениям?
Кстати, почему бы не сделать два луна и не выдать их через два контроллера? Суммарный объем кэша станет больше.
А как по субьективным ощущениям?
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
Очереди: было 17, стало 4 в среднем; передачи данных: было 602, стало 298; чтения: было 7 637 289, стало 6 041 298; записи: было 1 836 472, стало 1 069 210. Данные все привожу "по среднему", потому что тип нагрузки примерно одинаков (ночной период без особых временных изменений, дневной тоже). Вывод: дисковые очереди снизились при сохранении пропускной способности. Чем объяснить уменьшение disk transfers/sec - не знаю.
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
Насчёт программеров не знаю - надо у них спросить. Но вроде радикально ничего не менялось. Насчёт LUNов - у нас по совету сотрудников Trinity был создан один большой массив RAID10, на котором нарезаны 2 логических драйва (первичным для них стоит имеющийся контроллер, Write caching with mirroring отключён). Второй контроллер нам просто не дали при комплектации стойки. Я звонил на этот счёт - Геннадий сказал, что он, в принципе, не нужен. То есть, и без него будет работать. Хорошо б, конечно, второй, но и так можно. На тестирование. Сергей Селезнёв обещал появиться на этой неделе, но так и не появился. Очевидно, я должен сам был о себе напомнить. Надеюсь, что на следующей неделе, которая обязательно будет лучше текущей (;)), мы встретимся. [/list]
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Ведь у нас с вами был разговор о том, что существующая дисковая система переживает не лучшие времена. Вот потому вам и была второй раз предоставлена дисковая стойка раньше. Изначально мы планировали предоставить стойку с сервером вместе.
Приехать к вам в понедельник должен был Петр, но по каким-то причинам его поездка отменилась (я в это время был в Москве). По письму Дмитрия Мозгового наша помощь вам в данном вопросе не нужна, теперь я вижу, что все-таки нужна?
Приехать к вам в понедельник должен был Петр, но по каким-то причинам его поездка отменилась (я в это время был в Москве). По письму Дмитрия Мозгового наша помощь вам в данном вопросе не нужна, теперь я вижу, что все-таки нужна?
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
Видите ли, Геннадий, помощь Петра была бы нам необходима, если бы я самостоятельно не смог смонтировать стойку, проинсталлировать софт и сделать систему рабочей. Вопрос в том, чтобы сделать систему ещё более производительной. В прошлый понедельник мне удалось связаться с Вашим сотрудником Сергеем Селезнёвым, только что вернувшимся из поездки в Лондон (кажется). Я попытался задать ему свои вопросы - только для подтверждения того факта, что я всё сделал правильно и мои действия не обернутся для системы непоправимыми последствиями. Он мне ответил, что всё вроде в порядке, но лучше он сам приедет к нам со вторым контроллером, установит его, настроит систему на работу с двумя контроллерами и на этом всё. К сожалению, я сам не связался с Сергеем во вторник (на по телефону, ни по ICQ), а он тоже не вышел на связь. А теперь ещё и сервер к нам приедет на следующей неделе. Интересно, спасут ли нас дальнейшие системные навороты?.. Пока не уверен.
- CyberDrake
- free-lance moderator
- Сообщения: 338
- Зарегистрирован: 23 авг 2002, 10:39
- Откуда: Санкт-Петербург
- Контактная информация:
Прошу прощения за мой неприезд, произошла организационная накладка, видимо мы с Геннадием непраильно поняли друг друга.
Если планируется только один логический диск, то добавление второго контроллера повысит отказоустойчивость, но не даст прироста производительности, так как запросы к логиескому диску обрабатываюстя одним контроллером. При этом контроллера-владельца логического диска можно сменить вручную. Кстати можно попробовать сделать на массиве два логических диска, которые следует объединить в stripe средствами ОС, тогда при работе будут задействованы 2 контроллера, что в ряде случаев дает значительный прирост производительности, но опять же это надо тестировать на конкретной задаче.
Если планируется только один логический диск, то добавление второго контроллера повысит отказоустойчивость, но не даст прироста производительности, так как запросы к логиескому диску обрабатываюстя одним контроллером. При этом контроллера-владельца логического диска можно сменить вручную. Кстати можно попробовать сделать на массиве два логических диска, которые следует объединить в stripe средствами ОС, тогда при работе будут задействованы 2 контроллера, что в ряде случаев дает значительный прирост производительности, но опять же это надо тестировать на конкретной задаче.
Последний раз редактировалось CyberDrake 20 мар 2006, 11:28, всего редактировалось 1 раз.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Разве не это мы с вами пытались сделать до сих пор? Можете ли вы мне позвонить или вылезти в аську для решения наших вопросов? Думаю нам с вами достаточно созвониться, .Sergey Petrov писал(а):Видите ли, Геннадий, помощь Петра была бы нам необходима, если бы я самостоятельно не смог смонтировать стойку, проинсталлировать софт и сделать систему рабочей. Вопрос в том, чтобы сделать систему ещё более производительной.
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
И еще Сергей, у нас с Сергеем Селезневым был реальный пример на задаче один в один похожей с вашей задачей. Почему я вам рекомендовал сделать один логический диск, ровно потому, что на нашем примере разбивка массива на три группы под данные, логи и индексы приводила к понижению производительности в 3 раза. В данном же случае хоть очередь к дискам и большая, но все-таки меньше, чем в случае 320-го контроллера. Разве нет?
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
В принципе, единственное, что хотел выяснить - правильность выбора опций при инсталляции и инициализации стойки.
А именно, опцию "Enable write caching without batteries" я отключил, поскольку батарейка есть, опция " Enable write caching with mirroring" включена.
Далее, при инициализации логических драйвов в винде я указал тип драйва "dynamic" (он вроде позволяет динамически увеличивать размер тома) и в свойствах тома установил "Policies\Enable advanced performance", что позволяет системе понадеяться на батарйку и писать данные на диск побыстрее. Хотя, в принципе, наверное эта опция имеет на нас мало влияния, поскольку у нас превалирует чтение, а не запись.
Сейчас всё в принципе работает, но хотелось бы знать, может я что-то не так или не до конца сделал? Обращаюсь к Вашему опыту.
Ещё один немаловажный момент - нам предстоит очередное тестирование. На этот раз с сервером от IBM. Если дисковый массив с уже имеющимися на нём данными просто перевести на новый сервер - возможно ли это сделать так, чтобы заново не перезаливать все данные и как это чисто технически будет осуществлено? Сколько времени займёт? Мы просто цепляем тома к операционке и аттачим базу?
Теперь об одном логическом драйве - в принципе, всё возможно и мы можем попробовать в новой конфигурации с новым сервером не разбивать имеющееся пространство на несколько логических драйвов, а создать один большой и уже на нём размещать все данные. Что в таком случае делать с файловыми группами в SQL Server? Перевести все файлы данных в одну или оставить как есть (сейчас наши основные данные разбиты на 2 файловые группы для разнесения по разным логическим томам)? Теоретически разницы для базы никакой, а вот практически...
Думаю, последний вопрос надо обсудить и с нашим программистом.
Насчёт снижения дисковых очередей - результат налицо. Насколько приемлем тот уровень, который присутствует сейчас? Какое пороговое значение для этого параметра с нашей стойкой? По общей производительности приложения - мало что изменилось (как ни странно). Может, затык ещё в чём-то? Как его можно выявить?
А именно, опцию "Enable write caching without batteries" я отключил, поскольку батарейка есть, опция " Enable write caching with mirroring" включена.
Далее, при инициализации логических драйвов в винде я указал тип драйва "dynamic" (он вроде позволяет динамически увеличивать размер тома) и в свойствах тома установил "Policies\Enable advanced performance", что позволяет системе понадеяться на батарйку и писать данные на диск побыстрее. Хотя, в принципе, наверное эта опция имеет на нас мало влияния, поскольку у нас превалирует чтение, а не запись.
Сейчас всё в принципе работает, но хотелось бы знать, может я что-то не так или не до конца сделал? Обращаюсь к Вашему опыту.
Ещё один немаловажный момент - нам предстоит очередное тестирование. На этот раз с сервером от IBM. Если дисковый массив с уже имеющимися на нём данными просто перевести на новый сервер - возможно ли это сделать так, чтобы заново не перезаливать все данные и как это чисто технически будет осуществлено? Сколько времени займёт? Мы просто цепляем тома к операционке и аттачим базу?
Теперь об одном логическом драйве - в принципе, всё возможно и мы можем попробовать в новой конфигурации с новым сервером не разбивать имеющееся пространство на несколько логических драйвов, а создать один большой и уже на нём размещать все данные. Что в таком случае делать с файловыми группами в SQL Server? Перевести все файлы данных в одну или оставить как есть (сейчас наши основные данные разбиты на 2 файловые группы для разнесения по разным логическим томам)? Теоретически разницы для базы никакой, а вот практически...
Думаю, последний вопрос надо обсудить и с нашим программистом.
Насчёт снижения дисковых очередей - результат налицо. Насколько приемлем тот уровень, который присутствует сейчас? Какое пороговое значение для этого параметра с нашей стойкой? По общей производительности приложения - мало что изменилось (как ни странно). Может, затык ещё в чём-то? Как его можно выявить?
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Как только что сказал Селезнев, все правильно сделали, .Sergey Petrov писал(а):В принципе, единственное, что хотел выяснить - правильность выбора опций при инсталляции и инициализации стойки.
Это можно спокойно сделать не перезаливая базы. Технически выглядит, как если бы вы вытащили диск и подключили к другому серверу. Эту процедуру вам поможет сделать Сергей Селезнев.Ещё один немаловажный момент - нам предстоит очередное тестирование. На этот раз с сервером от IBM. Если дисковый массив с уже имеющимися на нём данными просто перевести на новый сервер - возможно ли это сделать так, чтобы заново не перезаливать все данные и как это чисто технически будет осуществлено?
Именно так, правда в настройках стойки видимо надо будет подправить циферки, какие - знает Серега,Сколько времени займёт? Мы просто цепляем тома к операционке и аттачим базу?
Здесь сложно сказать. По заверениям Майкрософт надо делать отдельные группы, под данные, логи, индексы. Но вот когда мы делали по рекомендациям, все было плохо. Надо пробовать и тестно сотрудничать с программистами.Теперь об одном логическом драйве - в принципе, всё возможно и мы можем попробовать в новой конфигурации с новым сервером не разбивать имеющееся пространство на несколько логических драйвов, а создать один большой и уже на нём размещать все данные. Что в таком случае делать с файловыми группами в SQL Server? Перевести все файлы данных в одну или оставить как есть
Давайте дождемся сервера и решим вместе. Я приеду с Серегой к вам, там обсудим, как лучше сделать. Затык может быть как в процессорах, сетевых очередях. К слову, посмотрите что там с сетью, какой показатель network utilization.производительности приложения - мало что изменилось (как ни странно). Может, затык ещё в чём-то? Как его можно выявить?
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
- Stranger03
- Сотрудник Тринити
- Сообщения: 12979
- Зарегистрирован: 14 ноя 2003, 16:25
- Откуда: СПб, Екатеринбург
- Контактная информация:
Не, поставьте на сервере "Нетворк Монитор", запустите его на сетевом интерфейсе, интересны параметры Network Utilization и ошибки в канале. Если первый параметр в пиках больше 30-ти, это плохо. Если не превышает 10-ти, 15-ти, то нормально.Sergey Petrov писал(а):Параметр Network Inteface\Bytes Total/sec порядка 1 500 000 при гигабитной карте и сети.
-
- Advanced member
- Сообщения: 63
- Зарегистрирован: 04 окт 2005, 18:02
Кто сейчас на конференции
Сейчас этот форум просматривают: нет зарегистрированных пользователей и 10 гостей