Назад | Перейти на главную страницу

Почему кластер mysql не использует несколько ядер процессора?

У меня проблема с процессом ndbmtd. Когда я использую следующую конфигурацию, я ожидаю, что оба ядра на нашем сервере с процессором Intel (R) Pentium (R) G6950 @ 2,80 ГГц будут полностью загружены. К сожалению, этого не происходит. Используется только ядро ​​с id = 0. У второго нет нагрузки.

Моя конфигурация:

[ndbd default]
MaxNoOfExecutionThreads=2
[ndbd]
HostName=192.168.1.4
NodeId=3
LockExecuteThreadToCPU=0,1
LockMaintThreadsToCPU=0

mpstat -P ВСЕ

08:47:09 AM     CPU     %user     %nice   %system   %iowait    %steal     %idle
08:47:11 AM     all     44.64      0.00      1.75      1.25      0.00     52.37
08:47:11 AM       0     89.45      0.00      1.01      2.01      0.00      7.54
08:47:11 AM       1      0.99      0.00      1.98      0.00      0.00     97.03

Однако «вверху» показывает 90% -ное использование процесса ndbmtd (почему?)

Моя топология - 2 узла данных, ndb_mgmt в ВМ, mysqld в ВМ.

Мой процессор не способен на такое, у меня что-то неправильно сконфигурировано или mysql-cluster не может полностью загрузить многоядерные процессоры?

Я связался с командой разработчиков MySQL Cluster, и Фрейзер Клемент предоставил мне подробный ответ. Сообщите нам, как проходит ваше тестирование. Хорошее место, чтобы задать вопросы, относящиеся к MySQL Cluster, - это форум: forum.mysql.com/list.php?25

Этот процессор не имеет Hyperthreading

Итак, у него есть 2 настоящих ядра.

Согласно этому : http://dev.mysql.com/doc/refman/5.1/en/mysql-cluster-programs-ndbmtd.html , для параметра MaxNoOfExecutionThreads следует установить значение 2 для 2-ядерного хоста.

В нем также указано, что при значении 2 будет:

1 local query handler (LQH) thread

1 transaction coordinator (TC) thread

1 transporter thread

1 subscription manager (SUMA) thread

При использовании простого ndbd все эти функции находятся в одном потоке, при ndbmtd и MaxNoOfExecutionThreads = 2 они разделены, как показано. Обратите внимание, что это «функциональное» разбиение - каждый поток выполняет свою роль и, следовательно, требует разного количества ЦП для выполнения своей части работы. Для заданной пропускной способности количество процессора, потребляемого каждым типом потока, будет различным.

Более высокие значения MaxNoOfExecutionThreads увеличивают количество потоков LQH, каждый из которых должен брать на себя равную долю работы «LQH» и быть сбалансирован относительно друг друга. Однако другие потоки будут иметь другое потребление ЦП.

Наконец, строка LockExecuteThreadToCpu = 0,1 используется ndbmtd в своего рода циклическом стиле. К сожалению, существует слишком много потоков выполнения (4) для предоставленного количества процессоров, чтобы обеспечить равный баланс. Итак, что происходит, так это то, что одному потоку LQH предоставляется один ЦП, а три других потока совместно используют другой ЦП. Это может объяснить наблюдаемый дисбаланс.

Обратите внимание, что сопоставление потоков с процессорами выводится в stdout (журнал ndb_out) каждого процесса ndbmtd при его запуске. Используя аналогичный конфиг, я вижу следующее:

NDBMT: num_threads = 4

Создание экземпляра DBSPJNo = 0

Заблокировать threadId = 3936 для CPU id = 0

Заблокировать threadId = 3935 для CPU id = 0

Заблокировать threadId = 3937 для CPU id = 0

ПРЕДУПРЕЖДЕНИЕ. Слишком мало процессоров, указанных с помощью LockExecuteThreadToCPU. Указано только 2, но необходимо 4, это может вызвать разногласия.

Назначение потоков LQH выделенным ЦП и другим потокам будет разделять оставшиеся th: 2 tid: 3940 cpu: 0 OK PGMAN (1) DBACC (1) DBLQH (1) DBTUP (1) BACKUP (1) DBTUX (1) RESTORE (1)

th: 3 tid: 3933 cpu: 1 OK CMVMI (0)

thr: 1 tid: 3939 cpu: 1 OK BACKUP (0) DBLQH (0) DBACC (0) DBTUP (0) SUMA (0) DBTUX (0) TSMAN (0) LGMAN (0) PGMAN (0) RESTORE (0) DBINFO (0) PGMAN (5)

thr: 0 tid: 3938 cpu: 1 OK DBTC (0) DBDIH (0) DBDICT (0) NDBCNTR (0) QMGR (0) NDBFS (0) TRIX (0) DBUTIL (0) DBSPJ (0)

Мы видим, что один исполняемый поток (3940) заблокирован для ЦП 0, а другие заблокированы для ЦП 1. 3940 - это рабочий поток LQH (так как он имеет блок DBLQH с номером> 0 (DBLQH (1))) .

В этом примере потоки CMVMI (сетевой приемник ввода-вывода), DBLQH (0) / SUMA (0) и DBTC (0) привязаны к ЦП 1.

Таким образом, в зависимости от используемого трафика количество ЦП, потребляемого на ЦП 0 и ЦП1, будет несбалансированным. Обратите внимание, что «обслуживающие» потоки также заблокированы для ЦП 0, что, если ЦП 0 перегружен, может ухудшить ситуацию.

Если узким местом для этого типа трафика является обработка LQH, то увеличение MaxNoOfExecutionThreads до 4 или выше приведет к появлению 2 «рабочих» LQH, каждому из которых будет назначено ядро. Однако другие потоки также будут использовать одно из ядер, что ограничит ресурсы рабочего LQH на этом ядре.

Если рабочие LQH не являются узким местом, то наличие дополнительных рабочих LQH ​​может уменьшить использование ЦП для других потоков и снизить пропускную способность.

Я рекомендую поэкспериментировать с загрузкой трафика, проверить вывод ndbmtd, чтобы понять отображение, и измерить достижимую пропускную способность и задержку, а также наблюдать за балансом и использованием ядер ЦП.

Я думаю, что вы должны установить MaxNoOfExecutionThreads = 4, когда у вас 2 ядра в процессоре, это свойство должно быть установлено в разделе ndbd

[ndbd] MaxNoOfExecutionThreads = 2

Я не знаю, почему вы должны установить этот параметр 2xcores, но это работает