Проблема
Я пытаюсь создать дополнительный индекс с Phoenix. Создание индекса занимает несколько часов. По-видимому, это связано с медленным сканированием HBase, поскольку я заметил следующую производительность:
- Мне может потребоваться 2 часа для сканирования таблицы, тогда как другие разработчики сообщили несколько минут для больших таблиц (100 миллионов строк).
- Оболочка HBase может подсчитывать строки в ок. скорость 10 000 в секунду, что означает 3800 с ( > 1 час!) для подсчета всех строк этой таблицы.
Оба с оболочкой HBase и сканером Java.
NB: операция GET (по строке) достигается с хорошими показателями (приблизительно 0,5 с).
Контекст
- 38 миллионов строк /1000 столбцов/односетевое семейство /96Go с сжатием GZ.
- У кластера есть 6 узлов (126Go RAM, 24 ядра) с 5 региональными серверами.
- Hortonworks Data Platform 2.2.0
Устранение неполадок
На основе книги HBase (http://hbase.apache.org/book.html#performance), вот что я уже проверил:
1) Оборудование
- IO (диск)
- NMon говорит, что диск никогда не занят более 80%, а чаще всего между 0 и 20%
- Топ говорит, что HBase JVM не заменяет (проверено 2 из 5 RS)
- IO (сеть): каждый активный интерфейс node стоит на одном и том же коммутаторе (весь второй пассивный интерфейс подключен к другому коммутатору)
2) JVM
- GC останавливается в порядке (несколько миллисекунд приостанавливаются каждую минуту)
- Куча выглядит нормально (не слишком близко к пределу)
- CPU поразительно LOW: не более 10%
- Темы:
- Активные потоки (10 "RpServe.reader = N" + несколько других) не содержат никаких утверждений
- Лот припаркованной нити ничего не делает (60 "DefaultRpcServer.handler = n", приблизительно 15 других)
- Огромный список клиентов IPC без статуса потока
3) Данные
- была загружена с использованием Hive + completebulkload.
- Количество регионов:
- 13 регионов, что означает, что для каждого RS имеется от 2 до 3 больших областей, что и ожидается.
- Эффективность сканирования остается неизменной после форсирования крупного уплотнения.
- Размер региона довольно однородный: 4,5Go (+/- 0,5) для 11 областей, 2,5Go для 2 областей.
4) Конфигурация HBase
-
Большая конфигурация не изменилась.
- HBase env указывает только порты для консоли JMX
- На сайте HBase есть несколько настроек для Phoenix
-
Некоторые параметры, которые выглядели хорошо для меня
- hbase.hregion.memstore.block.multiplier
- hbase.hregion.memstore.flush.size: 134217728 байт (134Go)
- Отношение Xmn Xmx:.2 Максимальное значение Xmn: 512 Mb Xms: 6144m
- hbase.regionserver.global.memstore.lowerLimit: 0.38
- hbase.hstore.compactionTreshold: 3
- hfile.block.cache.size: 0.4 (размер блока кэша AS% от кучи)
- Максимум HStoreFile (hbase.hregion.max.filesize): 10 go (10737418240)
- Кэш сканера клиента: 100 строк тайм-аут zookeeper: 30 секунд
- Максимальный размер ключа клиента: 10mo
- hbase.regionserver.global.memstore.lowerLimit: 0.38
- hbase.regionserver.global.memstore.upperLimit: 0.40
- Хранилища хранилища hstore: 10
- hbase.hregion.memstore.mslab.enabled:
- enabled hbase.hregion.majorcompaction.jitter: 0.5
-
Пробовал следующие изменения конфигурации без какого-либо влияния на производительность
- hbase-env.sh: попытался увеличить HBASE_HEAPSIZE = 6144 (так как по умолчанию он равен 1000)
- hbase-site.xml:
- hbase.ipc.server.callqueue.read.ratio: 0.9
- hbase.ipc.server.callqueue.scan.ratio: 0.9
5) Журнал не говорит ничего полезного
cat hbase-hbase-master-cox.log | grep "2015-05-11. * ERROR"
cat hbase-hbase-regionserver - *. log | grep "2015-05-11. * ERROR"
ничего не печатать
Печать WARN показывает не связанные с ней ошибки
2015-05-11 17: 11:10,544 WARN [B.DefaultRpcServer.handler = 8, queue = 2, port = 60020] shortcircuit.ShortCircuitCache: ShortCircuitCache (0x2aca5fca): не удалось загрузить 1074749724_BP-2077371184-184.10.17.65 -1423758745093 из-за исключения InvalidToken.
2015-05-11 17: 09: 12,848 WARN [regionserver60020-smallCompactions-1430754386533] hbase.HBaseConfiguration: параметр конфигурации "hbase.regionserver.lease.period" устарел. Вместо этого используйте "hbase.client.scanner.timeout.period"