Форумы Интермех - Кратковременные тормоза Search 7.2sp3 451 page 0

Форумы Интермех / InterBase / Кратковременные тормоза Search 7.2sp3

Автор	Сообщение
Борис Юсуфов Участник НИИ САПФИР, Махачкала	Дата: 14 Мар 2005 17:45:24 Уже как 2 недели наблюдаем следующую ситуацию. 2-3 раза в день с непредсказуемым интервалом происходит сильное падение производительности сервера (загрузка ЦП ~100%). Думали что происходит автоматический sweep отключили авто и поставили ручной запуск по ночам. Но это не помогло. Причем могут быть дни когда это вообще не просиходит. Падение производительности продолжается ~1-3 минуты затем все восстаннавливается. Грешили на наши программы дополнения к Search проверили все скрипты в программах и длительность выполнения в них стандартных ХП Search (Get_ArtSеructure_XP) но ни одна из задач в отдельности не загружает на такое время сервер. Просьба помочь советом. Конфиг. сервер IB 6.0 2-ЦП PIII 1000 Мгц. Windows 2000 Adv Server 1Гбайт ОЗУ IDE
Дмитрий Участник НПП ИНТЕРМЕХ	Дата: 14 Мар 2005 18:42:33 А какой процесс грузит сервер? InterBase 6 при выполнении сложных запросов вполне может 100% грузить процессор даже на небольшой базе данных. И 2-ЦП ему как мертвому припарка, т.к. он не заточен на поддержку SMP.
Борис Юсуфов Участник НИИ САПФИР, Махачкала	Дата: 15 Мар 2005 07:46:25 Дмитрий А какой процесс грузит сервер? Сервер грузит именно Ibserver.exe. Дмитрий InterBase 6 при выполнении сложных запросов вполне может 100% грузить процессор даже на небольшой базе данных. И 2-ЦП ему как мертвому припарка, т.к. он не заточен на поддержку SMP. Тогда скажите какой запрос или какая команда в Search 7.2sp3 может повторить данную ситуацию. т.е. загрузить сервер под 100% чтобы я объяснил это нашим пользователям. Все команды которые на мой взгляд могли бы долго выполняться и так загружать сервер мы вроде проверили и ничего криминального вроде нет(по крайней мере так долго ни одна из них сервер не загружает). Самое интересное на тестовом сервер ничего подобного не происходит, т.е получается что данная ситуация происходит при интенсивной работе пользователей (у нас в среднем с Серчем одновременно работают ~15 юзеров). Какие будут соображения
Дмитрий Участник НПП ИНТЕРМЕХ	Дата: 15 Мар 2005 10:38:44 А если одновременно выполняются 2 длительных операции разными пользователями? А если 3? Причем время параллельного выполнения операций может быть больше суммы времен выполнения операций в однопользовательском режиме (время может расходоваться на различные блокировки ресурсов). А можно узнать сколько у Вас записей в таблицах DOCLIST, ARTICLES, PC, VARTICLES?
Борис Юсуфов Участник НИИ САПФИР, Махачкала	Дата: 15 Мар 2005 12:34:03 Дмитрий А если одновременно выполняются 2 длительных операции разными пользователями? А если 3? Причем время параллельного выполнения операций может быть больше суммы времен выполнения операций в однопользовательском режиме (время может расходоваться на различные блокировки ресурсов). А можно узнать сколько у Вас записей в таблицах DOCLIST, ARTICLES, PC, VARTICLES? Вобщем то немного: Articles - 17210 DocList - 4844 PC - 57085 V_Articles - 8724 Точно помню одно, что проблемы начались через день после установки Sp3 или это просто совпадение На базе Search4.gdb запускал IBAnalyst 1.77 говорит что в базе есть бесполезные и плохие индексы и их достаточно много. Если заинтересовало могу выслать файл. В логе IB пишет при старте Database: D:\DATABASE\SEARCH4.GDB RDB$FLAGS for trigger CHECK_39 in RDB$TRIGGERS is corrupted (304) Database: D:\DATABASE\SEARCH4.GDB RDB$FLAGS for trigger CHECK_52 in RDB$TRIGGERS is corrupted (304)
Дмитрий Участник НПП ИНТЕРМЕХ	Дата: 15 Мар 2005 15:25:03 Могло быть и совпадением. Что касается индексов, то я не представляю как какая-то программа может оценить их бесполезность (разве что есть 2 одинаковых индекса на одно поле, но серьезные СУБД не дают такие индексы создавать), а плохие индексы (если я правильно понял что значит научный термин "плохие") должна исправлять проверка базы данных. В любом случае "лишние" индексы не могут приводить к таким падениям производительности. А вот отсутствие нужных индексов - очень даже может. На лог взглянуть интересно. Если не трудно - пришлите его на cad@intermech.ru. И заодно лог InterBase.
Борис Юсуфов Участник НИИ САПФИР, Махачкала	Дата: 15 Мар 2005 16:39:33 Письмо отправлено по почте, на Ваше имя. Дмитрий а плохие индексы (если я правильно понял что значит научный термин "плохие") должна исправлять проверка базы данных. В любом случае "лишние" индексы не могут приводить к таким падениям производительности. А вот отсутствие нужных индексов - очень даже может. Вот выдержка из лога IBAnalyst Под `плохими` мы имеем в виду индексы с большим числом повторяющихся ключей (90% от всех ключей) и большими группами одинаковых ключей (30% от всех ключей). Большие группы одинаковых ключей замедляют сборку мусора - MaxEquals здесь это % самой большой группы ключей с одинаковыми значениями. Поиск по таким индексам является неэффективным. Вы можете удалить такие индексы (если это не индекс по Foreign Key)