ReSQL.ru
     
powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / Огромное потребление памяти в FB 2.5
16 сообщений из 16, страница 1 из 1
Огромное потребление памяти в FB 2.5
    #39542118
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
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, 05:07
| Ответить | Цитировать | Написать  
Огромное потребление памяти в FB 2.5
    #39542122
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
сегодня попробую воспроизвести. Если нужна будет база - отпишусь.
...
Рейтинг: 0 / 0
26.10.2017, 07:08
| Ответить | Цитировать | Написать  
Огромное потребление памяти в FB 2.5
    #39542218
dimitr
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
dimitr
Участник
таки нужен воспроизводимый пример. Такое ощущение, что проблема во внутренностях процедуры. Ибо если она пустая (возвращает константу + саспенд), то я не вижу утечки. Может там в ней временные блобы создаются?
...
Рейтинг: 0 / 0
26.10.2017, 10:54
| Ответить | Цитировать | Написать  
Огромное потребление памяти в FB 2.5
    #39542273
Фотография CyberMax
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
CyberMax
Участник
dimitr,

Да, вы правы. Не догадался сразу посмотреть. Используется SELECT с LIST(). То есть проблема с временными блобами, которая снова была озвучена здесь недавно.
...
Рейтинг: 0 / 0
26.10.2017, 11:40
| Ответить | Цитировать | Написать  
Огромное потребление памяти в FB 2.5
    #39542278
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
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:43
| Ответить | Цитировать | Написать  
Огромное потребление памяти в FB 2.5
    #39542288
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
kdv,

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

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

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

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

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


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