Ibserver.exe грузит CPU на 99%

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 14:20

С недавних Ibserver.exe начал грузить CPU на 99%, ну и соответсвенно клиенты жалуются на тормоза.
Это происходит примерно после обеда, т.е. до обеда тормозов нет, после обеда есть.

Вот что имеем:
- Intebase 6 установлен на Windows 2000 Server. Ничего на сервере в последнее время не устанавливалось.
- 5 клиентов на Windows 2000/98
- Sweep Interval = 0
- Каждую ночь делается бэкап, gfix -sweep, иногда рестор (если база не занята)
- База вести ~300 мег
- Софт написан на Delphi 7, IBX 7.09

Раньше в приложении была одна транзакция с параметрами:
- read_committed, rec_version, nowait
ну и после Insert/Update/Delete делался CommitRetaining.

Работала эта схема 2002 года и все были довольны.

А как начало тормозить, после штудирования ibase.ru, я сделал для просмотра транзакции с параметрами
(1) read, read_committed, rec_version, nowait
а для изменения
(2) write, read_committed, rec_version, nowait

Результат: те-же тормоза.

Вот статистика, полученная IBAnalyst в момент тормозов

Код: Выделить всё

- Page size             4096 
- ODS version           10.0 
- Oldest transaction    1314 
- Oldest active         1315 
- Oldest snapshot       1315 
- Next transaction      1552 
- Bumped transaction    1 
- Sequence number       0 
- Next attachment ID    0 
- Implementation ID     16 
- Shadow count          0 
- Page buffers          0 
- Next header page      0 
- Database dialect      3 
- Creation date         Sep 6, 2006 23:53:39 
- Attributes            force write

Что делают (в основном) клиенты:
a) открывается диалоговое окно для ввода расходной с транзакцией (2)
b) заполняются номер накладной, дата и т.д., делается CommitRetainig
c) открывается форма с перечнем (DBGrid) имеющихся товаров с транзакцией (2)

d) клиент вводит нужное наименование, например "валенки", и запрос переоткрывается по таймеру с условием where Upper(Ware_Name) like '%ВАЛЕНКИ%'

Код: Выделить всё

select W.Ware_Name ...
from Wares W, Parts P
where (W.ID = P.Ware_ID)
  and (Parts.Exist_Flag=1)
  and Upper(W.Ware_Name) like '%ВАЛЕНКИ%'
order by W.Ware_Name

Вот тут то в основном тормоза и проявляются.
Раньше и до обеда все летает.
План запроса, до и во время тормозов, не меняется.

e) Клиент выбирает из списка нужный товар и вводит количество нажимает OK, делается CommitRetainig
И начиная с пункта (d) по (e) делается примерно раз 10-100

Эта операция (e)
1. добавляет запись в одну таблицу (Moves)
2. и изменят запись в другой таблице (Parts)

После того, как все товары внесены, нажимается главный OK, и пишущая транзакция (2) закрывается.
Больше пишущих транзакций открытых нет, есть только читающие (1)

Ivan_Pisarevsky

1. какой глубинный смысл CommitRetaining ?
2. что мешает перейти на фб 1.5.3 ?

запрос переоткрывается по таймеру с условием where

Upper(Ware_Name) like '%ВАЛЕНКИ%'

3. что значит фраза "запрос переоткрывается по таймеру" ?
4. что мешает хранить в БД копию поля уже в состоянии аппер, заполняяя его триггером и затем искать при помощи индекса по этому полю? или процентик в начале нужен всенепременнейше?

5. какой кэш пейджес в конфиге выставлен?

CyberMax · Сообщение **CyberMax** » 08 сен 2006, 14:57

Ivan_Pisarevsky писал(а):1. какой глубинный смысл CommitRetaining?

В IBX только одна транзакция, поэтому Commit приводит к закрытию набора. Чтобы его после этого не переоткрывать, и юзается CommitRetaining. Это одна из причин переходить на FIB+

.
Ну и с учетом использования IB6 проблемы неудивительны...

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 15:11

Ivan_Pisarevsky писал(а):1. какой глубинный смысл CommitRetaining ?

Потому как у IBDataSet'а нет UpdateTransaction.
Софт написан давно, и переделывать на чистый Commit или переходить на FIBы - проблематично.

Ivan_Pisarevsky писал(а):2. что мешает перейти на фб 1.5.3 ?

Хочется обойтись малой кровь, на серваке крутится еще куча прог.

Ivan_Pisarevsky писал(а):>запрос переоткрывается по таймеру с условием where Upper(Ware_Name) like '%ВАЛЕНКИ%'
3. что значит фраза "запрос переоткрывается по таймеру" ?

- пользователь ввел "валенки"
- зажмурил глаза
- через 350 милисек открыл
- в списке только "валенки"

т.е. при вводе наименования, как только после ввода последнего символа проходит 350 мс
в запрос добавляется условие
- Upper(Ware_Name) like '%ВАЛЕНКИ%'
и он переоткрывается.

Ivan_Pisarevsky писал(а):4. что мешает хранить в БД копию поля уже в состоянии аппер, заполняяя его триггером и затем искать при помощи индекса по этому полю? или процентик в начале нужен всенепременнейше?

Нужен, т.к. если пользователь вводит "валенки прорезиненные" то должны отфильтроваться
- валенки прорезиненные
- прорезиненные валенки
- суперпрорезиненные валенки

Ivan_Pisarevsky писал(а):5. какой кэш пейджес в конфиге выставлен?

DATABASE_CACHE_PAGES 10000

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 15:20

CyberMax писал(а):Ну и с учетом использования IB6 проблемы неудивительны...

Т.е. Вы считает, что тормоза из-за IB6?

Merlin · Сообщение **Merlin** » 08 сен 2006, 15:21

Sikambr писал(а): - пользователь ввел "валенки"
- зажмурил глаза
- через 350 милисек открыл
- в списке только "валенки"

Этта крутта. При наличии хотя бы одного пользователя - эстонца запрос переоткрывается после ввода каждой буквы

А если их 2 или 3... А чего бы, скажем, не повесить переоткрытие на нажатие Ентер? Раз уж кнопучка "Искать" неприемлема по религиозно-эстетическим соображениям?

Sikambr писал(а): DATABASE_CACHE_PAGES 10000

Для шестёрки многовато.

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 15:33

Merlin писал(а):
Sikambr писал(а): - пользователь ввел "валенки"
- зажмурил глаза
- через 350 милисек открыл
- в списке только "валенки"
Этта крутта. При наличии хотя бы одного пользователя - эстонца запрос переоткрывается после ввода каждой буквы А если их 2 или 3... А чего бы, скажем, не повесить переоткрытие на нажатие Ентер? Раз уж кнопучка "Искать" неприемлема по религиозно-эстетическим соображениям?

Операторы вводят наименования быстро, не глядя на клаву.

Merlin писал(а):
Sikambr писал(а): DATABASE_CACHE_PAGES 10000
Для шестёрки многовато.

А сколь нужно выставить?

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 15:49

e) Клиент выбирает из списка нужный товар и вводит количество нажимает OK, делается CommitRetainig
И начиная с пункта (d) по (e) делается примерно раз 10-100

Эта операция (e)
1. добавляет запись в одну таблицу (Moves)
2. изменят запись в другой таблице (Parts)

У меня такое подозрение, что тормоза из-за частых изменений таблицы Parts, т.е. сколько товаров добавили в расход, столько и произошло изменений в таблице Parts, а версии записей плодятся.
А чтобы получить список имеющихся в наличии товаров, как-раз читается таблица Parts.
Что скажете?

Merlin · Сообщение **Merlin** » 08 сен 2006, 16:01

Sikambr писал(а):
Merlin писал(а):
Sikambr писал(а): DATABASE_CACHE_PAGES 10000
Для шестёрки многовато.
А сколь нужно выставить?

А ХЗ. Помню смутно что говорили о её тормозах на Винде начиная именно с этой волшебной цифры. Попробуй 8. Но думаю что главная проблема не в этом. Там не может после обеда какой-нить босс отчёты начинать гонять?

CyberMax · Сообщение **CyberMax** » 08 сен 2006, 16:03

Попробуй воспользоваться BT SQL Monitor'ом. Он покажет, над чем сервер задумывается.

Код: Выделить всё

Т.е. Вы считает, что тормоза из-за IB6?

Это одна из причин. IB6 сам по себе очень глючен. И почему именно он? Firebird же тоже бесплатен... Плюс куча фичек, отсутствующих в шестерке. Об это писано уже тысячу раз...

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 16:05

Merlin писал(а):
Sikambr писал(а):
Merlin писал(а):
Sikambr писал(а): DATABASE_CACHE_PAGES 10000
Для шестёрки многовато.
А сколь нужно выставить?
А ХЗ. Помню смутно что говорили о её тормозах на Винде начиная именно с этой волшебной цифры. Попробуй 8. Но думаю что главная проблема не в этом. Там не может после обеда какой-нить босс отчёты начинать гонять?

Я читал, что значание более 10000 нежелательно.
Насчет отчетов - точно нет.

Merlin · Сообщение **Merlin** » 08 сен 2006, 16:06

Sikambr писал(а): У меня такое подозрение, что тормоза из-за частых изменений таблицы Parts, т.е. сколько товаров добавили в расход, столько и произошло изменений в таблице Parts, а версии записей плодятся.
А чтобы получить список имеющихся в наличии товаров, как-раз читается таблица Parts.
Что скажете?

Скажу - возьми IBAnalyst и проверь...

hvlad · Сообщение **hvlad** » 08 сен 2006, 16:07

Sikambr писал(а):
e) Клиент выбирает из списка нужный товар и вводит количество нажимает OK, делается CommitRetainig
И начиная с пункта (d) по (e) делается примерно раз 10-100

Эта операция (e)
1. добавляет запись в одну таблицу (Moves)
2. изменят запись в другой таблице (Parts)
У меня такое подозрение, что тормоза из-за частых изменений таблицы Parts, т.е. сколько товаров добавили в расход, столько и произошло изменений в таблице Parts, а версии записей плодятся.
А чтобы получить список имеющихся в наличии товаров, как-раз читается таблица Parts.
Что скажете?

gstat -r -t PARTS скажет
Но не с IB6

Sikambr · Сообщение **Sikambr** » 08 сен 2006, 16:14

CyberMax писал(а):Попробуй воспользоваться BT SQL Monitor'ом. Он покажет, над чем сервер задумывается.

BT SQL Monitor'ом = IBTM?

CyberMax писал(а):
Код: Выделить всё
Т.е. Вы считает, что тормоза из-за IB6?
Это одна из причин. IB6 сам по себе очень глючен. И почему именно он? Firebird же тоже бесплатен... Плюс куча фичек, отсутствующих в шестерке. Об это писано уже тысячу раз...

Система делалась в 2002 году.

CyberMax · Сообщение **CyberMax** » 08 сен 2006, 16:28

Sikambr писал(а):BT SQL Monitor'ом = IBTM?

Нет. Вот ссылка: http://www.devrace.com/files/bt_sqlmonitor.zip
Только проверь, чтобы в твоей TIBDatabase были включены TraceFlags.

Sikambr писал(а):Система делалась в 2002 году.

Firebird появился в 2000 году...

Замечание Sikambr. Не надо вложенных цитат. Достаточно процитировать конкретную фразу.

Сообщение **kdv** » 08 сен 2006, 20:37

Firebird появился в 2000 году...

первая версия вышла не в 2000 году.
это ib6 появился в середине 2000 года, а FB 1 был выпущен примерно в середине 2001 года, если я правильно помню.
В любом случае это было минимум 5 лет назад.

социологический опрос: Sikambr, вы как 6 лет назад IB 6 скачали, так ее и используете, не глядя на появление новых версий IB/FB? Или недавно где-то добыли IB 6? Если не секрет - где?

Sikambr · Сообщение **Sikambr** » 11 сен 2006, 06:50

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

Чтобы не создалось впечатления, что я безнадежно отстал, скажу:
- на основной работе я использую IB7.1 sp2, размер базы ~10 гиг и кол-во одновременных коннектов 50-80
- месяца 3 назад был закончен проект на FB2

Есть несколько причин, по которым я не хочу переходить на более свежий Interbase или Firebird в фирме X.
Но я не буду их описывать, т.к. боюсь начнется их обсуждение.

Если выяснится, что оставаясь на IB6, тормозов не избежать, то соответственно будут думать о переходе на более свежий IB или FB.

Сообщение **kdv** » 11 сен 2006, 09:20

Есть несколько причин, по которым я не хочу переходить на более свежий Interbase или Firebird в фирме X.
Но я не буду их описывать, т.к. боюсь начнется их обсуждение.

и на том спасибо.

Если выяснится, что оставаясь на IB6, тормозов не избежать, то соответственно будут думать о переходе на более свежий IB или FB.

судя по статистике и остальному основная причина тормозов в commitretaining. Думаю, можно даже туда поставить ibtm, но глядя на статистику с -r тоже будет ясно.

Ivan_Pisarevsky

Sikambr писал(а):Это происходит примерно после обеда, т.е. до обеда тормозов нет, после обеда есть.

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

Sikambr · Сообщение **Sikambr** » 14 сен 2006, 06:40

Ivan_Pisarevsky писал(а):...выходить из программы-клиента, на сервере же по крону делать свип во время обеда.

Так и сделал. Заработало. Спасибо.

iBase.ru Forum

Ibserver.exe грузит CPU на 99%

Ibserver.exe грузит CPU на 99%

Re: Ibserver.exe грузит CPU на 99%

Re: Ibserver.exe грузит CPU на 99%

Re: Ibserver.exe грузит CPU на 99%

Re: Ibserver.exe грузит CPU на 99%

Re: Ibserver.exe грузит CPU на 99%