Отправлено: 07.06.10 13:04. Заголовок: 007.012.003 жуткие тормоза в поиске и при заведении платежек

стояла версия 007.008.000
апгрейднулись до 007.012.003, далее, т.к. база ведется аж с 2003 года то некоторые номера стали двоиться и накладываться... в общем по совету из банка я произвёл архивацию базы... но после этого начались жуткие тормоза. Бухгалтер очень жалуется....
тормоза при быстром поиске платежек, и при набивании-копировании платежек.
смотрел по загрузке проца - доходит до 100%.
индексные файлы NDX убивал... - не помогло,
архив (ARCHIVE) пробовал удалять - тож не помогло.
походу дела всё именно из-за операции Архивирования....

как нить можно это вылечить?

 Отправлено: 07.06.10 13:08. Заголовок: есть мысль что напри..

есть мысль что например после удаления записей из таблиц при архивировании, сберыч не пакует эти самые таблицы (операция упаковка таблиц как в 1С-ке с dbf-файлами), но это такие теоретические предположения.....

в любом случае неплохо бы хоть какой нить вариант решения проблемы :)

 Отправлено: 07.06.10 15:30. Заголовок: printf пишет: смотр..

printf пишет:

цитата:

смотрел по загрузке проца - доходит до 100%

Вот этого не должно быть. В подобном случае пробовал накатить Виндозу "обновлением" - помогает 100%. Shell32 перестаёт вести себя подобным образом и "вздувать" приоритет для К-Б.

 Отправлено: 08.06.10 09:01. Заголовок: на машине стоит сраз..

на машине стоит сразу 5 банк клиентов (доступ через модем).
после архивирования на двух банк клиентов начались тормоза при поиске - ввода букв идёт посимвольно, при этом загрузка проца поднимается до 50% (2-х ядерная машина, то есть по одному ядру идёт загруз на 100%).
и такие тормоза именно на 2-х клиент банках где и было сделано архивирование баз.
на остальных К-Б тормозов нет.

 Отправлено: 08.06.10 09:02. Заголовок: с обновлением это то..

с обновлением это точно не связано, везде поставил 007,012,003 и только на двух К-Б тормоза...

 Отправлено: 08.06.10 20:12. Заголовок: может реессстррр п..

может реессстррр ппоччистиитььь и поновой накатить?

 Отправлено: 09.06.10 14:25. Заголовок: Тормоза после архива..

Тормоза после архивации наблюдал неоднократно на ВСЕХ версиях АРМ начиная с 07.005.00 и выше.
Явный баг в процедуре. Особенно, если база платежек довольно большая (более 3000), а таких клиентов у нас довольно много...

 Отправлено: 09.06.10 14:39. Заголовок: архивацию проводим у..

архивацию проводим у многих клиентов, таких проблем не наблюдали.....

 Отправлено: 10.06.10 11:35. Заголовок: Особенно, если база ..

цитата:

Особенно, если база платежек довольно большая (более 3000)

вот-вот, как раз наша ситуация :)

провёл архивацию на 007.008.000 -- таже ботва, начинает потом тормозить.
но не везде, а вот если выбрать рублевые платежки, выбрать получателя, и потом быстрый поиск -- вводишь буквы ООО и начинаются тормоза, проц грузится под 100%.

Пуська - да мож ваши клиенты не жаловались просто, или платёжек очень мало.

 Отправлено: 10.06.10 11:54. Заголовок: Блин, не вижу коррел..

Блин, не вижу связи. База получателей это USER.DDF - можно попробовать удалить индексы и почистить саму базу от ненужных вхождений. "Справочники - получатели"
Но смущает то, что при архивации она ни коим образом не затрагивается...
Возможен вариант кривого быстрого поиска, м.б. попробовать накатить последнюю версию?
Сделать бэкап, накатить версию,попробовать в работе и ежели не устроит - откатить назад.

 Отправлено: 10.06.10 13:21. Заголовок: я накатывал уже верс..

я накатывал уже версию 007.012.003 поверх на 007.012.003 -- всё тож самое...
поиск какой то тормозной...

w0rkm4n пишет:

цитата:

почистить саму базу от ненужных вхождений.

а что это значит?

рублевые платежки не удаляются никак.

до архивирования кол-ва информации было куда больше и работало всё без Тормозов.

наверно надо было не Архивироваться а устанавливать новый клиент банк, а старый переименовывать и использовать только для просмотра старой инфы.

 Отправлено: 10.06.10 13:53. Заголовок: printf пишет: а что..

printf пишет:

цитата:

а что это значит?

я про "почистить справочник получателей"

 Отправлено: 11.06.10 12:16. Заголовок: там 580 получателей,..

там 580 получателей, построчно удалять времени займет много.
а оптом не удаляется.

а платежек 2617.

чуток почистил - всё равно не помогает, какой то явный внутренний баг.

прикол еще в том что если вводишь данные которых нет в поиске, то буквы-цифры вводятся быстро, тормозов нет.
а если то что находит клиент-банк, то сразу поднимается загрузка проца и начинает поиск тормозит...
по идее - фигня какая то, ведь поиск что так работает, что так -- не важно что ты вводишь... а тормозит тока когда инфа находится.

 Отправлено: 13.06.10 09:55. Заголовок: printf архивацию пр..

printf
архивацию проводим только подсистемы рублевые п/п..и все!
честно, никаких жалоб!
встречалось пару-тройку случаев жутких тормозов (абсолютно не связанных с архивацией) при обновлении версии или при перестройке индексов справочников БИК и SWIFT, порядка 2-3 часов на это уходило...решалось просто - убиением оператора и чисткой реестра...

 Отправлено: 15.06.10 00:27. Заголовок: printf Подтверждаю,..

printf
Подтверждаю, что жалоб на тормоза КлБанка после архивации не поступало. Наоборот скорость только увеличивалась.

Такое ощущение тормоза возникают из-за того, что КлБанк обращается к службам Windows. А те в свою очередь и вызывают нагрузку процессора 100%. Мне например такое представляется, когда настроена какая-то своеобразная индексация в Windows или базы в сети.

Я советую заархивировать все данные не только за прошлый год, но и за этот. А потом удалить файл work.ddf (база платежек) и еще *.ddf с базой плательщиков, но какой точно не скажу, надо искать его экспериментальным путем. Тогда база получится чистая, как будто с нуля ее установили.

ЗЫ 580 получателей - никогда не видел такую гигантскую базу контрагентов

 Отправлено: 15.06.10 15:35. Заголовок: да, я тут провёл тес..

да, я тут провёл тестовую повторную архивацию (до 01.05.2010) вроде как помогло :), теперь стало побыстрее работать :)
спасибо

буду теперь бухам "начистовую делать" :)

 Отправлено: 16.06.10 10:46. Заголовок: не устроило наших бу..

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

и не понятное дело еще почему номера начали раньше захватываться с прошлых лет... неужели 50 тыщ записей это предел такой по номерам.

 Отправлено: 16.06.10 17:25. Заголовок: printf пишет: и не ..

printf пишет:

цитата:

и не понятное дело еще почему номера начали раньше захватываться с прошлых лет... неужели 50 тыщ записей это предел такой по номерам.

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

 Отправлено: 28.07.10 17:05. Заголовок: Поверьте, разработчики и не такое могут.

Доброе время суток господа и дамы:)))
сегодня абсолютно с такой же проблемой столкнулись, после архивации включительно по 31.12.2009 года, пошли косяки с быстрым поиском! клиенту не обходим он просто, по дате выбирать не имеет желания! кто что еще скажет, примерно кроме наката винды уже все попробывали, ну или почти все!!
буду рад любому дополнению по данной проблеме!???

 Отправлено: 28.07.10 20:30. Заголовок: Sasha911 пишет: буд..

Sasha911 пишет:

цитата:

буду рад любому дополнению по данной проблеме!???

Отзвонитесь завтра на 8-963-279-0065 - проблема решаема.

 Отправлено: 29.07.10 04:40. Заголовок: Отзвонитесь

Уважаемый Mike666, если информация секретна хоть в личку напиши!

 Отправлено: 29.07.10 13:51. Заголовок: господа есть еще кт..

господа
есть еще кто живой?:)
ну все испробовали ! кроме наката винды
естественно !!

 Отправлено: 29.07.10 19:46. Заголовок: Ну, в добавок ко все..

Ну, в добавок ко всему сегодня сказанному, Есть ещё такие варианты:

Ещё раз (после сохранения базы) поставить с инсталляхи (можно не один раз). Сам таким способом не пользуюсь, потому что делаю свои "апдейты".
Можно "сурово" (если есть возможность) - скопировать программу на флэху, сделать "системный откат" дней на 10-ть назад (узнать, где хранятся азхивы от 1С). Всё будет так же лихо работать, проверено. А затем тупо скопировать каталоги Archiv и Base. Если было обновление программы, то запустить и прогнать Configwc.exe.

 Отправлено: 29.07.10 19:51. Заголовок: Зачем такие сложност..

Зачем такие сложности? Может быть стоит начать с удаления файлов индексов (*.ndx)

 Отправлено: 29.07.10 20:09. Заголовок: Они уже пробовали - ..

Они уже пробовали - не помогло.

Я к чему веду - К-Б использует в бОльшей степени средства Windows, своего у него почти ничего нет, потому и действовать нужно теми же способами. База "коряво" закрылась - откат убирает из реестра все предупреждения об этом событии.

 Отправлено: 26.10.10 19:02. Заголовок: Сегодня столкнулся с..

Сегодня столкнулся с такой-же проблемой, перенес даже домой базу, и опять тормоза. Помогите!!!!!!!

 Отправлено: 26.10.10 20:31. Заголовок: Mrmixxx, опишите под..

Mrmixxx, опишите подробнее... с чего все началось, когда проявилось...

 Отправлено: 26.10.10 20:57. Заголовок: Пришел к лиенту, сде..

Пришел к лиенту, сделал архивацию 2009 года. После этого при быстром поиске платежки начинаются жуткие тормоза, проц до 100%, платежек около 2000. Вернул из бекапа work.ddf. Поиск работает быстро, архивирую - опять тормоза. Забрал базу доой, поставил с нуля, подложил только work, тормоза...

 Отправлено: 26.10.10 21:09. Заголовок: Версия 012.03 или 01..

Версия 012.03 или 012.05?

 Отправлено: 26.10.10 21:12. Заголовок: 012.03, также пробов..

012.03, также пробовал 070600, 070900

 Отправлено: 26.10.10 21:13. Заголовок: ошибся была версия п..

ошибся была версия при архивировании 012.05

 Отправлено: 26.10.10 21:30. Заголовок: подождите, т.е. на в..

подождите, т.е. на версии 07.006.00 тоже тормоза? Что-то как-то грустно...

отправил ЛС...

 Отправлено: 26.10.10 21:39. Заголовок: Есть несколько "..

Есть несколько "ненормальное" предложение: после архивирования снять принудительно со всех файлов в базе все атрибуты ("скрытый", "системный", "архивный", "только для чтения" - просто тупо снять), удалить все индексные файлы (*.ndx), не создавая никакого запроса, просто провести сеанс связи. А потом попробовать "поиск".

 Отправлено: 27.10.10 20:30. Заголовок: Сегодня появилась ид..

Сегодня появилась идея: откатить нормальный бекап на 07.009.00, урезать, а потом опять обновть до 07.012. Завтра попробую, напишу

 Отправлено: 18.07.11 20:08. Заголовок: решил возобновить те..

решил возобновить тему...

Обратился Клиент - версия АРМ 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 - на вас выставлю запрос завтра... :(

 Отправлено: 18.07.11 21:24. Заголовок: admin пишет: 1. На ..

admin пишет:

цитата:

1. На другом компе - нет эффекта

Вот была когда-то у меня обычная почтовая база под Outlook Express, и в какой-то момент начались ну дикие тормоза при открытии почтовых папок.
И сжимал базу, и папку с базой на другой диск переносил - ничего не помогало. В итоге оказалось виноват антивирус, воткнул папку с базами в список исключений - и стало хорошо.
Это я к тому, что в контенте work.ddf (а скорее в work.ndx) могут быть совершенно случайные сигнатуры, вызывающие "стояк" у эвристики антивируса.
И возникла эта сигнатура недавно (в смысле даты документа), тогда когда клиент обратился - поэтому обрезание проблему не решает, т.к. недавние документы остаются в work.ddf
Поэтому предложу эксперимент:
- архивные помесячные "нарезки" work.ddf у вас есть (ну или архивируем базу)
- заменяем work.ddf на любой из этих месячных "кусков"
- проверяем скорость поиска

 Отправлено: 18.07.11 22:01. Заголовок: А не проще ли (в пор..

А не проще ли (в порядке эксперимента) отключить антивирус? И проверить эту догадку...

 Отправлено: 18.07.11 23:18. Заголовок: Ребята... у Клиента ..

Ребята... у Клиента NOD 32, на работе Kasper, дома пусто - везде висит... т.е. предположение, что все таки не антивирь...

с восстановлением месячного архива можно даже не экспериментировать (хотя щас попробую) - суть - в архиве п/п будет немного... у клиента с начала года почти 3 тысячи п/п - в архиве не более 300 - следовательно работать будет быстрее... :(

 Отправлено: 18.07.11 23:47. Заголовок: что и требовалось до..

что и требовалось доказать - в архиве за месяц - около 30 п/п - работает до не приличия быстро...

 Отправлено: 19.07.11 08:58. Заголовок: А не проще ли отключ..

цитата:

А не проще ли отключить антивирус?

На такие грабли несколько раз наступал, стопроцентная остановка антивируса - это его деинсталляция
admin, а как насчет параметра ПОЛНЫЕ_ИНДЕКСЫ=0 ?

ЗЫ. Отключить в Винде службу индексирования, с папки BASE снять атрибут "Разрешить индексирование" ?
Перекинуть базы на раздел с FAT32 вместо NTFS ?

 Отправлено: 19.07.11 20:39. Заголовок: ZhooChee пишет: adm..

ZhooChee пишет:

цитата:

admin, а как насчет параметра ПОЛНЫЕ_ИНДЕКСЫ=0 ?

старшие коллеги сказали, что нифига не прокатывает....

опять со слов старших коллег - такая "байда", только с подсистемой рублевые п/п...

ZhooChee пишет:

цитата:

Перекинуть базы на раздел с FAT32 вместо NTFS ?

ну это уж из области научно фантастики...

Эксперимент провел еще один:
исходные данные:
АРМ 07.015.00.
БД из 30 - 40 п/п.
поиск по получателю в БД рублевые п/п проходит быстро (оговорюсь как делается поиск - щелкаем на получателей - все сортируется - щелкаем на черный треугольник рядом с расширенным поиском и выбираем поиск внутри строки - в поле поиска вводим какое-нить длинное слово).
Архивация БД никогда не производилась!

Цель:
создать в БД несколько сотен п/п и проверить поиск на предмет тормозов

Результат:
хрень полная... хитрым способом (загрузка из внешнего файла, стандартной операцией импорта из 1С) создал порядка 7 сотен п/п... т.е. на тот момент в БД было чуть менее 8-ми сотен п/п... и вот тут самое интересное - тупить при поиске стал безбожно...

Вывод:
Дело не в архивации БД. Дело в кривой процедуре поиска, ибо на версии 07.003.00 веСЧь работает безупречно и крайне быстро.

Послесловие:
Ребята, кто может подбить статистику - т.е. у кого из Клиентов есть более 700 п/п в рублевых или есть модель, где не делали усечение проведите эксперимент с поиском - будет ли "тупить", т.е. набор длинного слова в поиске будет происходит так - вводим на клаве слово, а в строке поиска все появляется медленно и по букавкам... Буду признателен...

 Отправлено: 21.07.11 08:23. Заголовок: У меня версия 07.012..

У меня версия 07.012.05, до архивации поиск работает быстро, ни чего не тормозило, после того как сделал архивацию, поиск начал тормозить, при вводе большого слова появляется по букве. В связи с тем, вернули бэкап, который делали до архивации и все вернулось как и было, т.е. работает все быстро. Мне кажется, что поиск тут не причем...

 Отправлено: 21.07.11 08:33. Заголовок: Может у меня на комп..

Может у меня на компе много разных моделей... х.з. - но я взял чистую модель и импортировал туда кучу платежек (около 800 всего) торможение есть... т.е. архивация не причем...

 Отправлено: 21.07.11 08:34. Заголовок: onyx301, а архивацию..

onyx301, а архивацию, т.е. усечение делали только рублевых или всей кухни?

 Отправлено: 21.07.11 13:49. Заголовок: admin пишет: onyx30..

admin пишет:

цитата:

onyx301, а архивацию, т.е. усечение делали только рублевых или всей кухни?

"Делали по всей кухне". Просто если делать не по "всей кухне" в КБ появляются тормоза при входе и обработке данных.

 Отправлено: 21.07.11 20:20. Заголовок: onyx301 пишет: "..

onyx301 пишет:

цитата:

"Делали по всей кухне". Просто если делать не по "всей кухне" в КБ появляются тормоза при входе и обработке данных.

т.е. утверждение - если усекаем БД, то сечем все подсистемы без разбора - верно? Надо попробовать завтра на модели... может все таки поиск ускорится...

 Отправлено: 04.08.11 19:53. Заголовок: У нас до сегодняшнег..

У нас до сегодняшнего дня некоторые Клиенты тоже жаловались, что после усечения БД (только платежки) начинаются тормоза во всей подсистеме "Рублевые платежные поручения". Но то ли Клиенты были мелкие, то ли операций особо по нам не проходило - в общем особого резонанса все это не получило. Однако сегодня обратился наш "гигант". Им просто катастрофически необходимо набирать платежки именно в КлСб. А у них после усечения БД (только платежки) происходит следующее: набрали документ, нажали сохранить ... пьем чай ... документ сохранился, нажали "закрыть" ... пьем чай, курим, допиваем чай... набираем следующий документ. Сегодня видел все это своими глазами. По рекомендации ТБ пробовал чистить системный ТЕМП, пото перенастроил вообще на С:\ТЕМП, переносил на другой компьютер, удалял скрипты из Базы и накатывал 07.14.02 по новой, убивал Архив... Ничего не помогло. Если подобную проблему кто то уже решил - подскажите решение.

 Отправлено: 05.08.11 05:33. Заголовок: Zarin Я пробовал по..

Zarin
Я пробовал после такого "явления" усекать дальше, по одному месяцу, после каждого усечения инсталлировался поверх. Где то через три - четыре усечения тормоза ушли. Да, перед этим автоматически реестр зачистил.

 Отправлено: 04.04.12 16:06. Заголовок: Прошло много времени..

Прошло много времени с момента последнего поста в этой теме...
Наступили на те же грабли, версия 07.015.01_45. Организация большая, поэтому тормоза как описано у Zarin выше, нажал кнопочку - покурил, еще раз нажал, чай попил и т.д.
Кто нибудь нашел решение проблемы?