Доброго времени суток!

стоит 1С 7.7 дбф версия, сервер 2х головый с 4Гб памяти (там ещё одна задача работает, но она отключена сейчас), с самописной конфигурацией.
До недавнего времени автообмен данных проходил нормально (ночью, несколько часов). Программисты (как грят они сами) по заказу одного отдела сменили структуру базы и теперь начались тормоза - база может грузиться сутки, а может и больше!

самое что интересное, если прогружать на локальной машине (1Гиг ОЗУ, пень 4 3ГГц) - грузиться максимум 2,5 часа...

настройки сервера не менялись!

куда рыть, кого бить??

Программист 1сВобще очень странная ситуация - может быть на серевере еще всетаки что-то? Например другие дбф базы и каталоги пользоватлей с почтой и тд и тп?нет, на нём тока 1Сы в 7.7. у нас на других серверах почта и пользовательские каталоги. Программист 1сМожет потестировать базы?Собираемся на днях произвести "чистку" :) pailНаверное, надо начать с анализа изменений структуры базы, сделанных программистами.
А также посмотреть на журнал регистрации базы, чтобы увидеть, объекты каких типов стали грузиться дольше. Или, может быть, самих объектов в обмене стало больше?
Долго могут грузиться справочники с периодическими реквизитами - история при обмене перегружается ВСЯ - независимо от того, менялись простые реквизиты или периодика.
Или документы прошлых периодов - если они попали в обмен.Вот их (программистов) слова:
"мы поставили отбор по реквизиту в большом справочнике"
В основном грузятся договора (их туева хуча), один раз на одном договоре висел сутки! в том договоре нет такого, что могло повергнуть в шок 1Сы.

Я так понимаю: внесли изменения, долго загрузились, выслали в регион, он там долго грузил (что и было), затем выслали к нам из региона... базы стали (по структуре и коду) идентичны! Объём данных стал в норме (2-4 МБ). Следовательно, должно вернуться всё на круги своя (по кол-ву затраченного времени)...

что и где копать?

pailОтбор по реквизиту в файле обмена не передается, потому на его объем влияния нет.
При приеме же любого элемента такого справочника перестраиваются индексы в таблице 1scrdoc по значению полей отбора - которая одна (!) отвечает за все отборы, дополнительные журналы документов, и еще за что-то (сейчас лень и вспоминать, и искать).
И эта таблица при широком использовании отборов - место в 1С 7 еще более узкое в производительности , чем общий журнал документов 1sjourn
Так что чудес нет, и все объяснимо с замедлением.это хорошо, что нет чудес!
но вот как мну это побороть? как мну вернуть на круги своя, т.е. что и где нужно настроить, что бы обмен не шёл несколько дней?

pailВарианты решений.
2. "одному подразделению" обосновать перед руководством покупку более производительной дисковой подсистемы на серверя вообще-то жду железо по мощней...но када оно придёт... обещали до НГ pail3. производить обмен локально.локально - т.е. ручками через конфигуратор?

Программист 1сБыл у меня справочник 2 мб -где то я поставил у поля идентификатор - отбор...(строка 40 символов) и справочник стал занимать 500 МБ. Аккуратнее надо с такими вещами.вот что ответил мну программер наш: "все норм, дбф 12 мегов, сдх 75"

2 pail, попробовал локально... можно сказать, что чуть быстрее...
что моно ещё сделать?