Форум » АРМ "Клиент" АС Клиент-Сбербанк » 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, если информация секретна хоть в личку напиши!
Sasha911: господа есть еще кто живой?:) ну все испробовали ! кроме наката винды естественно !!
Mike666: Ну, в добавок ко всему сегодня сказанному, Есть ещё такие варианты: Ещё раз (после сохранения базы) поставить с инсталляхи (можно не один раз). Сам таким способом не пользуюсь, потому что делаю свои "апдейты". Можно "сурово" (если есть возможность) - скопировать программу на флэху, сделать "системный откат" дней на 10-ть назад (узнать, где хранятся азхивы от 1С). Всё будет так же лихо работать, проверено. А затем тупо скопировать каталоги Archiv и Base. Если было обновление программы, то запустить и прогнать Configwc.exe.
sb77: Зачем такие сложности? Может быть стоит начать с удаления файлов индексов (*.ndx)
Mike666: Они уже пробовали - не помогло. Я к чему веду - К-Б использует в бОльшей степени средства Windows, своего у него почти ничего нет, потому и действовать нужно теми же способами. База "коряво" закрылась - откат убирает из реестра все предупреждения об этом событии.
Mrmixxx: Сегодня столкнулся с такой-же проблемой, перенес даже домой базу, и опять тормоза. Помогите!!!!!!!
admin: Mrmixxx, опишите подробнее... с чего все началось, когда проявилось...
Mrmixxx: Пришел к лиенту, сделал архивацию 2009 года. После этого при быстром поиске платежки начинаются жуткие тормоза, проц до 100%, платежек около 2000. Вернул из бекапа work.ddf. Поиск работает быстро, архивирую - опять тормоза. Забрал базу доой, поставил с нуля, подложил только work, тормоза...
admin: Версия 012.03 или 012.05?
Mrmixxx: 012.03, также пробовал 070600, 070900
Mrmixxx: ошибся была версия при архивировании 012.05
admin: подождите, т.е. на версии 07.006.00 тоже тормоза? Что-то как-то грустно... отправил ЛС...
Mike666: Есть несколько "ненормальное" предложение: после архивирования снять принудительно со всех файлов в базе все атрибуты ("скрытый", "системный", "архивный", "только для чтения" - просто тупо снять), удалить все индексные файлы (*.ndx), не создавая никакого запроса, просто провести сеанс связи. А потом попробовать "поиск".
Mrmixxx: Сегодня появилась идея: откатить нормальный бекап на 07.009.00, урезать, а потом опять обновть до 07.012. Завтра попробую, напишу
admin: решил возобновить тему... Обратился Клиент - версия АРМ 07.012.05 - усекли БД до 01/01/2011, после сего действия - "жуткие тормоза" при поиске п/п в подсистеме рублевые п/п... Что пробовал... 1. На другом компе - нет эффекта. 2. Удаление индексов из BASE - - нет эффекта 3. откат на версию 07.006.00 - нет эффекта 4. Откат на версию 07.004.01 - нет эффекта 5. Установка 07.014.02 - нет эффекта 6. Установка 07.015.00 - нет эффекта 7. откат на версию 07.003.00 - все просто летает... обалдеть... 8. установка поверх 07.003.00 свежей версии - нет эффекта, все тормозит... 9. попытка усечения БД на версии 07.003.00 и обновление до 07.012.05 - нет эффекта просмотр work.ddf утилиткой из 15 версии, показывает красивую табличку со всеми п/п без пустот... Вопрос - что делать??? 07.003.00 - не серьезно совсем... парни - help... З.Ы. k-nick - на вас выставлю запрос завтра... :(
ZhooChee: admin пишет: 1. На другом компе - нет эффекта Вот была когда-то у меня обычная почтовая база под Outlook Express, и в какой-то момент начались ну дикие тормоза при открытии почтовых папок. И сжимал базу, и папку с базой на другой диск переносил - ничего не помогало. В итоге оказалось виноват антивирус, воткнул папку с базами в список исключений - и стало хорошо. Это я к тому, что в контенте work.ddf (а скорее в work.ndx) могут быть совершенно случайные сигнатуры, вызывающие "стояк" у эвристики антивируса. И возникла эта сигнатура недавно (в смысле даты документа), тогда когда клиент обратился - поэтому обрезание проблему не решает, т.к. недавние документы остаются в work.ddf Поэтому предложу эксперимент: - архивные помесячные "нарезки" work.ddf у вас есть (ну или архивируем базу) - заменяем work.ddf на любой из этих месячных "кусков" - проверяем скорость поиска
u14was: А не проще ли (в порядке эксперимента) отключить антивирус? И проверить эту догадку...
admin: Ребята... у Клиента NOD 32, на работе Kasper, дома пусто - везде висит... т.е. предположение, что все таки не антивирь... с восстановлением месячного архива можно даже не экспериментировать (хотя щас попробую) - суть - в архиве п/п будет немного... у клиента с начала года почти 3 тысячи п/п - в архиве не более 300 - следовательно работать будет быстрее... :(
admin: что и требовалось доказать - в архиве за месяц - около 30 п/п - работает до не приличия быстро...
ZhooChee: А не проще ли отключить антивирус? На такие грабли несколько раз наступал, стопроцентная остановка антивируса - это его деинсталляция admin, а как насчет параметра ПОЛНЫЕ_ИНДЕКСЫ=0 ? ЗЫ. Отключить в Винде службу индексирования, с папки BASE снять атрибут "Разрешить индексирование" ? Перекинуть базы на раздел с FAT32 вместо NTFS ?
admin: ZhooChee пишет: admin, а как насчет параметра ПОЛНЫЕ_ИНДЕКСЫ=0 ? старшие коллеги сказали, что нифига не прокатывает.... опять со слов старших коллег - такая "байда", только с подсистемой рублевые п/п... ZhooChee пишет: Перекинуть базы на раздел с FAT32 вместо NTFS ? ну это уж из области научно фантастики... Эксперимент провел еще один: исходные данные: АРМ 07.015.00. БД из 30 - 40 п/п. поиск по получателю в БД рублевые п/п проходит быстро (оговорюсь как делается поиск - щелкаем на получателей - все сортируется - щелкаем на черный треугольник рядом с расширенным поиском и выбираем поиск внутри строки - в поле поиска вводим какое-нить длинное слово). Архивация БД никогда не производилась! Цель: создать в БД несколько сотен п/п и проверить поиск на предмет тормозов Результат: хрень полная... хитрым способом (загрузка из внешнего файла, стандартной операцией импорта из 1С) создал порядка 7 сотен п/п... т.е. на тот момент в БД было чуть менее 8-ми сотен п/п... и вот тут самое интересное - тупить при поиске стал безбожно... Вывод: Дело не в архивации БД. Дело в кривой процедуре поиска, ибо на версии 07.003.00 веСЧь работает безупречно и крайне быстро. Послесловие: Ребята, кто может подбить статистику - т.е. у кого из Клиентов есть более 700 п/п в рублевых или есть модель, где не делали усечение проведите эксперимент с поиском - будет ли "тупить", т.е. набор длинного слова в поиске будет происходит так - вводим на клаве слово, а в строке поиска все появляется медленно и по букавкам... Буду признателен...
onyx301: У меня версия 07.012.05, до архивации поиск работает быстро, ни чего не тормозило, после того как сделал архивацию, поиск начал тормозить, при вводе большого слова появляется по букве. В связи с тем, вернули бэкап, который делали до архивации и все вернулось как и было, т.е. работает все быстро. Мне кажется, что поиск тут не причем...
admin: Может у меня на компе много разных моделей... х.з. - но я взял чистую модель и импортировал туда кучу платежек (около 800 всего) торможение есть... т.е. архивация не причем...
admin: onyx301, а архивацию, т.е. усечение делали только рублевых или всей кухни?
onyx301: admin пишет: onyx301, а архивацию, т.е. усечение делали только рублевых или всей кухни? "Делали по всей кухне". Просто если делать не по "всей кухне" в КБ появляются тормоза при входе и обработке данных.
admin: onyx301 пишет: "Делали по всей кухне". Просто если делать не по "всей кухне" в КБ появляются тормоза при входе и обработке данных. т.е. утверждение - если усекаем БД, то сечем все подсистемы без разбора - верно? Надо попробовать завтра на модели... может все таки поиск ускорится...
Zarin: У нас до сегодняшнего дня некоторые Клиенты тоже жаловались, что после усечения БД (только платежки) начинаются тормоза во всей подсистеме "Рублевые платежные поручения". Но то ли Клиенты были мелкие, то ли операций особо по нам не проходило - в общем особого резонанса все это не получило. Однако сегодня обратился наш "гигант". Им просто катастрофически необходимо набирать платежки именно в КлСб. А у них после усечения БД (только платежки) происходит следующее: набрали документ, нажали сохранить ... пьем чай ... документ сохранился, нажали "закрыть" ... пьем чай, курим, допиваем чай... набираем следующий документ. Сегодня видел все это своими глазами. По рекомендации ТБ пробовал чистить системный ТЕМП, пото перенастроил вообще на С:\ТЕМП, переносил на другой компьютер, удалял скрипты из Базы и накатывал 07.14.02 по новой, убивал Архив... Ничего не помогло. Если подобную проблему кто то уже решил - подскажите решение.
tovami: Zarin Я пробовал после такого "явления" усекать дальше, по одному месяцу, после каждого усечения инсталлировался поверх. Где то через три - четыре усечения тормоза ушли. Да, перед этим автоматически реестр зачистил.
sk12: Прошло много времени с момента последнего поста в этой теме... Наступили на те же грабли, версия 07.015.01_45. Организация большая, поэтому тормоза как описано у Zarin выше, нажал кнопочку - покурил, еще раз нажал, чай попил и т.д. Кто нибудь нашел решение проблемы?
полная версия страницы