Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Использовал Memory Optimized таблицу вместо #временной  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
Есть у меня большая процедура с кучей временных таблиц.
Решил для эксперимента заменить три самые нагруженные, там есть вставки и удаления.
Всё сделал, как рекомендовано, все сработало, но скорость работы процедуры стала раз в 5-10 хуже на тех же данных.

Что может быть причиной?
22 июн 16, 12:05    [19322310]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
aleks2
Guest
Отсутствие понимания.
22 июн 16, 12:13    [19322340]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
aleks2
Отсутствие понимания.


Вот это ответ!
Хорошо сказал, спасибо
22 июн 16, 12:21    [19322380]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
все -- это как?
сколько бакетов сделано, сколько строк вставляется,
сколько уникальных значений, по которым хэш-индекс?
22 июн 16, 12:22    [19322384]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
msLex
Member

Откуда:
Сообщений: 9273
o-o
все -- это как?
сколько бакетов сделано, сколько строк вставляется,
сколько уникальных значений, по которым хэш-индекс?

Я бы еще добавил вопрос про тип inmemory таблиц, елси временные таблицы нужны только по ходу выполнения процедуры, то нужно содавать schema only таблицы.
22 июн 16, 12:52    [19322515]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
msLex
o-o
все -- это как?
сколько бакетов сделано, сколько строк вставляется,
сколько уникальных значений, по которым хэш-индекс?

Я бы еще добавил вопрос про тип inmemory таблиц, елси временные таблицы нужны только по ходу выполнения процедуры, то нужно содавать schema only таблицы.


Посмотрите
https://www.sql.ru/forum/1113054/vpechatlenie-ot-memory-optimized-tehnologii-na-sql-2014?hl=memory optimized

Если будут вопросы пишите. Перевод чего-то на инмемеору просто сам по себе ничего не ускорит, если вы не понимаете чего хотите и как это работает.
22 июн 16, 13:16    [19322653]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
msLex
Member

Откуда:
Сообщений: 9273
a_voronin
msLex
пропущено...

Я бы еще добавил вопрос про тип inmemory таблиц, елси временные таблицы нужны только по ходу выполнения процедуры, то нужно содавать schema only таблицы.


Посмотрите
https://www.sql.ru/forum/1113054/vpechatlenie-ot-memory-optimized-tehnologii-na-sql-2014?hl=memory optimized

Если будут вопросы пишите. Перевод чего-то на инмемеору просто сам по себе ничего не ускорит, если вы не понимаете чего хотите и как это работает.

Почему вы пишете мне? Это у ТС-а ворросы, у меня их нет.

А нет, один всеже есть, что лучше inmemory таблици или join в ssis?
22 июн 16, 13:24    [19322716]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
msLex
А нет, один всеже есть, что лучше inmemory таблици или join в ssis?

не, в SSIS не JOIN, там MERGE
и самописная MERGE-репликация

у меня другой вопрос, чем закончилась история с неработающими xtp-чекпойнтами?
можно было и написать в соответствующей теме, решили ли накатом CU и какого, если да
22 июн 16, 13:32    [19322747]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
o-o
msLex
А нет, один всеже есть, что лучше inmemory таблици или join в ssis?

не, в SSIS не JOIN, там MERGE
и самописная MERGE-репликация

у меня другой вопрос, чем закончилась история с неработающими xtp-чекпойнтами?
можно было и написать в соответствующей теме, решили ли накатом CU и какого, если да


Так я ж написал, после CU5 все в норме. Чекпоинт работает. 6-й не пробовали. Так обрадовались, что база поднялась, что забили.
22 июн 16, 15:38    [19323358]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
o-o,

Можно использовать InMemory если понимать когда она рулит.
22 июн 16, 15:39    [19323363]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
а я где-то пишу, что не нельзя использовать?
я вообще-то спрашиваю, сколько бакетов создал ТС и сколько у него различных значений для индекса.
в ожидании ответа пойду почитаю окончание истории (happy end?) с чекпойнтами.
видать, не было меня в тот день
22 июн 16, 16:02    [19323470]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
o-o,

https://www.sql.ru/forum/1216423/prevratnosti-administrirovaniya-sql-server
22 июн 16, 21:12    [19324667]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
msLex
a_voronin
пропущено...


Посмотрите
https://www.sql.ru/forum/1113054/vpechatlenie-ot-memory-optimized-tehnologii-na-sql-2014?hl=memory optimized

Если будут вопросы пишите. Перевод чего-то на инмемеору просто сам по себе ничего не ускорит, если вы не понимаете чего хотите и как это работает.

Почему вы пишете мне? Это у ТС-а ворросы, у меня их нет.

А нет, один всеже есть, что лучше inmemory таблици или join в ssis?


перестаньте притворяться
22 июн 16, 21:23    [19324690]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
a_voronin
msLex
пропущено...

Я бы еще добавил вопрос про тип inmemory таблиц, елси временные таблицы нужны только по ходу выполнения процедуры, то нужно содавать schema only таблицы.


Посмотрите
https://www.sql.ru/forum/1113054/vpechatlenie-ot-memory-optimized-tehnologii-na-sql-2014?hl=memory optimized

Если будут вопросы пишите. Перевод чего-то на инмемеору просто сам по себе ничего не ускорит, если вы не понимаете чего хотите и как это работает.


1. мы с вами понимаем, чего хотим, от этого отталкиваемся
2. Microsoft рекомендует перейти от использования ## и # таблиц к использованию memory optimized, я так и сделал, как они рекомендовали
3. даже если не вникать в тонкости, то (как рекомендует МС) должно быть лучше
22 июн 16, 21:27    [19324703]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
Стыдно признаться, что для определения числа бакетов рулетку крутанул и взял первое выпавшее число?
Ага, наплюем на тонкости, а что сервер потом как дурак ищет, куда вставить очередную строку, потому что ему рулеточное число подсунули, а подсунувший ждет до опупения, это в порядке вещей.

Тогда зачем жаловаться на производительность?
22 июн 16, 23:57    [19325209]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
автор
The other impact of undersizing hash buckets relates to performing an insert.
To insert a row in a hash index where there are collisions on the hash buckets,
the system has to first find the proper insertion point.
If the values are all duplicates, this isn’t a big impact because you simply insert in the
head of the chain.
If, however, there are lots of hash collisions but NOT many duplicate values,
you need to walk the chain of duplicates to find the proper place for this new value.
The list is sorted by key value, so all entries for duplicate keys are grouped together within the list.
New duplicates are inserted at the beginning of the group with the same key value.
23 июн 16, 12:02    [19325583]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
Ролг Хупин
Member

Откуда: Чебаркуль
Сообщений: 4176
o-o
Стыдно признаться, что для определения числа бакетов рулетку крутанул и взял первое выпавшее число?
Ага, наплюем на тонкости, а что сервер потом как дурак ищет, куда вставить очередную строку, потому что ему рулеточное число подсунули, а подсунувший ждет до опупения, это в порядке вещей.

Тогда зачем жаловаться на производительность?


я не то, чтобы жалуюсь, а попросил совета специалистов, которые выше меня на голову, да что там - на две!
;-)

Я следуя совету Майкрософтов, думал по-быстрому заменить и протестировать, но не тут-то было.

Да, с бакетами типа такого и вышло, но дело в том, что в разных вызовах процедуры временные таблицы заполняются разным количеством записей, от 0 до сотен тысяч. Как определиться?
23 июн 16, 16:56    [19327184]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
нет.
не получится просто так перенести.
бакетов должно быть примерно сколько уникальных значений,
и лучше перебор, чем недобор, значения с одинаковым хэшем создают цепочки,
чем длиннее, тем тормознее и вставка, и выборка.
индексы тоже: если хэш, то все запросы с не всеми колонками из хэш-функции идут лесом,
т.е. будет скан, нет такого, что в условии лишь ведущая колонка индекса и индекс будет использован.
которые BW-TREE тоже не такие, однонаправленные.
короче, надо разбираться, или не трогать работающее.
у Бен-Гана такой скрипт приведен:
SELECT
   object_name(hs.object_id) AS [object name],
   hs.total_bucket_count,
   hs.empty_bucket_count,
   floor((cast(empty_bucket_count as float)/total_bucket_count) * 100) AS[empty_bucket_percent],
   hs.avg_chain_length,
   hs.max_chain_length
FROM sys.dm_db_xtp_hash_index_stats AS hs
   JOIN sys.indexes AS i
   ON hs.object_id=i.object_id AND hs.index_id=i.index_id;

автор
With this query, you look at both the
empty bucket percent and the average chain length. Ideally, you’re looking for an empty bucket
percent of over 30 percent and an average chain length in the single digits.
If the bucket count is oversized, the impacts are not nearly as severe, so it is always better to err on
the side of oversizing. There are two impacts to oversizing:
First, the hash buckets are each an 8-byte pointer, which consumes memory, so a
dramatically oversized hash-bucket count will result in wasting memory. Because there is
only one hash table per index, this is usually not a significant factor.
The second impact comes into play when the query results in a table scan. Table scans
are implemented by visiting each bucket in the index being scanned. The optimizer will
choose the hash index with the lowest bucket count to scan, because that will minimize the
number of buckets to be visited. If 90 percent of the buckets are empty because of an
oversized hash table, the query will still need to visit every bucket, which slows down thequery substantially. If you follow my recommendation that there be at least one
nonclustered index on a table, this will not be a problem because the optimizer will choose
the BW-Tree nonclustered index for the scan.
23 июн 16, 17:25    [19327311]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
a_voronin
Member

Откуда: Москва
Сообщений: 4893
Ролг Хупин
o-o
Стыдно признаться, что для определения числа бакетов рулетку крутанул и взял первое выпавшее число?
Ага, наплюем на тонкости, а что сервер потом как дурак ищет, куда вставить очередную строку, потому что ему рулеточное число подсунули, а подсунувший ждет до опупения, это в порядке вещей.

Тогда зачем жаловаться на производительность?


Я следуя совету Майкрософтов,


Там есть адвайзер по переводу на ИнМемору -- вы его пользовали?

Я сижу на ИнМемору уже полтора (если не два) года. У меня есть несколько таблиц свыше 10 лямов. Но я никогда вот так тупо не переводил, это всегда было связано с оптимизацией конкретных запросов. Более того я не просто план смотрел, а запускал запросы старого и нового (ИнМемору) образца в параллель по 5 10 20 потоков и смотрел, как система ведет себя в целом. Потому что ИнМемору проявляет свои лучшие стороны при большой параллельности, но не на одиночных запросах.

Вам надо внимательно тестировать. Переход на новую технологию это не просто так взял и поставил. Без проработки всей системы эффекта будет мало.
27 июн 16, 11:46    [19339241]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
Alex_496
Member [заблокирован]

Откуда: https://www.dvbi.ru
Сообщений: 3869
вот именно, при нескольких потоках - быстрее. Но что-то не очень историй напочитать про практику применения inmemory.
28 мар 17, 20:21    [20343471]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Если вам интересно найдите книгу Дмитрия Короткевича по In Memory, он там все описывает очень подробно, и про кол-во бакетов (лучше много чем мало, большое кол-во влияет только на scan и кол-во памяти которое индекс займет (8 байт на бакет), и SQL округляет число бакетов до сл. степени двойки, а малое число влияет на все). Там же ближе к концу книги есть пример использования In Memory вместо временных таблиц, чаще всего это быстрее, но не всегда, почитайте, 250 стр. и все вопросы по in memory у вас отпадут сами собой.
29 мар 17, 04:44    [20344295]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
aleksrov
Member

Откуда:
Сообщений: 948
Также учтите что если у вас хеш индекс по vol1 и vol2 то в where не может быть только vol1, хеш строится по 2 значениям и искать мы должны по ним. Также, в таких таблицах, SQL всегда считает что там одна строка, это тоже надо учитывать.
29 мар 17, 05:31    [20344307]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
aleksrov
Также, в таких таблицах, SQL всегда считает что там одна строка, это тоже надо учитывать.

с чего бы это.
в плане числится оценка, равная bucket count,
и это логично: кто бы стал млн бакетов создавать под 1 строку?
уж скорее, млн под млн
29 мар 17, 09:49    [20344744]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
aleksrov
Member

Откуда:
Сообщений: 948
o-o,

Тут
Может я неправильно понял автора.
29 мар 17, 10:00    [20344803]     Ответить | Цитировать Сообщить модератору
 Re: Использовал Memory Optimized таблицу вместо #временной  [new]
o-o
Guest
aleksrov
o-o,

Тут
Может я неправильно понял автора.

это же про табличные переменные (memoty oprimized variables)
а тема про memory optimized tables
29 мар 17, 10:05    [20344829]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить