Гость
Войти | Профиль | Очистить
Действия ...
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Огромное потребление памяти в FB 2.5 / 16 сообщений из 16, страница 1 из 1
26.10.2017, 05:07
    #39542118
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
FB 2.5.7. Предыстория. С недавних пор у процесса сервера начала заканчиваться память с вот такими сообщениями:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
SERVER (Server)	Wed Oct 25 19:33:16 2017
	Database: -- CENSORED --
	unable to allocate memory from operating system
	At trigger 'BAT$RECEIPT$RECEIPT_BIU0' line: 6, col: 5
	internal Firebird consistency check (error during savepoint backout (290), file: exe.cpp line: 4056)


SERVER (Server)	Wed Oct 25 19:35:38 2017
	Database: -- CENSORED --
	internal Firebird consistency check (can't continue after bugcheck)


SERVER (Server)	Wed Oct 25 19:35:38 2017
	Database: -- CENSORED --
	internal Firebird consistency check (can't continue after bugcheck)

Сегодня поразбирался с этим триггером. Выяснилось, что на тестовой базе апдейт таблицы BAT$RECEIPT$RECEIPT увеличивает потребление памяти процессом сервера со 110 МБ до 1400 МБ и выше (дальше заканчиваются записи для обновления) при выполнении простого запроса:
Код: sql
1.
2.
3.
UPDATE BAT$RECEIPT$RECEIPT R
SET
    ID = ID


Методом комментирования нашли строку, при удалении которой сервер перестает потреблять память:
Код: sql
1.
2.
    IF (UPDATING AND (NEW.SERVICES_HINT IS NOT DISTINCT FROM OLD.SERVICES_HINT)) THEN
        EXIT;

Поле "SERVICES_HINT" объявлено следующим образом:
Код: sql
1.
    SERVICES_HINT              COMPUTED BY ((SELECT RESULT FROM HINT$RECEIPT$SERVICES(BAT$RECEIPT$RECEIPT.ID))),



Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
CREATE OR ALTER PROCEDURE HINT$RECEIPT$SERVICES (
    ID_RECEIPT DOM$KEY NOT NULL)
RETURNS (
    RESULT D_VARCHAR_25000)
AS
BEGIN
...
END



Предполагаю, что FB не освобождает память, если в вычисляемом поле в триггере Before Update используется ХП. В триггере After Update точно такая же проверка, но потребление памяти не увеличивается.
Если описания недостаточно, могу подготовить базу для воспроизведения.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 07:08
    #39542122
dimitr
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
сегодня попробую воспроизвести. Если нужна будет база - отпишусь.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 10:54
    #39542218
dimitr
dimitr
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
таки нужен воспроизводимый пример. Такое ощущение, что проблема во внутренностях процедуры. Ибо если она пустая (возвращает константу + саспенд), то я не вижу утечки. Может там в ней временные блобы создаются?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:40
    #39542273
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
dimitr,

Да, вы правы. Не догадался сразу посмотреть. Используется SELECT с LIST(). То есть проблема с временными блобами, которая снова была озвучена здесь недавно.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:43
    #39542278
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMaxerror during savepoint backout (290)
предположу дохрена памяти в undo log. Типа, запрос обновляет 1 млн записей, триггер обновляет еще 10-100, в итоге 10-100млн обновлений, и т.д.
CyberMax SERVICES_HINT COMPUTED BY ((SELECT RESULT FROM HINT$RECEIPT$SERVICES(BAT$RECEIPT$RECEIPT.ID))),
это, конечно, просто прекрасный код. Великолепный! Пиши так дальше, везде и чаще.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:47
    #39542288
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
kdv,

ну вычисляемое поле с SELECT из ХП это ещё полбеды, а вот сравнивать вычисляемые поля в триггере уж точно изврат какой-то.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:54
    #39542300
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
Симонов Дениса вот сравнивать вычисляемые поля в триггере уж точно изврат какой-то.
Это не я писал :).
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:56
    #39542301
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
kdvэто, конечно, просто прекрасный код. Великолепный! Пиши так дальше, везде и чаще.
Мне так удобно. Никаких проблем с кодом не вижу.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 11:59
    #39542305
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMaxМне так удобно. Никаких проблем с кодом не вижу.
проблема - это запрос в вычисляемом поле. Еще хуже - вызов процедуры в вычисляемом поле.
Так можно, но это говнокод, по определению.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:00
    #39542308
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMax,

ну для меня странно собирать огромные BLOB а потом сравнивать их между собой. Это же гигантский оверхед
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:02
    #39542312
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
kdv,

Чем отличается запрос в вычисляемом поле от подзапроса прямо в SELECT, без вычисляемого поля? Ответ: ничем. Или вы против подзапросов в запросе?
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:04
    #39542316
Мимопроходящий
Мимопроходящий
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
а ТС часом не проходил стажировку в Индии?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:08
    #39542321
CyberMax
CyberMax
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
Симонов Денисну для меня странно собирать огромные BLOB а потом сравнивать их между собой. Это же гигантский оверхед
Нет никакого сбора BLOB'ов. Сравниваются два VARCHAR'а.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:14
    #39542330
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMax,

с точки зрения оптимизации ничем. Пока вычисляемое поле не используется в запросе оно не вычисляется. Другое дело, что код становится менее прозрачным.

Что касается сравнения вычисляемых полей OLD.* и NEW.* в триггерах, то у меня вообще сомнения что это работоспособно.
Код: sql
1.
NEW.SERVICES_HINT IS NOT DISTINCT FROM OLD.SERVICES_HINT


в каких случаях это выражение ложно?
1. Изменили ID
2. Каким-то непонятным образом при одном и том же ID процедура HINT$RECEIPT$SERVICES даёт разные значения. Ну это в принципе возможно. Например HINT$RECEIPT$SERVICES делает свои вычисления на основе самой таблицы BAT$RECEIPT$RECEIPT или других таблиц которые меняются в триггерах. Это дико запутывает код.
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:16
    #39542332
kdv
kdv
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMaxЧем отличается запрос в вычисляемом поле от подзапроса прямо в SELECT, без вычисляемого поля? Ответ: ничем. Или вы против подзапросов в запросе?
запрос в вычисляемом поле - это говнокод, сообщаю по опыту обследования разных систем на тему производительности.

Да, поначалу это прикольно, потому что работает "типа само", а когда база становится сложнее - происходит вот такая фигня, что "где-то тормозит", а потом выясняется, что где-то на третьем уровне вложенности вот это самое вычисляемое поле с запросом или процедурой, в которой еще запросы, которые .... и т.д.
Или, запрос без столбца А быстро работает, а запрос со столбцом А - медленно. Смотрим в столбец А, а там выборка из процедуры, которая выбирает из ... и опять же "и так далее".
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
26.10.2017, 12:16
    #39542333
Симонов Денис
Симонов Денис
Участник
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Огромное потребление памяти в FB 2.5
CyberMax,

ты сам сказал что внутри LIST используется. Т.е. вначале мы что-то агрегируем в большущий BLOB, который преобразуется в VARCHAR а затем сравнивается
...
Рейтинг: 0 / 0
| Ответить | Цитировать | Написать  
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Огромное потребление памяти в FB 2.5 / 16 сообщений из 16, страница 1 из 1
Целевая тема:
Создать новую тему:
Автор:
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
созд. / загр.: 163ms
Закрыть
start [/forum/topic.php?fid=40&mobile=1&tid=1561365]:
 0ms
get settings:
 9ms
get forum list:
 11ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 61ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 48ms
get tp. blocked users:
 2ms
others: 13ms
total:  163ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]