http://tracker.firebirdsql.org/browse/CORE-1477
Любопытно, когда я его добавлял, дата в JIRA съехала на 19/Mar/07
Теперь он глубоко внизу :)
--
С уважением, Евгений
Кузнецов Евгений wrote:
http://tracker.firebirdsql.org/browse/CORE-1477
Воспроизвел, спасибо. Я вижу три проблемы:
1) почему пик 700МБ вместо 350МБ
потому что в конце запроса undo-лог копируется с текущего сейвпойнта на
предыдущий, в результате на короткий момент времени имеем две копии
Доброго времени суток!
To Vlad Khorsun
Сегодня постараюсь поместить IR в трекер.
По поводу первого случая - Вам еще это интересно? 36/17 достаточно ли
или надо еще покрутить?
С уважением, Евгений
Кузнецов Евгений ...
Доброго времени суток!
To Vlad Khorsun
Сегодня постараюсь поместить IR в трекер.
Ок
По поводу первого случая - Вам еще это интересно? 36/17 достаточно ли
или надо еще покрутить?
Извини, я пока занят более срочными вещами и больше не смотрел в эту сторону.
При
On 25 сент, 17:46, Vlad Khorsun [EMAIL PROTECTED] wrote:
Извини, я пока занят более срочными вещами и больше не смотрел в эту
сторону.
Ок :)
При каких обстоятельствах память растёт до 36МБ и не возвращается по коммиту ?
Нужно добавить еще одно дополнительное поле даты, построить по
Кузнецов Евгений ...
On 25 сент, 17:46, Vlad Khorsun wrote:
При каких обстоятельствах память растёт до 36МБ и не возвращается по коммиту ?
Нужно добавить еще одно дополнительное поле даты, построить по нему
индекс и включить условие по дате в where для всех update. Вроде бы
потребляемая
Hello, Евгений!
Кузнецов Евгений wrote:
При каких обстоятельствах память растёт до 36МБ и не возвращается по коммиту ?
Нужно добавить еще одно дополнительное поле даты, построить по нему
индекс и включить условие по дате в where для всех update. Вроде бы
потребляемая память с ростом числа
On 25 сент, 18:33, Vlad Khorsun [EMAIL PROTECTED] wrote:
Растёт однократно ? Тогда это скорее всего битмап, используемый при
индексном поиске. Его память отдаётся назад в общий пул процесса. Хотя
многовато для битмапа...
Вполне может быть - индексы там не очень хорошие. Есть ли
Доброго времени суток!
Vlad Khorsun wrote:
Сегодня постараюсь поместить IR в трекер.
Ок
http://tracker.firebirdsql.org/browse/CORE-1477
С уважением, Евгений
Доброго времени суток!
On 23 сент, 00:50, Oleg LOA [EMAIL PROTECTED] wrote:
P.S. Заведи SR в трекере, может кто и займётся
А что такое SR - service request?
В любом случае на трекер лучше сначала получить благословение :) всех
заинтересованных сторон.
С уважением, Евгений
Доброго времени суток!
On 23 сент, 01:00, Vlad Khorsun [EMAIL PROTECTED] wrote:
На первый взгляд : 350МБ уходит под анду-лог (1млн записей по 280 байт +
накл.
расходы).
Спасибо.
Значит, он отводит под VARCHAR(255) столько же, сколько и под
CHAR(255)+2 - для ускорения операций?
Вторые
Vlad Khorsun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
На первый взгляд : 350МБ уходит под анду-лог (1млн записей по 280 байт +
накл.
расходы). Вторые 350МБ, похоже, уходят под его копию во время
VIO_verb_cleanup,
(я давно хотел пооптимизировать verb_post в этом плане, но
Кузнецов Евгений [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
А что такое SR - service request?
Угу он потом должен породить change request, кторый породит code review после
которого ok to merge, а потом будет новый rebaseline :-):-):-)
Oleg LOA ...
Vlad Khorsun ...
На первый взгляд : 350МБ уходит под анду-лог (1млн записей по 280 байт + накл.
расходы). Вторые 350МБ, похоже, уходят под его копию во время VIO_verb_cleanup,
(я давно хотел пооптимизировать verb_post в этом плане, но всё руки не доходят)
А сливать это во
On 23 сент, 11:24, Vlad Khorsun [EMAIL PROTECTED] wrote:
Да. Запись в памяти хранится в фиксированном формате.
Любопытно, а как выкручиваются те, у кого VARCHAR(32000) или
BLOB.
Подтверждения первому вопросу (невозврат памяти даже по коммиту) я пока не
видел
??? Не воспроизводится?
Кузнецов Евгений ...
On 23 сент, 11:24, Vlad Khorsun :
Да. Запись в памяти хранится в фиксированном формате.
Любопытно, а как выкручиваются те, у кого VARCHAR(32000) или
BLOB.
А что - повторные апдейты миллиона жирных варчаров случаются сплошь и
рядом ? :) Блобы не есть часть записи
On 23 сент, 11:44, Vlad Khorsun [EMAIL PROTECTED] wrote:
А что - повторные апдейты миллиона жирных варчаров случаются сплошь и
рядом ? :) Блобы не есть часть записи и живут в основном в страничном кеше.
В том и дело, что VARCHAR никто не изменял - поэтому даже 350 для undo-
log,
мне
To Vlad Khorsun
Дополнение - и первую, и вторую ситуации вроде бы можно воспроизвести
по log1.txt в составе архива
С уважением, Евгений
Кузнецов Евгений ...
On 23 сент, 11:44, Vlad Khorsun wrote:
А что - повторные апдейты миллиона жирных варчаров случаются сплошь и
рядом ? :) Блобы не есть часть записи и живут в основном в страничном кеше.
В том и дело, что VARCHAR никто не изменял - поэтому даже 350 для undo-
log,
мне
On 23 сент, 12:57, Vlad Khorsun [EMAIL PROTECTED] wrote:
Могу повторить - в памяти записи хранятся в распакованном формате
фиксированной длины
Здесь мне надо подумать, еще раз статьи почитать. Вопрошу еще попозже.
Если ты про однократный рост с 17МБ до 21МБ, то никакой утечки тут нет,
Кузнецов Евгений ...
Если ты про однократный рост с 17МБ до 21МБ, то никакой утечки тут нет,
это абсолютно нормально
А сколько тогда ненормально? Вроде ж Вы говорили в начале ветки, что
этого хватит.
Процессу кушать нужно ? Вот он отъел немного, положил за щёку и жуёт
потихоньку - то
On 23 сент, 13:38, Vlad Khorsun [EMAIL PROTECTED] wrote:
Процессу кушать нужно ? Вот он отъел немного, положил за щёку и жуёт
потихоньку - то проглотит, то назад (в за щёку) выплюнет ;)
А я думал, там военный коммунизм :)
Ненормально - это десятки мегабайт
Кажется, удалось добиться 36
Доброго времени суток!
Khorsun Vlad wrote:
но при повторном вызове в одной транзакции FB в пике
потребляет до 700 Мб
Это нормально - undo-log не святым духом питается. Оно же
возвращается по коммиту.
Сижу теперь и думаю - а почему undo-log столько занял, если сама БД
была существенно
Кузнецов Евгений [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Доброго времени суток!
Khorsun Vlad wrote:
но при повторном вызове в одной транзакции FB в пике
потребляет до 700 Мб
Это нормально - undo-log не святым духом питается. Оно же
возвращается по коммиту.
Сижу
Oleg LOA wrote:
Э это нужно смотреть как память используется.
Гм, а как она может использоваться?
Я делал неоднократные массовые update (см. пост 17.09.2007 11:35 и
продолжение от 17.09.2007 14:20), естественно, память ушла под
undo_log оператора.
Вопрос - что содержится в undo-log? Даже
Oleg LOA ...
Кузнецов Евгений ...
Вопрос - что содержится в undo-log? Даже если бы он содержал
старые версии записей целиком с выравниваниями, неужели он мог бы
занимать в несколько раз больше, чем сама БД?
Вот я и говрю - смотреть как и что используется, оптимизировать в конце концов.
P.S.
Доброго времени суток!
On 17 сент, 14:45, Khorsun Vlad [EMAIL PROTECTED] wrote:
Вечером буду смотреть
Удалось что-нибудь выяснить?
С уважением, Евгений
Кузнецов Евгений ...
Доброго времени суток!
On 17 сент, 14:45, Khorsun Vlad :
Вечером буду смотреть
Удалось что-нибудь выяснить?
Пока нет, ибо ещё не вечер :)
--
Хорсун Влад
Доброго времени суток!
Обнаружил, что после выполнения одной из процедур сервер (Windows
2000, CS, 1-й dialect, FW OFF) не освобождает память. В процедуре
выполняется update всей таблицы и после него повторные
непересекающиеся update (думаю, я это переделаю, но пока так)
Получаем
Start
Кузнецов Евгений ...
Обратите внимание на величину CurrentMemory - она не изменяется ни
после выполнения процедуры, ни после завершения транзакции. Это
нормально?
Нет
(Если нужен воспроизводимый пример, то чуть попозже).
Нужен
Если все update в процедуре формировать динамически,
Доброго времени суток!
On 17 сент, 10:40, Khorsun Vlad wrote:
Кузнецов Евгений ...
(Если нужен воспроизводимый пример, то чуть попозже).
Нужен
Думаю, сегодня будет. Куда отсылать?
А на 2.0.1 это воспроизводится ?
Да, все то же самое. Наверное, никто не занимается такими
Вот, что получается на кошках
Start Transaction:
consistency
no_auto_undo
nowait
select * from rdb$database
PLAN (RDB$DATABASE NATURAL)
-Statistics-
Reads = 0
Writes = 0
Fetches = 53
Marks = 0
CurrentMemory = 17028548
MaxMemory = 17155676
NumBuffers = 1000
-Detail statistics-
Кузнецов Евгений ...
Доброго времени суток!
On 17 сент, 10:40, Khorsun Vlad wrote:
Кузнецов Евгений ...
(Если нужен воспроизводимый пример, то чуть попозже).
Нужен
Думаю, сегодня будет. Куда отсылать?
Как обычно - в Простоквашино дяде Фёдору ;)
(hvlad at users sourceforge
Кузнецов Евгений ...
21 мб против 17 в начале - этого хватит?
Должно хватить
--
Хорсун Влад
Кузнецов Евгений ...
21 мб против 17 в начале - этого хватит?
В догонку - а при повторных вызовах процедуры память
продолжает течь или остаётся 21МБ ?
--
Хорсун Влад
On 17 сент, 12:09, Khorsun Vlad [EMAIL PROTECTED] wrote:
Кузнецов Евгений ...
21 мб против 17 в начале - этого хватит?
В догонку - а при повторных вызовах процедуры память
продолжает течь или остаётся 21МБ ?
Вроде бы нет, но при повторном вызове в одной транзакции FB в пике
потребляет
Кузнецов Евгений ...
On 17 сент, 12:09, Khorsun Vlad
Кузнецов Евгений ...
21 мб против 17 в начале - этого хватит?
В догонку - а при повторных вызовах процедуры память
продолжает течь или остаётся 21МБ ?
Вроде бы нет,
Тогда это вряд ли утечка... но посмотреть на неё
On 17 сент, 14:45, Khorsun Vlad [EMAIL PROTECTED] wrote:
Это нормально - undo-log не святым духом питается. Оно же
возвращается по коммиту.
А no_auto_undo отключать undo-log не должен?
Вечером буду смотреть
Спасибо, будем ждать.
С уважением, Евгений.
Кузнецов Евгений wrote:
А no_auto_undo отключать undo-log не должен?
Нет, конечно. Иначе как гарантировать атомарность оператора.
--
Дмитрий Еманов
Доброго времени суток!
On 17 сент, 14:52, Dmitry Yemanov [EMAIL PROTECTED] wrote:
Кузнецов Евгений wrote:
А no_auto_undo отключать undo-log не должен?
Нет, конечно. Иначе как гарантировать атомарность оператора.
А аналог NO SAVEPOINT в FB не планируется?
С уважением, Евгений.
Кузнецов Евгений wrote:
А аналог NO SAVEPOINT в FB не планируется?
Мной - нет :-) За остальных не скажу. IMHO, это из серии dirty reads -
сделать несложно, но мало кому реально надо.
--
Дмитрий Еманов
On 17 сент, 15:14, Dmitry Yemanov [EMAIL PROTECTED] wrote:
Кузнецов Евгений wrote:
А аналог NO SAVEPOINT в FB не планируется?
Мной - нет :-) За остальных не скажу. IMHO, это из серии dirty reads -
сделать несложно, но мало кому реально надо.
И консерватории противоречит? :)
Кстати, а для
Кузнецов Евгений wrote:
Кстати, а для ES undo-log работает?
Да, конечно.
Когда тестировал, обратил внимание на следующее - при выполнении ES
Mem usage подскакивает до 100 Мб, сразу же после него замеряем
использование памяти процессом через UDF - 30.
Это при no_auto_undo или как?
--
On 17 сент, 16:26, Dmitry Yemanov [EMAIL PROTECTED] wrote:
Когда тестировал, обратил внимание на следующее - при выполнении ES
Mem usage подскакивает до 100 Мб, сразу же после него замеряем
использование памяти процессом через UDF - 30.
Это при no_auto_undo или как?
Да, с ним. А, то есть
Кузнецов Евгений wrote:
А, то есть no_auto_undo отключает undo-log уровня транзакции,
и если statement успешно выполнился, то undo-log statement'а грохается
и все?
Так точно.
--
Дмитрий Еманов
45 matches
Mail list logo
