Имеется набор таблиц вида
ID INTEGER (PK)
INFO BLOB 5120000

Вставка больших блобов (2 Мб и более) может занимать до 40 секунд (а может и на порядок меньше). Монитор показывает резкое (с 2 до 25%) возрастание загрузки процессора в это время. IO остается низким.

Пишущий клиент один, читателей (неактивных) 1-2. Чтение блобов выполняется мгновенно.

Куда можно копать?

Интересует именно оптимизация работы блобов, вроде как с обычными таблицами удалось все довести до нормы.

Пробовал ли кто заменить блобы на сеты строк (порезанных по 16 К, например)?


Немного о конфигурации:

Windows, DB2 8.10 (32 bit).

Блобы (размеры от 1 К до 500 Мб) лежат в DMS Tablespace, размазанном по 4 дискам в Raide. Удаление блобов бывает, но редко и относительно (порядка 10%) мало.

Логирование блобовских таблиц включено, логи лежат на отдельном диске.

Памяти под кэши операционки остается порядка 6 Г.

Дополнительный вопрос:

Не могу найти однозначный ответ на вопрос: запись блобов идет синхронно или асинхронно?

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

Блобы, по сути, только хранятся - после сохранения изредка поштучно (выбор по уникальному индексу) считываются, можно считать, что время считывания некритично.

То, что бутылочным горлом оказывается IO - не похоже, к сожалению: мониторим очередь к диску, время занятости диска и так далее - всё чисто: очередь - 0, занятость - 1-3%, объемы чтения - нулевые, объемы записи - примерно сопоставимы с размерами блоба (точнее сложно сказать, одновременно идет еще запись нескольких строк в обычные таблицы, но вроде как разница укладывается в разумное число страниц).

Со структурой RAID поиграться не удасться: продакшн. Но такой же по железу
и структуре RAID пишет обычных Tablespace до гига в час и не жужжит.

Растет именно загрузка процессора с 1-2 до 25%. С учетом того, что есть два двухядерных проца, ощущение, что какой-то тред (определеяющий - куда писать?) непонятно что считает, и его-то мы и ждем. Ну не верю я, что запись 2 Мегов (хорошо, 4 Мегов с учетом логов) может идти 70 секунд, это же не дискета в конце концов.

Nikolay KulikovУ меня есть предположение, что можут виноват кэш контроллера RAID. Он постоянно сканируется на манер вычисления похожих страниц. Можно ли у вас его отключить и поигратться???

Поиграться на продакшн можно ограниченно. Мы пробовали изменить соотношение использования памяти кэша с 50/50 чтение - запись на 20/80. Ситуация несколько улучшилась, но не принципиально.

Полностью отключить нельзя - в той же базе лежит несколько маленьких, но активно читаемых таблиц, и хоть HIT RATIO удается держать где-то 99%, лечь по IO на них очень не хотелось бы.

Victor Metelitsa1. Не могу ничего особенного сказать про LOB'ы. Однако, логично ожидать, что операция синхронная. Я так думаю в виду рекомендации IBM-еров держать LOB'ы в SMS, потому что они не кешируются в буферном пуле. Раз они проскакивают мимо буферного пула, а про асинхронный I/O говорят лишь в контексте буферного пула (параметры конфигурации типа iocleaners), то...



Вот и я так думаю:((

Я сейчас уже сколоняюсь к мысли отказаться от блобов: резать инфу на куски и класть в N varchar-ов в нормальные таблички. Интуитивно - выигрыш должен быть, не будет сохранение 100 строк идти так долго. Делал ли кто-нибудь такой финт ушами?

Victor Metelitsa[quot Lana Zapornikova]
Бутылочное горлышко есть. Его не может не быть. И это не процессор, потому что загрузка < 100%.

Или "загрузка процессора = 25%" надо понимать как "загрузка каждого из четырёх ядер=25%"??? В этом случае, да, если работает одна нить, то бутылочным горлышком становятся процессоры.

Интуитивно ясно, что то, что вы наблюдаете, ненормально и не должно быть. Но с LOB'ами и многоядерниками у меня нет опыта ;-(.

Может не быть, если каким-то образом ждем на локах/семафорах/еще чем-нибудь. Могу рассказать историю из театра абсурда об улучшении производительности вдвое путем использования команды SLEEP.

Процессорная загрузка растет на всех 4 "процах", при этом на каждом скачет от 5 до 50%, а но сумма в течении всего периода именно 25% (точнее, 23-24%), словно одна нить перескакивает с одного на другой. В нормальные периоды суммарная загрузка - 5-10 %.

Но в целом - быть не должно, и что мысль уйти на нормальный таблицы в основном от непонимания механизмов LOB:(

ggvС разбиением на куски надо иметь ввиду, что по скорости FETCH граничным размером является 20KB - около этого значения скорость примерно равна, update на lob немного дороже, а вот на больших размерах LOB'ы становятся выгоднее.

Речь идет именно о чтении? Если 2 мега у меня будут читаться 3-4 секунды вместо 1-2 нынешних, меня это устроит. А соотношение на вставку?

Victor Metelitsa Lana Zapornikova Victor Metelitsa[quot Lana Zapornikova]
Бутылочное горлышко есть. Его не может не быть. И это не процессор, потому что загрузка < 100%.

Может не быть, если каким-то образом ждем на локах/семафорах/еще чем-нибудь. Могу рассказать историю из театра абсурда об улучшении производительности вдвое путем использования команды SLEEP.

Чего программа может ждать на семафорах? Это и будет бутылочным горлышком, если. Аналогично, последний раз у меня веб-апликуха вела себя странно после переноса на другой сервер, делала страницы по 10 сек, а выяснилось, что дело в настройках DNS. Но я считаю, что и это подпадает под понятие бутылочного горлышка.

Ну в общем дело терминологии. Для меня ожидание локов при простое и проца, и железа - баг приложения или конфигурации.

А чего DB2 ждет на семафорах я не знаю, но у меня сейчас на сервере, где бежит OLTP-шное приложение, висит специальный доморощенный сервис, единственная задача которого установить минимальный интервал для мультимедийного виндусового таймера в 0. Совершенно случайно обнаружили, что так DB2 работает вдвое быстрее. Точнее, если на сервере бежит одно такое приложение - все равно. Если 20 - тоже все равно. А вот если 2-3, то кранты, без этого db2sysс жрет процессора в два раза больше (а мы там ограниченны именно процем, не IO). Воспроизводится на разном железе (двухядерные процессоры везде).

К сожалению, озадачить IBM не удается - построить чисто db2 скрипт с таким же эффектом руки не дойдут никак.

Nikolay Kulikovdb2pd не игрались. оттедова можно вытащить кучку информации. Правда у нее много недокументированых опций... Надо посмотреть...

Э... а где бы эти недокументированные опции почитать?

Спасибо!

Victor MetelitsaНе особо полезно в данном случае, но для полноты:



Спасибо. Собственно, уже и планируем выполнить первую рекомендацию: на размерах до 5 Mb нет провала по производительности вставки (точнее, есть выигрыш), если вся запись идет асинхронно.

Ну а главный итог недельной борьбы (если кому интересно):

db2NtNoCache вопреки утверждениям документации сильно влияет на скорость работы с BLOB. Во всяком случае, для DMS. Сильно - в зависимости от соотношений железа/памяти/размера Tablespace имеем разницу от полутора до 5 раз на вставке данных (чтение не тестировалось).

IBM пока не прокомментировала расхождения доков и реальности.

Nikolay Kulikovdb2ntnocache является deprecated!!!! И говорит о том что все TS не кэшируются файловой системой!!! Что в случае с блобами не кошерно.
Если у вас стоит версия больше чем 8.2 нужно делать
0) db2set db2ntnoache=
1) BLOB в SMS tablespace
2) для всех табличных пространств кроме BLOB/CLOB
db2 alter tablespace xxx no file system caching

Официальный ответ IBM: читайте доки и ссылка
http://publib.boulder.ibm.com/infocenter/db2luw/v8/index.jsp?topic=/com.ibm.db2.udb.doc/admin/c0005408.htm

Читаю:

On Windows(R) NT, the registry variable DB2NTNOCACHE specifies whether or not DB2(R) will open database files with a NOCACHE option. If DB2NTNOCACHE=ON, file system caching is eliminated. If DB2NTNOCACHE=OFF, the operating system caches DB2 files. This applies to all data except for files that contain LONG FIELDS or LOBS.

Если честно, то и я, и англоговорящие сотрудники IBM понимаем эту фразу одинаково: параметр DB2NTNOCACHE не влияет на контейнеры с LONG. Тем более, что это, вообще говоря, логично. Моей паранойи не хватило проверять этот факт пока не приперло.

По поводу SMS: я делала тесты, у меня получается, что либо одинаковое время вставки SMS/DMS (если расширение дать небольшими порциями), либо SMS лучше (захват большими порциями), но есть очень заметные (до пары секунд) задержки на размещение новых страниц. Фрагментации на дисках нет. Есть способ бороться с такими задержками? У меня RealTime система, так что мне лучше всегда -10%, чем такие выбросы.