Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft SQL Server Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
как будто мне жалко:
name minimum maximum config_value run_value
max server memory (MB) 16 2147483647 36864 36864

только на сервере больше никого не было,
а блоба там 7 гиг.
да и если бы 1Гб памяти был, прочел бы и записал,
у нас и 400гиг читают в одном запросе, никто не умер
18 янв 17, 17:31    [20119575]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
alexeyvg
Member

Откуда: Moscow
Сообщений: 31960
o-o
да и если бы 1Гб памяти был, прочел бы и записал,
В общем да - это же не индекс, сортировать ничего не надо, прочитал и записал.
o-o
Что чтения рандомные, то мне понятно, и это минус на скорости.

Да и для рандомных чтений непонятно - очереди к диску же нулевые. А должно быть много.

Тут просто кривой код какой то, недоделанный.

Типа, по одному блочку читает и пишет. Команды передаются как то между процесссами, и на каждый блок требуется один тик ОС. Может, что то такое?
Да ещё и эта кривизна, с чтениями одной страницы по 100 раз.

Это как драматическое снижение скорости записи BULK INSERT при включении сжатия.
Сервер простаивает, процессоры не нагружены, очередь дисков 0, а запись 3 мб/сек. А без сжатия - 1000 мб/сек.
В МС знают, но забили.
18 янв 17, 18:00    [20119698]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
o-o,

Решил проверить что у меня происходит в БЛОБами

Имеем
Рабочая станция - ноутбук с HDD диском - никаких SSD, имеется тестовая база, в ней таблица с блобами

1. Проверяем что с данными
select
    au.*
    , au.total_pages * 8 / 1024 as Mb
from sys.allocation_units au
    inner join sys.partitions p on
        au.container_id = p.hobt_id
where p.object_id = object_id('dbo.DocumentFiles')
and p.index_id = 1

результат

allocation_unit_id type type_desc container_id data_space_id total_pages used_pages data_pages Mb
-------------------- ---- ------------------------------------------------------------ -------------------- ------------- -------------------- -------------------- -------------------- --------------------
72057596801908736 1 IN_ROW_DATA 72057596741484544 1 5321 5309 5298 41
72057596517220352 2 LOB_DATA 72057596741484544 2 1034084 1033982 0 8078
72057596801974272 3 ROW_OVERFLOW_DATA 72057596741484544 1 0 0 0 0
2. Проверочный скрипт перезаливки данных
set statistics io, time on

insert dbo._DocumentFiles with (tablock)
select /*top 1000*/ *
    from dbo.DocumentFiles

set statistics io, time off
go

Статистика выполнения

Table 'DocumentFiles'. Scan count 1, logical reads 5309, physical reads 4902, read-ahead reads 3815, lob logical reads 2283881, lob physical reads 605393, lob read-ahead reads 900267.

SQL Server Execution Times:
CPU time = 42182 ms, elapsed time = 495908 ms.

(134443 row(s) affected)

Картинка с другого сайта.
3. Проверяем что с данными в итоговой таблице
select
    au.*
    , au.total_pages * 8 / 1024 as Mb
from sys.allocation_units au
    inner join sys.partitions p on
        au.container_id = p.hobt_id
where p.object_id = object_id('dbo._DocumentFiles')
and p.index_id = 0


allocation_unit_id type type_desc container_id data_space_id total_pages used_pages data_pages Mb
-------------------- ---- ------------------------------------------------------------ -------------------- ------------- -------------------- -------------------- -------------------- --------------------
72057596803743744 1 IN_ROW_DATA 72057596742795264 2 5180 5175 5171 40
72057596803809280 2 LOB_DATA 72057596742795264 2 1023934 1023933 0 7999
72057596803612672 3 ROW_OVERFLOW_DATA 72057596742795264 2 0 0 0 0

(3 row(s) affected)


Вывод - проблема не воспроизводится.

Вопросы к автору следующие, уж извините за примитивность.
1. источником данных является вьюха или таблица
2. если таблица - куча или с кластером
3. попробуйте переливку данных их вашей "Desctination" таблицы в следующую - третью тестовую какую нить.
4. Проверьте фрагментацию блобов в источнике
5. Недавно на МСДН-БОЛ читал что компактность блобов в 2008 идет только при оффлайн ребилде, попробую чуть позже найти пруффлинк.
19 янв 17, 12:11    [20122133]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
Что то не умею картинки вставлять - там должна быть статистика из кэша


total_physical_reads total_logical_reads total_logical_writes
1,052,057.00 8,389,727.00 1,036,373.00
19 янв 17, 12:14    [20122148]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
-Гвоздь-,

думаю, надо с версии сервера начинать.
у нас 2008 R2 SP1,
что уже отлично.
Microsoft SQL Server 2008 R2 (SP1) - 10.50.2500.0 (X64)   Jun 17 2011 00:54:03   Copyright (c) Microsoft Corporation  Enterprise Edition (64-bit) on Windows NT 6.0 <X64> (Build 6002: Service Pack 2) (Hypervisor) 

например, вот такая баговина была:
Performance bug: NOLOCK scans involving off-row LOB data

ответы на вопросы:
источник -- компресснутая куча.
компрессили те, кто не знают, что нтексты не компрессятся,
но тут уже я ничего не поделаю. база-источник -- ридонли.
ее ресторят с другого сервера и делают ридонли.
приемник неважен, задача перелить.
во вчерашнем эксперименте приемник- пустая куча.
лить в кластерный невыгодно как раз потому,
что исходник -- куча.
там есть ПК, но это identity, по которому сделан некластерный уникальный индекс,
ну т.е. ordered бесплатным не будет, поэтому уж проще в кучу слить.
потом кластерный ПК создается моментально

у ТС версия сервия еще хуже, так что непоследний фактор в этом блобном деле
19 янв 17, 12:53    [20122359]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
o-o,

ИМХО - источник проблемы это "таблица источник".

...
3. попробуйте переливку данных их вашей "Desctination" таблицы в следующую - третью тестовую какую нить.
...
я думаю вы не получите эту проблему если проверите, поэтому проблема не в медленной вставке а в медленной выборке,
посмотрите состояние таблицы источника - хотя у вас уж больно специфичный источник - вы всё равно не сможете на него повлиять.
19 янв 17, 13:03    [20122394]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
сейчас пробую перелить из не-ридонли базы.
кучу в кучу же, select into
посмотрим, чем закончится
19 янв 17, 13:04    [20122399]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
o-o,

Перепутал вас с ТС - извините
19 янв 17, 13:05    [20122404]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
-Гвоздь-
я думаю вы не получите эту проблему если проверите, поэтому проблема не в медленной вставке а в медленной выборке,
посмотрите состояние таблицы источника - хотя у вас уж больно специфичный источник - вы всё равно не сможете на него повлиять.

я и не говорю нигде о медленной вставке.
я нигде не цитирую число writes.
у меня ожидания на *чтении* и число *чтений* нереально большое.
сейчас источник идеальный, самая обычная некомпресснутая куча в обычной базе.
то самое, перелитое вчера, лью заново.
кстати, отработало за 9:37.
осталось понять, это его с компрессии клинит или с read only.
хотя все равно время дурацкое для такого объема.
сейчас статистику вывешу
19 янв 17, 13:13    [20122439]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
(No column name) type_desc total_pages Mb
proposte_di_delibera IN_ROW_DATA 160068 1250
proposte_di_delibera LOB_DATA 868909 6788
proposte_di_delibera_rw IN_ROW_DATA 160066 1250
proposte_di_delibera_rw LOB_DATA 868914 6788

creation_time execution_count elapsed_time_ss total_logical_reads total_physical_reads total_rows query
2017-01-19 11:00:14.437 1 577 26915244 1029443 2082132 select * into dbo.proposte_di_delibera_rw from dbo.proposte_di_delibera;
19 янв 17, 13:18    [20122471]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
o-o,

Посмотрите плиз еще на total_logical_writes

Вот на моем тесте physical_reads - близок к logical_writes - а logical_reads- больше в 8 раз
total_physical_reads	total_logical_reads	total_logical_writes
1,052,057.00 8,389,727.00 1,036,373.00
19 янв 17, 13:23    [20122498]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
кривое, говорю, чтение.
202Гига он начитал в таблице, где гиг inrow и 7 гиг ntext-а.
сейчас закомпрессю в read write базе и снова перелью.
хотя бы пойму, откуда 90 минут против 9
19 янв 17, 13:23    [20122499]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
-Гвоздь-
o-o,

Посмотрите плиз еще на total_logical_writes

Вот на моем тесте physical_reads - близок к logical_writes - а logical_reads- больше в 8 раз
total_physical_reads	total_logical_reads	total_logical_writes
1,052,057.00 8,389,727.00 1,036,373.00

говорю же, все хорошо у меня с записью,
зачем мне writes, когда у меня беда с reads?
вот моя статистика, и что?
total_logical_reads total_physical_reads total_rows total_logical_writes
26915244 1029443 2082132 1029382

пойду лучше компресснутое лить.
закомпрессило оно аж за 11 секунд,
кто бы сомневался, нтекст никто и не думал компрессить.

и поди не зря был баг при скане с nolock.
поди когда куча, он все то же самое делает:
для каждой строки лезет почитать IAM:
Randal
the old behavior was to scan all the IAM pages for the table/index to make sure that the off-row link actually pointed to a page allocated to the table/index. If there are lots of IAM pages, this means lots of logical IOs, and poorly performing SELECT queries. And it does the scan once for *every row*. The person that hit it today had a 500 row select of ~20KB per row taking 20 seconds – 10MB of physical IOs and 30MB of logical IOs!
19 янв 17, 13:36    [20122588]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
с компрессией просто быстрее вышло,
меньше физических чтений, логические почти те же.
зато теперь, исключив влияние компрессии, я подозреваю рид онли.
кажется, я попадаю на тот самый баг, что и при чтении с nolock.
и хотя никакого nolock у меня нет, зато есть рид онли база.
и он не ставит S на таблицу и попадает в тот же случай, что и с nolock
сейчас с tablock копирую из рид онли базы, пускай обломается
19 янв 17, 13:53    [20122667]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
зараза какая.
ну выставил он S таблице,
но час копировал все равно.
ридонли база его убивает.
вот картинка с результатом.
остается только скопировать это все в левую базу,
перелить из нее, как есть,
а потом перелить, выставив базе ридонли.
может быть, завтра сделаю

К сообщению приложен файл. Размер - 58Kb
19 янв 17, 15:27    [20123293]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
TaPaK
Member

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

может не в read_only дело, я не получаю разницы. Может пула не хватает, отсюда столько чтений, хотя звучит не логично :)
19 янв 17, 15:29    [20123313]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
да пусто на сервере.
я уже переливаю в соседнюю базу,
потом ее сделаю ридонли и пусть весь обед переливает обратно.

вы на какой версии тестируете?
по ссылке (Рэндал) написано, что и в 2008 снова это было.
наверное, это и огребаем
19 янв 17, 15:49    [20123421]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
и такой еще вопрос:
почему же для перелива 8Гиг инроу пула хватает,
а для такого же по объему перелива нтекста уже не хватает?
объем он ведь тот же.

меняется *струкрура* читаемого.
и почему-то оффроу ему надо по 100 раз читать.
видимо, "увлекательное чтение" (с)
короче, за 10 минут из обычной базы в обычную же перелилось.
компресснутая куча, чтобы воспроизвести все условия.
а сейчас база сделана ридонли и из нее обратно в первую переливаю, процесс пошел.
19 янв 17, 16:01    [20123483]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
-Гвоздь-
Guest
TaPaK
o-o,

может не в read_only дело, я не получаю разницы. Может пула не хватает, отсюда столько чтений, хотя звучит не логично :)


у меня тоже не получается такой разницы
я тестовую базу сделал ReadOnly - перезаливал в другую базу - без разницы и с NOLOCK и c TABLELOCKX

могу предложить только безумный case:
- изменить источник READONLY на RW
- сделать оффлайн ребилд кучи создание кластерного PK с последующим его удалением
- сделать снова READONLY
19 янв 17, 16:07    [20123515]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
это какая-то кривая база.
потому что даже из другой базы, сделанной ридонли,
перелилось за 6 минут.
а из той каждый месяц надо арховировать, и всегда дольше часа

хотя чтения все равно те же несусветные.

итого: если база ридонли, логических чтений в 2 раза больше,
чем когда база не ридонли,
но главный тормоз в чем-то еще.

P.S. мне нравится соотношение чтений/записи

К сообщению приложен файл. Размер - 48Kb
19 янв 17, 16:57    [20123717]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
TaPaK
Member

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

автор
итого: если база ридонли, логических чтений в 2 раза больше,
чем когда база не ридонли,
но главный тормоз в чем-то еще.

так вроде как и писали, скорее всего фрагментация
19 янв 17, 17:06    [20123762]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
вот что у баз-источников различно:
name snapshot_isolation_state_desc recovery_model_desc is_fulltext_enabled is_parameterization_forced
CORESQL7FM ON FULL 1 1
S1229i OFF SIMPLE 0 0

остальные параметры совпадают
(проблемная - CORESQL7FM, которая в полной модели,
но ей все равно, она же ридонли)

ту базу трогать не могу, даже просто в read_write перевести
19 янв 17, 17:11    [20123782]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
o-o
Guest
TaPaK
o-o,

автор
итого: если база ридонли, логических чтений в 2 раза больше,
чем когда база не ридонли,
но главный тормоз в чем-то еще.

так вроде как и писали, скорее всего фрагментация

какая нафиг фрагментация 8-о???
это КУЧА!!!
если вы про плотность страниц,
то боже мой, неужели она меняется,
как только базу делаешь ридонли???
это типа моментальный перевод в ридонли
на самом деле без спросу разреживает кучи,
заполняя только половину страниц?
(и это моментально для всех куч в базе???)
да еще и объем при этом не меняется???
дурдом, товарищи
19 янв 17, 17:17    [20123818]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
TaPaK
Member

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

а что там с планами? одинаковые?
19 янв 17, 17:25    [20123877]     Ответить | Цитировать Сообщить модератору
 Re: как улучшить скорость записи/чтения блобов?  [new]
TaPaK
Member

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

я не знаю как у вас с запросом и влияет ли, но разница readonly ещё и в расположении статистик в tempdb и сброса её если останавливаете
19 янв 17, 17:29    [20123908]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 [3] 4   вперед  Ctrl      все
Все форумы / Microsoft SQL Server Ответить