Версия:

Руководство по разрешению проблем

Руководство по разрешению проблем

В данном руководстве используется сторонний модуль stat. Для его установки выполните команду:

$ sudo yum install tarantool-stat
        $ # -- ИЛИ --
        $ sudo apt-get install tarantool-stat

Проблема: при выполнении INSERT/UPDATE-запросов возникает ошибка ER_MEMORY_ISSUE

Возможные причины

  • Нехватка памяти (значения параметров arena_used_ratio и quota_used_ratio из box.slab.info() приближаются к 100%).

    Чтобы проверить значения данных параметров, выполните соответствующие команды:

    $ # подключаемся к админ-консоли нужного экземпляра Tarantool
            $ tarantoolctl enter <instance_name>
            $ # -- ИЛИ --
            $ tarantoolctl connect <URI>
    
    -- запрашиваем значение arena_used_ratio value
            tarantool> require('stat').stat()['slab.arena_used_ratio']
    
            -- запрашиваем значение quota_used_ratio value
            tarantool> require('stat').stat()['slab.quota_used_ratio']
    

Решение

У вас есть несколько вариантов действий:

  • Зайти в конфигурационный файл Tarantool и увеличить значение параметра box.cfg{memtx_memory} (при наличии свободных ресурсов).

    In versions of Tarantool before 1.10, the server needs to be restarted to change this parameter. The Tarantool server will be unavailable while restarting from .xlog files, unless you restart it using hot standby mode. In the latter case, nearly 100% server availability is guaranteed.

  • Провести очистку базы данных.

  • Проверьте, нет ли проблем с фрагментацией памяти:

    -- запрашиваем значение quota_used_ratio value
            tarantool> require('stat').stat()['slab.quota_used_ratio']
    
            -- запрашиваем значение items_used_ratio value
            tarantool> require('stat').stat()['slab.items_used_ratio']
    

    При высокой степени фрагментации памяти (значение параметра quota_used_ratio приближается к 100%, items_used_ratio около 50%) рекомендуется перезапустить Tarantool в режиме hot standby.

Проблема: Tarantool создает большую нагрузку на CPU

Возможные причины

Поток обработки транзакций нагружает ЦП более чем на 60%.

Решение

Подключиться к Tarantool с помощью утилиты tarantoolctl, внимательно изучить статистику запросов с помощью box.stat() и выявить источник потребления. Для этой цели могут оказаться полезными следующие команды:

$ # подключаемся к админ-консоли нужного экземпляра Tarantool
        $ tarantoolctl enter <instance_name>
        $ # -- ИЛИ --
        $ tarantoolctl connect <URI>
-- запрашиваем RPS для вызовов хранимых процедур
        tarantool> require('stat').stat()['stat.op.call.rps']

Критическое значение RPS — 75 000, в случае большого Lua-приложения (модульного приложения, содержащего более 200 строк кода) — 10 000 - 20 000.

-- запрашиваем RPS для запросов указанного типа
        tarantool> require('stat').stat()['stat.op.<query_type>.rps']

Критическое значение RPS для запросов типа SELECT/INSERT/UPDATE/DELETE — 100 000.

Если основная нагрузка генерируется SELECT-запросами, следует добавить slave-сервер и часть запросов обрабатывать на нем.

Если же нагрузка по большей части приходится на INSERT/UPDATE/DELETE-запросы, рекомендуется провести шардинг базы данных.

Проблема: обработка запросов прекращается по таймауту

Возможные причины

Примечание

Все описанные ниже ситуации можно распознать по записям в журнале Tarantool, начинающимся со слов 'Too long...'.

  1. Быстрые и медленные запросы обрабатываются в одном подключении, что приводит к забиванию readahead-буфера медленными запросами.

    Решение

    У вас есть несколько вариантов действий:

    • Увеличить размер readahead-буфера (box.cfg{readahead}).

      Перезапускать Tarantool при этом не требуется. Для обновления конфигурации необходимо подключиться к Tarantool с помощью утилиты tarantoolctl и передать в box.cfg{} новое значение параметра readahead:

      $ # подключаемся к админ-консоли нужного экземпляра Tarantool
              $ tarantoolctl enter <instance_name>
              $ # -- ИЛИ --
              $ tarantoolctl connect <URI>
      
      -- задаем новое значение readahead
              tarantool> box.cfg{readahead = 10 * 1024 * 1024}
      

      Пример расчета: при 1000 RPS, размере одного запроса в 1 Кбайт и максимальном времени обработки одного запроса в 10 секунд минимальный размер readahead-буфера должен равняться 10 Мбайт.

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

  2. Медленная работа дисков.

    Решение

    Проверить занятость дисков (с помощью утилиты iostat, iotop или strace посмотреть на параметр iowait) и попробовать разнести .xlog-файлы и снимки состояния базы данных по разным дискам (т.е. указать разные значения для параметров wal_dir и memtx_dir).

Проблема: параметры репликации lag и idle принимают отрицательные значения

Речь идет о параметрах box.info.replication.(upstream.)lag и box.info.replication.(upstream.)idle из сводной таблицы box.info.replication.

Возможные причины

Не синхронизированы часы на машинах или неправильно работает NTP-сервер.

Решение

Проверить настройки NTP-сервера.

Если проблем с NTP-сервером не обнаружено, то не следует ничего предпринимать, потому что при вычислении лага репликации используются показания системных часов на двух разных машинах, и в случае рассинхронизации может случиться так, что часы удаленного мастер-сервера всегда будут отставать от часов локального экземпляра Tarantool.

Проблема: общие параметры репликации не совпадают на репликах в рамках одного кластера

Речь идет о кластере, состоящем из одного мастера и нескольких реплик. В таком случае значения общих параметров из сводной таблицы box.info.replication, например box.info.replication.lsn, должны приходить с мастера и должны быть одинаковыми на всех репликах. Если такие параметры не совпадают, это свидетельствует о наличии проблем.

Возможные причины

Сбой репликации.

Решение

Перезапустить репликацию.

Проблема: репликация мастер-мастер остановлена

Речь идет о том, что параметр box.info.replication(.upstream).status имеет значение stopped.

Возможные причины

В репликационном кластере, состоящем из двух мастер-серверов, один из серверов попытался выполнить действие, уже выполненное другим сервером, – например, повторно вставить кортеж с таким же уникальным ключом (распознается по ошибке вида 'Duplicate key exists in unique index 'primary' in space <space_name>').

Решение

Возобновить репликацию с помощью следующих команд (должны быть выполнены на всех мастер-серверах):

$ # подключаемся к админ-консоли нужного экземпляра Tarantool
        $ tarantoolctl enter <instance_name>
        $ # -- ИЛИ --
        $ tarantoolctl connect <URI>
-- перезапускаем репликацию
        tarantool> original_value = box.cfg.replication
        tarantool> box.cfg{replication={}}
        tarantool> box.cfg{replication=original_value}

Также рекомендуется перейти на текстовые первичные ключи или настроить репликацию мастер-реплика.

Проблема: Tarantool работает заметно медленнее, чем раньше

Возможные причины

Неэффективное использование памяти (память занята большим количеством неиспользуемых объектов).

Решение

Call the Lua garbage collector with the collectgarbage(„count“) function and measure its execution time with the Tarantool functions clock.bench() or clock.proc().

Пример кода для подсчета потребляемой памяти:

$ # подключаемся к админ-консоли нужного экземпляра Tarantool
        $ tarantoolctl enter <instance_name>
        $ # -- ИЛИ --
        $ tarantoolctl connect <URI>
-- lзагрузка модуля clock для работы со временем
        tarantool> local clock = require 'clock'
        -- запускаем таймер
        tarantool> local b = clock.proc()
        -- запускаем сборку мусора
        tarantool> local c = collectgarbage('count')
        -- останавливаем таймер по завершении сборки мусора
        tarantool> return c, clock.proc() - b

Если возвращаемое clock.proc() значение больше 0.001, это может являться признаком неэффективного использования памяти (активного вмешательства не требуется, но рекомендуется оптимизация кода). Если значение превышает 0.01, необходимо провести подробный анализ кода и оптимизировать потребление памяти.

Если значение больше 0,01, код приложения однозначно необходимо проанализировать на предмет оптимизации использования памяти.