Как работает многопоточная архитектура в DB2 9.5

Обзор

В версии DB2® 9.5 для Linux®, UNIX® и Windows® с кодовым названием “Viper 2" добавлены новые возможности многопоточности, полезные для тех, кто регулярно следит за процессами или потоками и хочет понять, сколько памяти использует их база данных, или упростить такие ответственные задачи, как резервное копирование, восстановление и откат. В статье объясняется, как эти изменения влияют на параметры конфигурации, и описывается новая технология, реализованная в DB2 9.5.

Шашанк Харче, штатный инженер-программист, IBM

Шашанк Харче (Shashank Kharche) — штатный инженер-программист лаборатории IBM Australia Development Lab в Сиднее. Он сертифицированный администратор DB2 IBM. В настоящее время Шашанк работает в отделении Down Systems Division Азиатско-Тихоокеанского региона. Он обладает богатым опытом в области СУБД DB2 и диагностики/решения серьезных проблем. Он опубликовал несколько технических записок (technotes) IBM. Имеет диплом бакалавра по вычислительной технике. Связаться с ним можно по адресу: shashank.kharche@au1.ibm.com.



01.04.2009

Введение

Чтобы разобраться в возможностях многопоточности DB2 9.5, начнем с модели процессов DB2. Всей моделью процессов DB2 управляют средства Base System Utilities (BSU). BSU выделяют память для экземпляра и базы данных, перехватывают и обрабатывают сигналы и управляют исключительными ситуациями, переданными DB2. На рис.1 приведена старая модель процессов DB2 для платформ Linux и UNIX.

Рисунок 1. Старая модель процессов DB2 на платформах Linux и UNIX
Старая модель процесса DB2 на платформах Linux и UNIX

Рис. 2 иллюстрирует новую модель процесса для Linux и UNIX.

Рисунок 2. Новая модель процесса DB2 на платформах Linux и UNIX
Новая модель процесса DB2 на платформах Linux и UNIX.

Связь между серверами базы данных, клиентами и приложениями поддерживается средой. Эта среда — не что иное, как модель процессов, используемая всеми серверами DB2. Она гарантирует, что файлы, используемые внутри СУБД, не будут мешать пользователю или приложениям базы данных.

За решение разнообразных задач, таких как обработка запросов приложений базы данных, чтение файлов журналов регистрации событий и перемещение записей журнала регистрации из буфера в файлы на диске, отвечают т.н. управляемые единицы ядра (engine dispatchable units - EDU). Как правило, сервер DB2 выделяет на каждую EDU задачу отдельную EDU. До версии DB2 9.5 большинство таких EDU обрабатывались как процессы в среде UNIX или Linux и как потоки в среде Windows. Теперь в версии 9.5 достигнуто единообразие моделей процессов DB2, так как на всех платформах - Linux, UNIX и Windows - EDU основаны на потоках.

Вот некоторые преимущества новой модели памяти:

  • Новая модель памяти проще и удобнее в конфигурировании. См. следующие документы из DB2 Information Center:
  • Эта модель экономит ресурсы:
    Используется гораздо меньше дескрипторов системных файлов. Наиболее заметное различие между процессами и потоками состоит в том, что все потоки процесса совместно используют одно и то же пространство памяти и определяемые системой ресурсы. В число таких ресурсов входят описатели файлов (дескрипторы файлов), совместно используемая память, примитивы синхронизации процессов и текущий каталог. Все потоки процесса могут пользоваться одними и теми же дескрипторами файлов. Каждому агенту не нужно вести собственную таблицу дескрипторов файлов.
  • Повышение производительности:
    В общем случае операционные системы могут быстрее переключаться (переключение контекста) между потоками одного и того же процесса, чем между разными процессами. Не требуется переключать адресное пространство. Так как глобальная память общая и выделять новую память почти не надо, создание потока осуществляется проще и быстрее, чем создание процесса. Создание процесса потребляет много тактов процессора и памяти.
  • Большее число автоматически и динамически конфигурируемых параметров уменьшает нагрузку на администратора БД.
    Об этом говорится в разделе Упрощение конфигурирования модели процесса настоящей статьи.
  • Теперь модель процессов одинакова для всех трех платформ: Linux, UNIX и Windows.

Мониторинг потоков при помощи db2pd и их отражение в выходных данных команды ps

До версии DB2 9.5 в средах UNIX и Linux при помощи системной команды ps или команды db2_local_ps можно было вывести список всех активных EDU DB2. В DB2 9.5 эти команды больше не распечатывают никаких потоков EDU внутри процесса db2sysc. Так что одно из изменений, которые заметят пользователи и администраторы DB2, когда при помощи этой команды ОС попытаются взглянуть на работающие в системе процессы, состоит в том, что вместо нескольких процессов они увидят только один. Это административное изменение, ожидаемое с точки зрения администратора БД.

$ ps -fu db2ins10
     UID     PID    PPID   C    STIME    TTY  TIME CMD
db2ins10 1237176 2109662   0   Feb 28      -  0:12 db2acd 0
db2ins10 1921136 2109662   0   Feb 28      -  0:14 db2sysc 0
db2ins10 2101494 1941686   0 14:22:34  pts/1  0:00 -ksh
db2ins10 2420958 2101494   0 15:25:33  pts/1  0:00 ps -fu db2ins10

Под AIX:
Чтобы увидеть все потоки процесса db2sysc (PID = 1921136):

Листинг 1. Просмотр всех потоков процесса db2sysc в системе AIX
$ ps -mo THREAD -p 1921136

    USER     PID    PPID       TID ST  CP PRI SC    WCHAN        F     TT BND COMMAND
db2ins10 1921136 2109662         - A    0  60 26        *    40401      -   - db2sysc 0
       -       -       -   1273899 S    0  60  1 f1000100403674b0   410400      -   - -
       -       -       -   1327331 Z    0  60  1        -   c00001      -   - -
       -       -       -   1392805 Z    0  60  1        -   c00001      -   - -
       -       -       -   1601705 Z    0  60  1        -   c00001      -   - -
       -       -       -   1814627 Z    0  60  1        -   c00001      -   - -
       -       -       -   1851457 S    0  60  1 f1000004f010de00   410400      -   - -
       -       -       -   1961987 Z    0  60  1        -   c00001      -   - -
       -       -       -   1974311 Z    0  60  1        -   c00001      -   - -
       -       -       -   2023571 S    0  60  1 f100010041b401b0   410400      -   - -
       -       -       -   2068591 Z    0  60  1        -   c00001      -   - -
       -       -       -   2179161 Z    0  60  1        -   c00001      -   - -
       -       -       -   2187515 Z    0  60  1        -   c00001      -   - -
       -       -       -   2216003 S    0  60  1        -   400400      -   - -
       -       -       -   2412647 Z    0  60  1        -   c00001      -   - -
       -       -       -   2551911 Z    0  60  1        -   c00001      -   - -
       -       -       -   2592969 Z    0  60  1        -   c00001      -   - -
       -       -       -   2621455 S    0  60  1 f1000100407f7e30   410400      -   - -
       -       -       -   2658531 S    0  60  1        -   418400      -   - -
       -       -       -   3031171 Z    0  60  1        -   c00001      -   - -
       -       -       -   3457047 Z    0  60  1        -   c00001      -   - -
       -       -       -   3899477 Z    0  60  1        -   c00001      -   - -
       -       -       -   4157609 Z    0  60  1        -   c00001      -   - -
       -       -       -   4390991 S    0  60  1        -   400400      -   - -
       -       -       -   4636819 Z    0  60  1        -   c00001      -   - -
       -       -       -   5628153 S    0  60  1        -   400400      -   - -
       -       -       -   6783009 Z    0  60  1        -   c00001      -   - -

Под Linux:

Чтобы увидеть все потоки процесса db2sysc (PID = 1921136): ps -lLfp 1921136

Жизнь администратора БД существенно облегчилась. Внесены усовершенствования в db2pd для распечатки процессов и потоков. Теперь для распечатки всех активных потоков EDU можно применять команду db2pd с опцией -edu. Это можно делать в системах UNIX, Linux и Windows.

Листинг 2. Просмотр всех потоков процесса db2sysc в системе Linux
$ db2pd -edu

Database Partition 0 -- Active -- Up 1 days 01:05:54
Список всех EDU для раздела 0 базы данных.

db2sysc PID: 1921136
db2wdog PID: 2109662
db2acd  PID: 1237176


EDU ID    TID         Kernel TID     EDU Name                 USR            SYS
===================================================================================
1801      1801           2216003        db2agent (idle) 0     0.706935     1.071737
1543      1543           5628153        db2resync 0           0.002641     0.004271
1286      1286           1851457        db2ipccm 0            0.082388     0.044037
1029      1029           2023571        db2licc 0             0.000211     0.001055
772       772            4390991        db2thcln 0            0.000244     0.000105
515       515            2621455        db2aiothr 0           2.740874     6.287562
2           2            1273899        db2alarm 0            0.274076     0.408226
258       258            2658531        db2sysc 0             2.085981     1.379128

Сколько памяти использует DB2?

Существует несколько способов проверки использования памяти:

  • db2pd -dbptnmem
  • db2 get snapshot for applications on sample
  • select * from table(admin_get_dbp_mem_usage())
  • db2mtrk -a и db2mtrk -p

Отметим следующее:

  • db2pd точно отображает иерархию общей памяти
  • Однако db2pd не может сообщить о выделении частной памяти
  • db2mtrk может сообщить о выделении частной памяти, но слаба в других отношениях
  • Использование частной памяти уже не представляет особого интереса
  • Может оказаться достаточно общего отчета db2pd -dbpntmem

Использование db2pd

Листинг 3. Пример db2pd
$ db2pd -dbptnmem

Database Partition 0 -- Active -- Up 1 days 01:11:27

Database Partition Memory Controller Statistics
(статистика контроллера памяти раздела базы данных)
Controller Automatic: Y
Memory Limit:         13994636 KB
Current usage:           76608 KB
HWM usage:            332736 KB
Cached memory:        16064 KB

Individual Memory Consumers (отдельные потребители памяти):

Name             Mem Used (KB) HWM Used (KB) Cached (KB)
========================================================
DBMS-db2ins10            46784         46784       10048
FMP_RESOURCES            22528         22528           0
PRIVATE                   7296          7296        6016

Информация по каждому полю:

Поле Controller Automatic имеет значение Y, если выбрано значение AUTOMATIC параметра конфигурации INSTANCE_MEMORY. Это означает, что менеджер БД автоматически определяет верхний предел потребления памяти.

Memory Limit — верхний предел доступной для использования памяти сервера DB2. Он соответствует значению параметра конфигурации INSTANCE_MEMORY.

Current usage — количество памяти, потребляемое сервером в данный момент.

HWM usage — пиковое значение потребления памяти с момента активизации раздела базы данных при выполнении команды db2start.

Cached memory — количество памяти, которая в настоящий момент не используется, но зарезервирована для повышения производительности при будущих запросах.

Отдельные потребители памяти:

  • Перечислены все зарегистрированные «потребители» памяти на сервере DB2 с указанием общего количества потребляемой ими памяти.
  • Name: Краткое обозначение «потребителя» памяти. Примеры:
    • APPL-<dbname> память приложения, потребляемая базой данных <dbname>
    • DBMS-xxx память, требуемая глобальному менеджеру базы данных
    • FMP_RESOURCES память, требуемая для связи с db2fmps
    • PRIVATE собственная память, необходимая для других целей
    • FCM_RESOURCES ресурсы Fast Communication Manager
    • LCL-<pid> сегмент памяти, используемый для связи с локальными приложениями
    • DB-<dbname> память базы данных, потребляемая базой данных <dbname>
  • Mem Used (KB): Сколько памяти выделено потребителю в данный момент.
  • HWM Used (KB): Пиковое значение используемой потребителем памяти.
  • Cached (KB): Количество памяти, которая в настоящее время не используется, но доступна для выделения в будущем.

Использование команды db2 get snapshot

Листинг 4. Пример использования команды db2 get snapshot
$ db2 get snapshot for applications on sample

Memory usage for application:

  Memory Pool Type                         = Application Heap
     Current size (bytes)                  = 65536
     High water mark (bytes)               = 65536
     Configured size (bytes)               = 1048576

Agent process/thread ID                    = 6463
  Agent Lock timeout (seconds)             = -1
  Memory usage for agent:

    Memory Pool Type                       = Other Memory
       Current size (bytes)                = 196608
       High water mark (bytes)             = 196608
       Configured size (bytes)             = 16710107136

Использование команд SQL

Листинг 5. Пример использования команды SQL
$ db2 "select * from table(admin_get_dbp_mem_usage())"

DBPARTITIONNUM MAX_PARTITION_MEM    CURRENT_PARTITION_MEM PEAK_PARTITION_MEM
-------------- -------------------- --------------------- --------------------
             0          14330507264             340590592            340852736

  1 record(s) selected.

Использование команды db2mtrk

Листинг 6. Пример использования команды db2mtrk -a
$ db2mtrk -a
Tracking Memory on: 2008/02/29 at 15:51:00

Application Memory for database: SAMPLE
   appshrh
   128.0K

  Memory for application 546
   apph        other
   64.0K       192.0K

  Memory for application 545
   apph        other
   64.0K       192.0K

  Memory for application 544
   apph        other
   64.0K       320.0K

  Memory for application 543
   apph        other
   64.0K       576.0K

  Memory for application 547
   apph        other
   64.0K       192.0K
Листинг 7. Пример использования команды db2mtrk -p
$ db2mtrk -p
Tracking Memory on: 2008/02/29 at 15:51:37

Memory for agent 6463
   other
   192.0K

Memory for agent 6206
   other
   192.0K
Memory for agent 5949
   other
   320.0K

Memory for agent 2094
   other
   576.0K

Memory for agent 6720
   other
   192.0K

Примечание: По умолчанию параметру INSTANCE_MEMORY присвоено значение AUTOMATIC, то есть максимальная выделяемая экземпляру память составляет определенный процент объема ОЗУ (75% для более мелких систем и 95% для более крупных систем). Сюда входят все локальные разделы для одного экземпляра.

db2 get dbm cfg show detail|grep INSTANCE_MEMORY
Size of instance shared memory(4KB)(INSTANCE_MEMORY)=AUTOMATIC(3498659)AUTOMATIC(3498659)

Нельзя навсегда установить разные значения INSTANCE_MEMORY для разных разделов базы данных. Для лицензий DB2 Express верхний предел INSTANCE_MEMORY ограничен еще и величиной 4 ГБ памяти (1 048 576 * 4 КБ страниц). Лицензии DB2 Workgroup ограничены максимум 16 ГБ памяти (4 194 304 * 4 КБ страниц). Попытки присвоить параметру конфигурации INSTANCE_MEMORY значение, превышающее эти пределы, закончатся сбоем с кодом ошибки SQL5130N, указывающим границу диапазона для данной лицензии. Другие типы лицензий не имеют дополнительных ограничений. Нельзя установить значение INSTANCE_MEMORY, превышающее объем ОЗУ.


Решение проблем резервного копирования и восстановления DPF

Каждый раздел получает отдельную метку времени

В предыдущих версиях DB2:

$ db2_all " db2 backup db test"

Backup successful. The timestamp for this backup image is : 20080304124529
eva88: db2 backup db test completed ok

Backup successful. The timestamp for this backup image is : 20080304124544
eva88: db2 backup db test completed ok

Backup successful. The timestamp for this backup image is : 20080304124554
eva88: db2 backup db test completed ok

В то время как в DB2 9.5 команда BACKUP усовершенствована и использует список разделов базы данных, что дает единое системное представление.

$ db2 backup db test on all dbpartitionnums
Part  Result
----  -------------------------------
0000  DB20000I  The BACKUP DATABASE command completed successfully.
0010  DB20000I  The BACKUP DATABASE command completed successfully.

Backup successful. The timestamp for this backup image is : 20080304135942

Как определить, какие файлы журнала регистрации событий требуются при отмене отката?

$ db2 rollforward db test to 2008-03-01 and stop
SQL1275N  The stoptime passed to roll-forward must be greater than or equal to 
"2008-03-04-12.45.54.000000 UTC", because  database "TEST" on node(s) "0,1" 
contains information later than the specified time.

$ db2 rollforward db test to 2008-03-04-12.45.54.000000 and stop
DB20000I  The ROLLFORWARD command completed successfully.

Приведенный выше пример показывает, что если при отмене отката (rollforward) время (point in time – PIT), указанное в команде, прошло, вы получите сообщение об ошибке (SQL1275N). Оно указывает на корректное время PIT. Можно попробовать воспользоваться командой BACKUP с параметром INCLUDE logs. Однако в базе данных DPF команда BACKUP с параметром INCLUDE logs выдает сообщение об ошибке (SQL2032N). Так что эту опцию использовать нельзя.

Между тем в DB2 9.5 для минимизации времени восстановления можно воспользоваться оператором "TO END OF BACKUP" с командой ROLLFORWARD для отмены отката всех разделов в секционированной базе данных. Минимальное время восстановления — это самый ранний момент времени в интервале отмены отката, когда база данных остается согласованной (то есть объекты, перечисленные в каталоге базы данных, совпадают с объектами, физически присутствующими на диске). Вручную правильно определить момент времени для отмены отката базы данных трудно, особенно если это секционированная база данных. Опция "END OF BACKUP" облегчает эту задачу.

$ db2 rollforward db test to end of backup and stop
DB20000I  The ROLLFORWARD command completed successfully

Что важно знать об ограничениях пользователя?

Параметры User limits устанавливают или отображают различные ограничения на использование ресурсов оболочкой. Некоторые из этих ограничений полезно установить для предотвращения таких проблем, как запуск ошибочным сценарием оболочки безостановочного изготовления собственных копий или запуск пользователями системы бесконечно работающих процессов. Но что именно нужно установить? Ниже приводятся некоторые соображения по ограничению разных ресурсов.

  • При запуске db2 ограничений на данные и число файлов нет.
  • Стек ограничивать бессмысленно, так как DB2 создает собственное пространство стека (AGENT_STACK_SZ dbm cfg)

    На 64-битной UNIX
    По умолчанию: 4 МБ
    Минимум: 1 МБ
    Максимум: 128 МБ

    На 32-битной LINUX
    По умолчанию: 1 МБ
    Минимум: 64 KБ
    Максимум: 4 МБ
  • MAXFILOP — это максимальное значение для раздела базы данных. Новые значения по умолчанию составляют ~32K для 32-битной системы и ~64K для 64-битной.
  • Текущее значение ulimit (или 8 ГБ для AIX, если ulimit установлен в unlimited). DB2 заменяет значение предела unlimited для основной памяти (core). Чтобы получить core больше 8 ГБ, нужно явно установить значение core limit, превышающее 8 ГБ, но не unlimited.

Упрощение конфигурирования модели процессов

В этом разделе мы покажем, чем отличается поведение параметров конфигурации в DB2 9.5. Обратите внимание на значения по умолчанию и интервалы, так как они изменились.

Рисунок 3. Параметры конфигурации
Configuration parameters

* — на секционированном сервере базы данных с локальным и удаленным клиентами
** — этот параметр применяется при параллельном создании индекса
*** — при параллельном создании индекса этот параметр не применяется

Если у вас есть критические для производительности «неогороженные» (unfenced — выполняемые в том же адресном пространстве, что и сервер) внешние хранимые процедуры (SP) или определяемые пользователем функции (UDF), они должны правильно вести себя, когда к ним одновременно обращаются сразу несколько потоков (thread-safe). При переносе все внешние, неогороженные SP и UDF становятся «огороженными» (fenced).
В целях сохранения целостности данных, по соглашению, неогороженные SP и UDF должны изначально быть thread-safe, но это требование не проверяется. Исполнение не-thread-safe SP или UDF в многопоточном процессе может вызвать непредсказуемые проблемы. Поэтому в рамках процедуры миграции создайте сценарий для их преобразования в неогороженные.

В заключение коротко пробежимся по новым потокам и процессам:

  • db2thcln (очистка стека потоков): освобождает ресурсы по окончании EDU (только для UNIX).
  • db2aiothr (поток коллектора aio): управляет асинхронными запросами ввода-вывода к разделу базы данных (только для UNIX).
  • db2alarm (поток предупредительной сигнализации): уведомляет EDU по истечении запрошенного ими времени (только для UNIX).
  • db2vend (огороженный процесс вендора): исполняет код вендора от имени EDU, например, исполняет программу выхода пользователя с целью архивации журнала (только для UNIX).
  • db2extev (поток управления внешними событиями): то же, что и SIGUSR2.
  • db2acd: процесс контроля состояния.

Наконец, повлияет ли переход на DB2 9.5 на уже имеющиеся у вас приложения?
НЕТ, абсолютно НЕ повлияет. Все эти внутренние изменения никак не влияют на приложения. Они совершенно прозрачны с точки зрения администрирования и программирования приложений.

Ресурсы

Научиться

Получить продукты и технологии

Обсудить

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Information Management
ArticleID=379712
ArticleTitle=Как работает многопоточная архитектура в DB2 9.5
publish-date=04012009