Spec-Zone .ru
спецификации, руководства, описания, API
|
|
Spec-Zone .ru
спецификации, руководства, описания, API
|
NDB клиент управления CLUSTERLOG STATISTICS команда
может обеспечить много полезных статистических данных в своем выводе. Счетчики, предоставляющие информацию о
состоянии кластера, обновляются в 5-секундных интервалах создания отчетов координатором транзакции (TC) и
локальный обработчик запроса (LQH), и пишутся журналу кластера.
Статистика координатора транзакции. У каждой транзакции есть один координатор транзакции, который выбирается одним из следующих методов:
Круговым способом
Коммуникационной близостью
(Начинание с MySQL Cluster NDB 6.3.4:), предоставляя размещение данных подсказывают, когда транзакция запускается
Можно определить, какой метод выбора TC используется для транзакций, запущенных с данного узла SQL,
используя ndb_optimized_node_selection системная переменная.
Все операции в пределах той же самой транзакции используют тот же самый координатор транзакции, который сообщает о следующей статистике:
Trans count. Это - транзакции числа, запущенные
в последнем интервале, используя этот TC в качестве координатора транзакции. Любая из этих транзакций,
возможно, фиксировала, была прервана, или остается незафиксированной в конце интервала создания отчетов.
Транзакции не переходят между TC.
Commit count. Это - число транзакций, используя
этот TC в качестве координатора транзакции, которые фиксировались в последнем интервале создания
отчетов. Поскольку некоторые транзакции, фиксировавшие в этом интервале создания отчетов, возможно,
запустились в предыдущем интервале создания отчетов, это возможно для Commit
count быть больше чем Trans count.
Read count. Это - число операций чтения
первичного ключа, используя этот TC в качестве координатора транзакции, которые были запущены в
последнем интервале создания отчетов, включая простые чтения. Это количество также включает чтения,
выполняемые как часть операций уникального индекса. Операция чтения уникального индекса генерирует 2
операции чтения первичного ключа — 1 для скрытой таблицы уникального индекса, и 1 для таблицы, на
которой имеет место чтение.
Simple read count. Это - число простых операций
чтения, используя этот TC в качестве координатора транзакции, которые были запущены в последнем
интервале создания отчетов. Это - подмножество Read count. Поскольку
значение Simple read count постепенно увеличивается в различном моменте
времени от Read count, это может отстать Read
count немного, таким образом, это мыслимо что Simple read count
не равно Read count для данного создания отчетов об интервале, даже если
все чтения, сделанные в течение того времени, были фактически простыми чтениями.
Write count. Это - число операций записи
первичного ключа, используя этот TC в качестве координатора транзакции, которые были запущены в
последнем интервале создания отчетов. Это включает всех, вставляет, обновляет, пишет и удаляет, так же
как записи, выполняемые как часть операций уникального индекса.
Работа обновления уникального индекса может генерировать многократные операции чтения PK и операции записи на индексировать таблице и на базовой таблице.
AttrInfoCount. Это - число 32-разрядных слов
данных, полученных в последнем интервале создания отчетов для операций первичного ключа, используя этот
TC в качестве координатора транзакции. Для чтений это пропорционально числу столбцов, которые требуют.
Для вставок и обновлений, это пропорционально числу столбцов, записанных, и размер их данных. Для
удаляют операции, это обычно - нуль.
Операции уникального индекса генерируют многократные операции PK и так увеличьте это количество.
Однако, слова данных, отправленные, чтобы описать работу PK непосредственно, и ключевую отправленную
информацию, не считаются здесь. Информация атрибута,
отправленная, чтобы описать столбцы, чтобы читать для сканирований, или описать ScanFilters, также
не включается AttrInfoCount.
Concurrent Operations. Это - число первичного
ключа или операций сканирования, используя этот TC в качестве координатора транзакции, которые были
запущены во время последнего интервала создания отчетов, но которые не были завершены. Операции
постепенно увеличивают этот счетчик, когда они запускаются и постепенно уменьшают его, когда они
завершаются; это происходит после фиксаций транзакции. Грязные чтения и записи — так же как отказавшие
операции — постепенно уменьшают этот счетчик.
Максимальное значение это Concurrent Operations может иметь
максимальное количество операций, которые может поддерживать блок TC; в настоящий момент это (2 * MaxNoOfConcurrentOperations) + 16 +
MaxNoOfConcurrentTransactions. (Для получения дополнительной информации об этих
параметрах конфигурации, см. раздел Параметров Транзакции Раздела
17.3.2.6, "Узлы данных Кластера MySQL Defining".)
Abort count. Это - число транзакций, используя
этот TC в качестве координатора транзакции, которые были прерваны во время последнего интервала создания
отчетов. Поскольку некоторые транзакции, которые были прерваны в последнем интервале создания отчетов,
возможно, запустились в предыдущем интервале создания отчетов, Abort count
может иногда быть больше чем Trans count.
Scans. Это - число сканирований таблицы,
используя этот TC в качестве координатора транзакции, которые были запущены во время последнего
интервала создания отчетов. Это не включает сканирования диапазона (то есть, упорядоченный индексируют
сканирования).
Range scans. Это - число упорядоченных,
индексируют сканирования, используя этот TC в качестве координатора транзакции, которые были запущены в
последнем интервале создания отчетов.
Локальная статистика обработчика запроса (Operations). Есть 1 событие
кластера на локальный блок обработчика запроса (то есть, 1 на процесс узла данных). Операции записываются в LQH,
где данные, на которых они работают, находятся.
Единственная транзакция может работать на данных, хранивших в многократных блоках LQH.
Operations статистическая величина обеспечивает число локальных операций,
выполняемых этим блоком LQH в последнем интервале создания отчетов, и включает все типы операций чтения, и
операции записи (вставьте, обновите, запишите, и удалите операции). Это также включает операции, используемые,
чтобы тиражировать записи. Например, в кластере с 2 копиями, запись к основной копии записывается в основном
LQH, и запись к резервному копированию будет записана в резервном LQH. Операции уникального ключа могут привести
к многократным локальным операциям; однако, это не включает локальные
операции, сгенерированные в результате сканирования таблицы, или упорядоченный индексируют сканирование, которые
не считаются.
Статистика планировщика процесса. В дополнение к статистике, о которой сообщает координатор транзакции и локальный обработчик запроса, у каждого процесса ndbd есть планировщик, который также обеспечивает полезные метрики, касающиеся производительности MySQL Cluster. Этот планировщик работает в бесконечном цикле; во время каждого цикла планировщик выполняет следующие задачи:
Считайте любые входящие сообщения из сокетов в буфер задания.
Проверьте, есть ли какие-либо синхронизированные сообщения, которые будут выполняться; если так, поместите их в буфер задания также.
Выполните (в цикле) любые сообщения в буфере задания.
Отправьте любые распределенные сообщения, которые были сгенерированы, выполняя сообщения в буфере задания.
Ожидайте любых новых входящих сообщений.
Статистические данные планировщика процесса включают следующее:
Mean Loop Counter. Это - число циклов,
выполняемых в третьем шаге от предыдущего списка. Эта статистическая величина увеличения размера как
использование буфера TCP/IP улучшается. Можно использовать это, чтобы наблюдать изменения в
производительности, поскольку Вы добавляете новые процессы узла данных.
Mean send size и Mean receive
size. Эти статистические данные позволяют Вам измерить эффективность, соответственно пишет и
читает между узлами. Значения даются в байтах. Более высокие значения означают более низкую стоимость на
байт, отправленный или полученный; максимальное значение составляет 64 K.
Чтобы вызвать весь кластер регистрируют статистику, которая будет зарегистрирована, можно использовать следующую
команду в NDB клиент управления:
ndb_mgm> ALL CLUSTERLOG STATISTICS=15
Устанавливание порога для STATISTICS к 15 причинам журнал кластера,
чтобы стать очень многословный, и вырасти вполне быстро в размере, в прямой пропорции к числу узлов кластера
и количеству действия в MySQL Cluster.
Для получения дополнительной информации о клиентских командах управления MySQL Cluster, касающихся журналирования и создания отчетов, см. Раздел 17.5.6.1, "MySQL Cluster Logging Management Commands".