Форум » АРМ "Клиент" АС Клиент-Сбербанк » 007.012.003 жуткие тормоза в поиске и при заведении платежек » Ответить
007.012.003 жуткие тормоза в поиске и при заведении платежек
printf: стояла версия 007.008.000 апгрейднулись до 007.012.003, далее, т.к. база ведется аж с 2003 года то некоторые номера стали двоиться и накладываться... в общем по совету из банка я произвёл архивацию базы... но после этого начались жуткие тормоза. Бухгалтер очень жалуется.... тормоза при быстром поиске платежек, и при набивании-копировании платежек. смотрел по загрузке проца - доходит до 100%. индексные файлы NDX убивал... - не помогло, архив (ARCHIVE) пробовал удалять - тож не помогло. походу дела всё именно из-за операции Архивирования.... как нить можно это вылечить?
Ответов - 48, стр:
1 2 3 All
printf: есть мысль что например после удаления записей из таблиц при архивировании, сберыч не пакует эти самые таблицы (операция упаковка таблиц как в 1С-ке с dbf-файлами), но это такие теоретические предположения..... в любом случае неплохо бы хоть какой нить вариант решения проблемы :)
Mike666: printf пишет: смотрел по загрузке проца - доходит до 100% Вот этого не должно быть. В подобном случае пробовал накатить Виндозу "обновлением" - помогает 100%. Shell32 перестаёт вести себя подобным образом и "вздувать" приоритет для К-Б.
printf: на машине стоит сразу 5 банк клиентов (доступ через модем). после архивирования на двух банк клиентов начались тормоза при поиске - ввода букв идёт посимвольно, при этом загрузка проца поднимается до 50% (2-х ядерная машина, то есть по одному ядру идёт загруз на 100%). и такие тормоза именно на 2-х клиент банках где и было сделано архивирование баз. на остальных К-Б тормозов нет.
printf: с обновлением это точно не связано, везде поставил 007,012,003 и только на двух К-Б тормоза...
admin: может реессстррр ппоччистиитььь и поновой накатить?
denis-tim: Тормоза после архивации наблюдал неоднократно на ВСЕХ версиях АРМ начиная с 07.005.00 и выше. Явный баг в процедуре. Особенно, если база платежек довольно большая (более 3000), а таких клиентов у нас довольно много...
pusska: архивацию проводим у многих клиентов, таких проблем не наблюдали.....
printf: Особенно, если база платежек довольно большая (более 3000) вот-вот, как раз наша ситуация :) провёл архивацию на 007.008.000 -- таже ботва, начинает потом тормозить. но не везде, а вот если выбрать рублевые платежки, выбрать получателя, и потом быстрый поиск -- вводишь буквы ООО и начинаются тормоза, проц грузится под 100%. Пуська - да мож ваши клиенты не жаловались просто, или платёжек очень мало.
w0rkm4n: Блин, не вижу связи. База получателей это USER.DDF - можно попробовать удалить индексы и почистить саму базу от ненужных вхождений. "Справочники - получатели" Но смущает то, что при архивации она ни коим образом не затрагивается... Возможен вариант кривого быстрого поиска, м.б. попробовать накатить последнюю версию? Сделать бэкап, накатить версию,попробовать в работе и ежели не устроит - откатить назад.
printf: я накатывал уже версию 007.012.003 поверх на 007.012.003 -- всё тож самое... поиск какой то тормозной... w0rkm4n пишет: почистить саму базу от ненужных вхождений. а что это значит? рублевые платежки не удаляются никак. до архивирования кол-ва информации было куда больше и работало всё без Тормозов. наверно надо было не Архивироваться а устанавливать новый клиент банк, а старый переименовывать и использовать только для просмотра старой инфы.
w0rkm4n: printf пишет: а что это значит? я про "почистить справочник получателей"
printf: там 580 получателей, построчно удалять времени займет много. а оптом не удаляется. а платежек 2617. чуток почистил - всё равно не помогает, какой то явный внутренний баг. прикол еще в том что если вводишь данные которых нет в поиске, то буквы-цифры вводятся быстро, тормозов нет. а если то что находит клиент-банк, то сразу поднимается загрузка проца и начинает поиск тормозит... по идее - фигня какая то, ведь поиск что так работает, что так -- не важно что ты вводишь... а тормозит тока когда инфа находится.
pusska: printf архивацию проводим только подсистемы рублевые п/п..и все! честно, никаких жалоб! встречалось пару-тройку случаев жутких тормозов (абсолютно не связанных с архивацией) при обновлении версии или при перестройке индексов справочников БИК и SWIFT, порядка 2-3 часов на это уходило...решалось просто - убиением оператора и чисткой реестра...
KYUM: printf Подтверждаю, что жалоб на тормоза КлБанка после архивации не поступало. Наоборот скорость только увеличивалась. Такое ощущение тормоза возникают из-за того, что КлБанк обращается к службам Windows. А те в свою очередь и вызывают нагрузку процессора 100%. Мне например такое представляется, когда настроена какая-то своеобразная индексация в Windows или базы в сети. Я советую заархивировать все данные не только за прошлый год, но и за этот. А потом удалить файл work.ddf (база платежек) и еще *.ddf с базой плательщиков, но какой точно не скажу, надо искать его экспериментальным путем. Тогда база получится чистая, как будто с нуля ее установили. ЗЫ 580 получателей - никогда не видел такую гигантскую базу контрагентов
printf: да, я тут провёл тестовую повторную архивацию (до 01.05.2010) вроде как помогло :), теперь стало побыстрее работать :) спасибо буду теперь бухам "начистовую делать" :)
printf: не устроило наших бухов вариант обрезания до мая... им нужен весь этот год. в итоге одна из баз клиент-банка было записей в платежных рублевых поручениях - 51849 стало записей - 2025 в итоге при поиске тормозит, и когда нажимаешь на колонке получатель - задумывается. а до архивации такого не было. и не понятное дело еще почему номера начали раньше захватываться с прошлых лет... неужели 50 тыщ записей это предел такой по номерам.
w0rkm4n: printf пишет: и не понятное дело еще почему номера начали раньше захватываться с прошлых лет... неужели 50 тыщ записей это предел такой по номерам. Поверьте, разработчики и не такое могут. Внутренний уникальный номер документа в базе формировался по примитивному методу... не будем уточнять какому, и через год уникальные номера начинают совпадать. 2 выхода. Обновляйтесь или режьте базу.
Sasha911: Доброе время суток господа и дамы:))) сегодня абсолютно с такой же проблемой столкнулись, после архивации включительно по 31.12.2009 года, пошли косяки с быстрым поиском! клиенту не обходим он просто, по дате выбирать не имеет желания! кто что еще скажет, примерно кроме наката винды уже все попробывали, ну или почти все!! буду рад любому дополнению по данной проблеме!???
Mike666: Sasha911 пишет: буду рад любому дополнению по данной проблеме!??? Отзвонитесь завтра на 8-963-279-0065 - проблема решаема.
Sasha911: Уважаемый Mike666, если информация секретна хоть в личку напиши!
полная версия страницы