none
Увеличение производительности RRS feed

  • Вопрос

  • Надеюсь не пересекусь с другими темами.

    Стоит вопрос увеличения прозиводительности SQLServer'а засчет увеличения производительности аппаратной платформы.

    Критичным является операция построения индексов.

    Насколько мне известно, при построении индексов в основном задействуются память и процессор.
    Так вот.
    1) Какие процессоры на сегодняшний момент обеспечивают наиболее быструю работу в этом отношении SQL Server'а. Понятно, что речь идет о x64.
    2) Если есть, то дайте ссылки на тестирование SQL Server на различных платформах (о супер системах стоимостью несколько млн. долларов не упоминать).
    3)  Возможно ли с помощью кластера увеличить производительность, если да, то дайте ссылки.
    4) Какие еще способы увеличения производительности можно рассмотреть. (логику не рассматривать)

    Есть 2-х ядерный 2-х процессорный AMD Opteron.

    Есть 2-х процессорный Itanium2 1,5 ГГц.

    Сравнить их не имеется возможности, т.к. оба задействованы. Но не думаю, что результаты будут существенно различны. Сейчас идексы на Opteron'е строятся около 3-х часов.




    30 июля 2007 г. 15:05

Ответы

  •  

    2) Есть сайзеры от HP, лучше пока ничего нет, нужна регистрация:

    http://h71019.www7.hp.com/activeanswers/Secure/412638-0-0-0-121.html

    http://h71019.www7.hp.com/activeanswers/Secure/127077-0-0-0-121.html

     

    3) Нет.

     

    4) http://msdn2.microsoft.com/en-us/library/aa479364.aspx

     

    30 июля 2007 г. 15:40
    Модератор
  • "Насколько мне известно, при построении индексов в основном задействуются память и процессор" -- дисковую подсистему зря из списка вычеркнули.

    3) SQL Server на кластере не поддерживает распределение нагрузки. Только для отказоустойчивости

     

    4) "логику не рассматривать" -- IMHO, зря.

    "Сейчас идексы на Opteron'е строятся около 3-х часов" - вы их каждую ночь перестраиваете? REBUILD/REORGANIZE/DBCC REINDEX? ONLINE?

    31 июля 2007 г. 7:11
  •  russish написано:
    Надеюсь не пересекусь с другими темами.

    Стоит вопрос увеличения прозиводительности SQLServer'а засчет увеличения производительности аппаратной платформы.

    Критичным является операция построения индексов.

    Насколько мне известно, при построении индексов в основном задействуются память и процессор.
    Так вот.
    1) Какие процессоры на сегодняшний момент обеспечивают наиболее быструю работу в этом отношении SQL Server'а. Понятно, что речь идет о x64.
    2) Если есть, то дайте ссылки на тестирование SQL Server на различных платформах (о супер системах стоимостью несколько млн. долларов не упоминать).
    3)  Возможно ли с помощью кластера увеличить производительность, если да, то дайте ссылки.
    4) Какие еще способы увеличения производительности можно рассмотреть. (логику не рассматривать)

    Есть 2-х ядерный 2-х процессорный AMD Opteron.

    Есть 2-х процессорный Itanium2 1,5 ГГц.

    Сравнить их не имеется возможности, т.к. оба задействованы. Но не думаю, что результаты будут существенно различны. Сейчас идексы на Opteron'е строятся около 3-х часов.

     

    Укажите версию СУБД и платформы?

     

    Необходимость постоения индексов обусловлена вашей спецификой (например, новые таблицы) или это делается в рамках плана обслуживания?

     

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

    Вопрос номер два поставлен некорректно... Мало того, что таким сравнением никто серьёзно нигде не занимается, но и отказ от ссылок на тесты производительности больших систем тоже непонятен... ИМХО, исходить нужно не из цены, а из размера базы данных... Кроме того, основная доля возможностей повышения производительности лежит в оптимизации схемы и запросов, а Вы, как я понял, это исключаете....

     

    Чтобы предложить Вам способы повышения производительности ваших приложений нужна более развёрнутая информация об них и о проблемах, которые у них возникают.

    31 июля 2007 г. 9:04

Все ответы

  •  

    2) Есть сайзеры от HP, лучше пока ничего нет, нужна регистрация:

    http://h71019.www7.hp.com/activeanswers/Secure/412638-0-0-0-121.html

    http://h71019.www7.hp.com/activeanswers/Secure/127077-0-0-0-121.html

     

    3) Нет.

     

    4) http://msdn2.microsoft.com/en-us/library/aa479364.aspx

     

    30 июля 2007 г. 15:40
    Модератор
  • "Насколько мне известно, при построении индексов в основном задействуются память и процессор" -- дисковую подсистему зря из списка вычеркнули.

    3) SQL Server на кластере не поддерживает распределение нагрузки. Только для отказоустойчивости

     

    4) "логику не рассматривать" -- IMHO, зря.

    "Сейчас идексы на Opteron'е строятся около 3-х часов" - вы их каждую ночь перестраиваете? REBUILD/REORGANIZE/DBCC REINDEX? ONLINE?

    31 июля 2007 г. 7:11
  •  russish написано:
    Надеюсь не пересекусь с другими темами.

    Стоит вопрос увеличения прозиводительности SQLServer'а засчет увеличения производительности аппаратной платформы.

    Критичным является операция построения индексов.

    Насколько мне известно, при построении индексов в основном задействуются память и процессор.
    Так вот.
    1) Какие процессоры на сегодняшний момент обеспечивают наиболее быструю работу в этом отношении SQL Server'а. Понятно, что речь идет о x64.
    2) Если есть, то дайте ссылки на тестирование SQL Server на различных платформах (о супер системах стоимостью несколько млн. долларов не упоминать).
    3)  Возможно ли с помощью кластера увеличить производительность, если да, то дайте ссылки.
    4) Какие еще способы увеличения производительности можно рассмотреть. (логику не рассматривать)

    Есть 2-х ядерный 2-х процессорный AMD Opteron.

    Есть 2-х процессорный Itanium2 1,5 ГГц.

    Сравнить их не имеется возможности, т.к. оба задействованы. Но не думаю, что результаты будут существенно различны. Сейчас идексы на Opteron'е строятся около 3-х часов.

     

    Укажите версию СУБД и платформы?

     

    Необходимость постоения индексов обусловлена вашей спецификой (например, новые таблицы) или это делается в рамках плана обслуживания?

     

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

    Вопрос номер два поставлен некорректно... Мало того, что таким сравнением никто серьёзно нигде не занимается, но и отказ от ссылок на тесты производительности больших систем тоже непонятен... ИМХО, исходить нужно не из цены, а из размера базы данных... Кроме того, основная доля возможностей повышения производительности лежит в оптимизации схемы и запросов, а Вы, как я понял, это исключаете....

     

    Чтобы предложить Вам способы повышения производительности ваших приложений нужна более развёрнутая информация об них и о проблемах, которые у них возникают.

    31 июля 2007 г. 9:04
  • Используется SQL Server 2005 SP1 x64

    Согласен, что в повышение производительности  лежит в оптимизации схемы и запросов, но узкое место как раз не в этом. Время выполнения запросов устраивает.

    Дело в том, что база достаточно большая (сейчас чуть больше ТБ, каждый день на 3 - 5ГБ увеличивается). Каждый день, точнее ночь, в нее заносятся данные. Днем база должна быть доступна.

    При этом используется таблица "стандартного" вида

    [ID]  int
    [Value] varchar

    Ее необходимо пополнять. Естесственно, если вносить большое количество данных, то быстрее будет снять индексы и построить их заново. Так вот строится неприемлемо долго. Сейчас там где - то чуть меньше млрд. записей.

    Ну и несколько таблиц вида 

    [ID] int
    [idValue1] int
    [idValue2] int
    [Description] varchar

    Вот так.


    3 августа 2007 г. 19:09
  • <каждый день на 3 - 5ГБ увеличивается>
    Ого Вы какими темпами растёте!Smile
    Ну так раз Вы ночью вносите небольшую порцию данных (по сравнению с размером таблицы), то зачем делать полную перестройку индекса (я полагаю, что REBUILD)?
    С самой большой таблицей работа ведётся со всеми строками, или только с последними? 2005 сервер - секционировать таблицу не пробовали?
    4 августа 2007 г. 15:21
  •  Andrey Kudievskiy написано:
    <каждый день на 3 - 5ГБ увеличивается>
    Ого Вы какими темпами растёте!
    Ну так раз Вы ночью вносите небольшую порцию данных (по сравнению с размером таблицы), то зачем делать полную перестройку индекса (я полагаю, что REBUILD)?
    С самой большой таблицей работа ведётся со всеми строками, или только с последними? 2005 сервер - секционировать таблицу не пробовали?


    Наверное вы не поняли смысл. Основная таблица естесствено секционирована.
    Структрура БД следующая (это пример)
    Таблица1 (секционирована по дате) - Money_Echange обмен валют

    id int
    money_id_from int
    money_id_to int
    cash int

    id - идентификатор записи
    money_id_from - валюта которую меняют
    money_id_to - валюта на которую меняют
    cash - сколько меняют.

    Соответсвенно есть таблица Money
    id_money int
    money_caption varchar (50)
    В которой содержаться все валюты.

    Соответсвенно таблицы связаны по id_money (FK)

    При занесении данных в Money_Echange надо вносить валюты, которых нет в таблицу Money, потом JOIN ить и заносить ID шники.

    Объем вносимых данных в таблицу MONEY очень большой и эффективнее удалять индексы перед занесением, а потом строить их заново.



    7 августа 2007 г. 15:54
  • Хм..., я Вас и сейчас, видимо, недопонимаю.
    Давайте по полочкам:
    1) исходя из Вашей структуры таблица Money - это справочник валют. Сколько у нас валют в мире, да которые ещё и участвуют в денежном обмене (отбрасываем каменные бусы африканских племён)? Ну давайте примем нереальный максимум - 10000. Так почему Вы пишете, что объём вносимых данных в таблицу очень большой?
    2) если пункт 1) верный (мои предположения), то почему бы не сформировать справочник валют, и тогда не столкнёмся со случаем, когда в Money_EXchange нужно вносить валюты, к-рых нет в таблице Money
    3) я понимаю, что это пример, но всё же: "cash INT" - или Вы храните деньги в центах/копейках?
    8 августа 2007 г. 7:20
  •  Andrey Kudievskiy написано:
    Хм..., я Вас и сейчас, видимо, недопонимаю.
    Давайте по полочкам:
    1) исходя из Вашей структуры таблица Money - это справочник валют. Сколько у нас валют в мире, да которые ещё и участвуют в денежном обмене (отбрасываем каменные бусы африканских племён)? Ну давайте примем нереальный максимум - 10000. Так почему Вы пишете, что объём вносимых данных в таблицу очень большой?
    2) если пункт 1) верный (мои предположения), то почему бы не сформировать справочник валют, и тогда не столкнёмся со случаем, когда в Money_EXchange нужно вносить валюты, к-рых нет в таблице Money
    3) я понимаю, что это пример, но всё же: "cash INT" - или Вы храните деньги в центах/копейках?


    Прикольно отвечаете.
    Если бы я привел пример не про валюты, а про названия химических соединений, входящих в состав хвоста
    кометы Хейла Боппа, вы бы тоже начали рассуждать о целесообразности. Русским языком было сказано. Это ПРИМЕР.
    Вы правильно поняли, что  таблица Money - справочник. Данных в него заносится много. Вот и ищу вариант увеличения производительности.
    8 августа 2007 г. 9:58
  • Я бы спросил мнение у остальных форумчан, прочитавших Ваш ПРИМЕР (обязательно большими буквами!Smile), что они подумали о справочнике Money и о том, сколько вообще может в нём содержаться данных.
    Ну да Бога ради, пример так пример, абстрагируемся от этого. Итак, есть табличка, в неё надо заливать данные, при этом на ней есть индексы, и измерения показали, что самый быстрый вариант - дроп этих индексов и создание их заново. Мои предложения - проанализировать, где у сервера "bottle throat" - процы, память, диски при заливке и создании индексов заново. Вообще если матчасть позволит, табличку в отдельную файловую группу, и ложим на самый быстрый RAID.
    Тормозит именно создание индексов? А может лог активно при заливке растёт? BULK INSERT, или что-то другое?
    8 августа 2007 г. 13:48
  • 40% "вариантов" повышения производительности лежит в области проектирования схемы данных.

    И то, какая это должна быть схема зависит и от "качества данных" и от их количества.

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

     

    еще 50% "вариантов" - в запросах к данным. Два очень похожих запроса, возвращающих строго одни и те же данные, могут выполняться за принципиально разное время в зависимости от "грамотности" написания.

    15 августа 2007 г. 18:58
    Отвечающий