К каким данным относятся системные переменные MariaDB, например, innodb_log_buffer_size

0

Многие системные переменные MariaDB определяют максимальные размеры данных, и я не понимаю, какие данные точно измеряются, в контексте операций записи, где я отправляю много данных по JDBC, например:

innodb_buffer_pool_size = 24696061952

а также

innodb_log_buffer_size = 8388608

а также

max_allowed_packet = 562036736

Я использую контрольный показатель, где я вставляю, обновляю или удаляю 50000 строк с 2 МБ необработанных данных, это дата и двойные данные.

Поэтому, когда MariaDB реализует эти ограничения, определенные переменными, смотрит ли он на необработанное значение параметров, отправляемых по проводам, или же включает в себя всю строку SQL?

т.е. просто измеряется

2012-01-01,0.1234
2012-01-02,0.4321
2012-01-03,0.9999
...

или он рассматривает байты в строке SQL:

UPDATE data SET value = 0.1234 WHERE date = '2012-01-01'
UPDATE data SET value = 0.4321 WHERE date = '2012-01-02'
UPDATE data SET value = 0.9999 WHERE date = '2012-01-03'

что в этом примере, очевидно, в 2 - 3 раза больше?

Теги:
mariadb

1 ответ

1

innodb_log_buffer_size

Это относится к чему-то внутреннему. транзакции записываются в журнал повтора (ib_logfile0/ib_logfile1). повторные записи журнала буферизуются в буфере журнала повтора до момента совершения транзакции. Формат записей журнала повторного использования не документируется и также может быть изменен между версиями. Вы можете увидеть, сколько записано в журнал, просмотрев изменения переменной состояния innodb_os_log_written.

 MariaDB [test]> show global status like 'innodb_os_log_written';
 +-----------------------+-------+
 | Variable_name         | Value |
 +-----------------------+-------+
 | Innodb_os_log_written | 12800 |
 +-----------------------+-------+
 1 row in set (0.00 sec)

innodb_buffer_pool_size

Ваши данные крошечные, а буферный пул достаточно велик. Буферный пул - это то, как innodb кэширует данные. Если данные больше, чем буферный пул, которого нет в вашем случае, Innodb нужно будет читать с диска чаще. Поэтому оставьте это как есть, или вы можете уменьшить его.

max_allowed_packet

Это всего лишь мера безопасности, пытаясь предотвратить DDOS. Если вы отправляете очень большие пакеты, они заставляют сервер выделять больше памяти и, возможно, исчерпывают память. Но если вы не отправляете большие пакеты, сервер не выделяет много памяти, и если вы не боитесь DDOS, вы можете иметь его размером до 1G.

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

MariaDB [test]> show status like 'bytes%';
+----------------+-------+
| Variable_name  | Value |
+----------------+-------+
| Bytes_received | 570   |
| Bytes_sent     | 1716  |
+----------------+-------+
2 rows in set (0.00 sec)

Как это соответствует размеру данных, которые вы отправляете? Не всегда есть прямой ответ.

  • Заявления, которые не подготовлены (на стороне сервера)

    Если вы просто отправляете неподготовленные запросы, вы отправите 4 байта заголовка пакета + 1 байт для команды (COM_QUERY) + строку запроса SQL. если запрос больше 16 М, он будет разбит на несколько пакетов, а на один пакет на 4 байта.

  • Заявления, подготовленные на стороне сервера.

    С подготовленными на стороне сервера инструкциями это сложнее. Каждый тип данных имеет свою собственную кодировку. , поэтому ints не отправляются как текст, ни плавающие, ни даты. строки по-прежнему отправляются как строки. Обычно количество отправленных данных будет немного меньше (вы не отправляете SQL-команды, а только данные).

  • Пакетная оптимизация

    Сервер MariaDB 10.2 и JDBC также имеют оптимизацию для отправки нескольких данных для одного подготовленного оператора. Это может уменьшить количество данных, отправленных клиентом (немного), но количество данных, полученных клиентом, будет значительно сокращено, это всего лишь один пакет для всех команд, а не для каждой команды. Эта оптимизация пока не работает для DELETE.

Для пакетной обработки заявлений, которые не подготовлены на стороне сервера, JDBC имеет еще одну оптимизацию, которая преобразует много похожих запросов INSERT в одну мульти-вставку, что также уменьшает количество отправленных и полученных байтов, но это только INSERT (там теперь задача сделать что-то подобное для DELETE)

Поделиться
  • 0
    Предположим, что max_allowed_packet не должен превышать 2% ОЗУ, иначе может возникнуть max_allowed_packet памяти, когда происходит много сложных вещей.
  • 0
    Пакетирование 100 строк в одном INSERT выполняется примерно в 10 раз быстрее. Делайте это, когда это практично
Показать ещё 2 комментария

Ещё вопросы

Сообщество Overcoder
Наверх
Меню