Linux Ubuntu Server 16.04, 14.04

Как видно на скрине за 15 минут + 50гб виртуалки

Hi Ivan,

Thanks for the report.

Can you say anything about your workflow? Is it DML-only, or is there DDL, and what kind, or are there lots of admin statements? How many connections run at a time? How often do they reconnect? Could you please paste or attach some typical SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST \G outputs?

Further, please store the output of SHOW GLOBAL STATUS after you started the server (before the memory started growing), and again when it's already grown close to the edge, before you have to restart the server.

Before you restart the server, please send SIGHUP (kill -s SIGHUP <pid>). It should make the server write something to the error log. Please attach the whole error log since server startup and till the end of the session, when you restart it.

1_1.csv SELECT * FROM INFORMATION_SCHEMA.PROCESSLIST
1_2.csv SHOW GLOBAL STATUS before restart server
1_3.csv SHOW GLOBAL STATUS after restart server

Я на самом основном уже делаю откат на 10.1.24
На втором сервере могу пока все что необходимо скинуть.
Второй с 4Гб ОЗУ. 1_2.csv VIRT = 40Gb
Прирост памяти увеличивается от количества записываемых данных (INSERT). Количество соединений всегда примерно одинаковое.
То что скинул это постоянный набор - это программы. Еще может быть максимум 20 соединений от Apache2 - которые только читают.
Остановка apache ничего не меняет - прирост постояно продолжается
Елена - объясните что такое Is it DML-only, or is there DDL
У меня обычные компы - не виртуалка. С Ubuntu Server, LAMP

Прирост где-то около 1 000 000 - 3 000 000 записей в сутки, которые раскладываются по 3 таблицам

DML – data modification language – это INSERT/REPLACE, UPDATE, DELETE, SELECT, LOAD DATA, работа с HANDLER, вызов процедур.
DDL – data definition language – это всевозможные CREATE, ALTER, DROP, а также TRUNCATE.
Admin statements – это работа с таблицами, типа ANALYZE, OPTIMIZE, CHECK etc, с аккаунтами, с переменными (SET), плагинами (INSTALL/UNINSTALL), логами (FLUSH) и т.п.

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

Судя по статусу, в основном выполняется DML, много используются InnoDB, триггеры и транзакции; очень много присваиваний переменных (SET), создаются какие-то UDF, но непонятно используются ли; одновременных соединений не очень много, но реконнекты происходят часто.

Всё это (хотя и не только это) – потенциальные подозреваемые в утечке.

Пожалуйста, сохраните и пришлите error log – желательно с результатом SIGHUP, но если не получится, то хотя бы просто полную сессию сервера от старта и до рестарта.

Да у меня DML
Идет постоянное заполнение таблиц.
И тригер который перекладывает данные из одной таблицы в другую, с небольшой конвертацией.
На основном сервере тригер тоже есть, но он просто проверяет определенные поля на наличие определенных данных и при наличии пишет данные в другую таблицу.

Сейчас на сервер практически нет прихода данных, но началось кеширование, которое строит отчеты по всем пришедшим за предыдущие сутки данным. Роста нет.

Simplified test case:

--let $n= 1000000

CREATE TABLE t1 (a INT);

INSERT INTO t1 VALUES (1);

CREATE TABLE t2 (b INT);

CREATE TRIGGER tr AFTER UPDATE ON t1 FOR EACH ROW SELECT (SELECT b FROM t2) INTO @x;

--disable_query_log

--echo # Running $n queries

while ($n)

{

    UPDATE t1 SET a = 2;

    --dec $n

}

--enable_query_log

DROP TABLE t1,t2;

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                 

25926 elenst    20   0  1.175t 1.045g  14516 S  99.5  6.7   5:46.77 mysqld                                  

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND                                 

27115 elenst    20   0 16.412g 0.015t   2716 S  49.4 95.2   0:11.61 mysqld                                  

Trigger and subquery from a table appear to be important here. Without the trigger the same query executed the same number of times doesn't cause any memory consumption growth; without the subquery the same trigger also works fine.

Not reproducible on 10.1.

igor, this is caused by your commit 82cb35be11:

commit 82cb35be11c

Author: Igor Babaev <igor@askmonty.org>

Date:   Wed Mar 23 16:09:58 2016 -0700

    Changed the base class for Item_window_func from Item_result_field to

    Item_func_or_sum.

    Implemented method update_used_tables for class Item_findow_func.

    Added the flag Item::with_window_func.

    Made sure that window functions could be used only in SELECT list

    and ORDER BY clause.

    Added test cases that checked different illegal placements of

    window functions.

In particular, by this change:

804

805

   thd->lex->current_select->parsing_place= SELECT_LIST;

806

  if (setup_fields(thd, ref_ptrs, fields_list, MARK_COLUMNS_READ,

807

                   &all_fields, 1))

808

    DBUG_RETURN(-1);

809

  thd->lex->current_select->parsing_place= save_place;

810

In this bug, trigger invokes Item_singlerow_subselect::fix_length_and_dec() which invokes subselect_single_select_engine::fix_length_and_dec(), then subselect_engine::set_row() and Item_cache::get_cache(). The latter creates a new Item. And the Item constructor counts all items in the SELECT and HAVING clauses:

495

    enum_parsing_place place= 

496

      thd->lex->current_select->parsing_place;

497

    if (place == SELECT_LIST || place == IN_HAVING)

498

      thd->lex->current_select->select_n_having_items++;

With your change thd->lex->current_select->select_n_having_items is increased for every trigger invocation, and st_select_lex::setup_ref_array() will allocate larger and larger arrays every time.

The fix for this bug was pushed into the 10.2 tree.

For future reference, stored procedures were also affected (it was also fixed):

CREATE TABLE t2 (b INT);

--delimiter $

CREATE PROCEDURE pr() 

BEGIN

  DECLARE n INT DEFAULT 0;

  WHILE n < 100000

  DO

    SELECT (SELECT b FROM t2) INTO @x;

    SET n = n+1;

  END WHILE;

END $

--delimiter ;

CALL pr();

DROP PROCEDURE pr;

DROP TABLE t2;

Also, there could be a scenario without an obvious subquery in the SELECT list:

CREATE TABLE t2 (b INT);

CREATE VIEW v2 AS SELECT * FROM t2;

--delimiter $

CREATE PROCEDURE pr() 

BEGIN

  DECLARE n INT DEFAULT 0;

  WHILE n < 100000

  DO

    SELECT b FROM v2 INTO @x;

    SET n = n+1;

  END WHILE;

END $

--delimiter ;

CALL pr();

DROP PROCEDURE pr;

DROP VIEW v2;

DROP TABLE t2;

Prepared statements which are re-executed multiple times also triggered the same problem:

CREATE TABLE t2 (b INT);

CREATE VIEW v2 AS SELECT * FROM t2;

PREPARE stmt FROM "SELECT b FROM v2";

--let $n= 100000

while ($n)

{

    EXECUTE stmt;

    --dec $n

}

DROP VIEW v2;

DROP TABLE t2;