История версий
Требования

Введение

Быстрый старт

Развертывание

Моделирование данных

Подключение

Запись данных

Миграция

Запросы

Операции и обслуживание

Настройка производительности

Устранение неполадок

Справочник

Справочник по SQL

Часто задаваемые вопросы

YMatrix Производительность: Часто задаваемые вопросы

Этот документ содержит распространённые проблемы, связанные с оптимизацией производительности YMatrix.


1 Отчёт стресс-теста на Java Connection timed out

Стресс-тест запросов через JDBC, конкуренция 50, пул соединений использует Druid от Alibaba.
Время ответа стабильно в течение 2,5 минут, после чего начинает увеличиваться. Мастер начинает выдавать следующую ошибку:
ERROR "failed to acquire resources on one or more segments", "can not connect to server: Connection timed out".
Логи ошибок/паники сегмента None

Анализ проблемы

Распределённая база данных генерирует большое количество передач данных по TCP/UDP, каждая из которых использует отдельный порт. Эти порты или соединения OS воспринимает как единовременные маршрутизируемые сессии (connection conn).
Параметр системы nf_conntrack_max определяет максимальное количество маршрутизационной информации, которое OS может одновременно поддерживать.
В данном случае несколько виртуальных машин размещены на одном физическом сервере, и виртуальная сеть использует NAT. При одновременном возникновении большого числа параллельных запросов виртуальная маршрутизационная информация резко возрастает и может быстро превысить порог nf_conntrack_max, что приводит к активному отбрасыванию сетевой картой пакетов, которые не могут быть обработаны.

Это также объясняет, почему при большей конкуренции вероятность потери пакетов возрастает.

Решение

Измените параметры ядра:

sudo sysctl net.netfilter.nf_conntrack_buckets=262144
sudo sysctl net.netfilter.nf_conntrack_max=1048576


2 Запрос SQL с длительным выполнением оператора движения

В плане выполнения запроса обнаружено, что оператор движения потребляет значительное время.

Анализ проблемы

Бизнес-среда может быть облачной. Облачные среды неэффективно обрабатывают UDP, что может приводить к высокой задержке UDF или высокой вероятности потери пакетов, косвенно увеличивая время передачи данных UDF.
Кроме того, уровень логирования пользователя может быть установлен на высокие значения, например, debug5, что также снижает эффективность передачи UDP из-за большого объёма вывода логов.

Решение

  1. Переключитесь на TCP-соединение.
  2. Включите ic proxy.
  3. Снизьте уровень логирования.


3 Клиент долго возвращает большой объём данных

Описание проблемы

Длительное время возврата большого объёма данных при использовании клиентов PSQL или других клиентов.

Решение

Установите параметр FETCH_COUNT перед выполнением запроса для ограничения количества возвращаемых строк за один раз.

postgres=# \set FETCH_COUNT 200
postgres=# SELECT *  FROM test_table;


4 После выполнения точечных запросов на уровне Java-приложения в логах базы данных появляется большое количество привязанных переменных

Анализ проблемы

Большое количество привязанных переменных (bind) создаёт значительную нагрузку на производительность. Эту нагрузку можно избежать, изменив параметр preferQueryMode. Установка preferQueryMode=simple обычно обеспечивает лучшую производительность, поскольку запросы выполняются только на узле, где находятся данные, и не требуют распределённой подготовки и передачи данных.

Решение

Необходимо выполнить оба шага:

  1. Добавьте параметр preparedThreshold=0&preferQueryMode=simple в URI.
  2. Версию JDBC необходимо обновить до postgresql-9.4.1210.jar и выше. Старые версии JDBC не поддерживают параметр preferQueryMode.

5 Как заменить утилиту addr2line, вызывающую сбои Postgres или высокое потребление памяти.

Описание проблемы

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

Анализ проблемы

Просмотр системного лога сообщений показал, что в определённый момент времени на сервере появилось большое количество процессов addr2line, что привело к нехватке ресурсов сервера.

Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400707] [  96593]  1001 96593    78471    24188   249856        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400708] [  96594]  1001 96594    85480    28085   290816        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400709] [  96595]  1001 96595    85480    29534   307200        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400710] [  96596]  1001 96596    77318    23547   249856        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400711] [  96597]  1001 96597    85480    29597   294912        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400712] [  96598]  1001 96598    85480    31518   315392        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400714] [  96599]  1001 96599    85480    29146   290816        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400715] [  96600]  1001 96600    77318    23283   253952        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400716] [  96601]  1001 96601    77318    23322   253952        0             0 addr2line
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.400718] [  96602]  1001 96602    76199    22816   241664        0             0 addr2line
......
......
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.402077] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/system.slice/matrixdb5.supervisor.service,task=addr2line,pid=96124,uid=1001
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.402084] Out of memory: Killed process 96124 (addr2line) total-vm:355284kB, anon-rss:141732kB, file-rss:0kB, shmem-rss:0kB
Aug 29 14:46:17 yonmatrix-01 kernel: [13522.427650] oom_reaper: reaped process 96124 (addr2line), now anon-rss:0kB, file-rss:0kB, shmem-rss:0kB

Решение

Оригинальную утилиту addr2line на системе можно резервно скопировать и заменить на llvm-addr2line. Пример на Galaxy Kirin V10 SP3:

  1. Установите llvm
    # yum install llvm -y
  2. Создайте резервную копию оригинальной addr2line
    # mv /usr/bin/addr2line /usr/bin/addr2line_bak
  3. Создайте символьную ссылку
    # ln -s /usr/bin/llvm-addr2line /usr/bin/addr2line
  4. Проверьте успешность замены
    # addr2line --version
← Предыдущая
PLPython