v7: Бухгалтерия 7.7: тормоза из-за акта сверки #564649

Добрый день. Проблема следующая: бехгалтерия 7.7 (sql), в базе одновременно работают 10 пользователей. Как только кто-то из них запускает формирование акта сверки, скажем, за месяц, все остальные начинают жутко тормозить. Как лечится эта проблема? И еще момент. Во время групповой обработки документов частенько вылетает сообщение об ошибке "Время ожидания блокировки таблицы 1SJourn истекло". В принципе, это и так понятно, что таблица журнала доков в момент записи/проведения конкретного документа блокируется для всех остальных юзеров, но - опять же, - вроде бы есть какой-то патч?

Добрый день. Проблема следующая: бехгалтерия 7.7 (sql), в базе одновременно работают 10 пользователей. Как только кто-то из них запускает формирование акта сверки, скажем, за месяц, все остальные начинают жутко тормозить. Как лечится эта проблема? И еще момент. Во время групповой обработки документов частенько вылетает сообщение об ошибке "Время ожидания блокировки таблицы 1SJourn истекло". В принципе, это и так понятно, что таблица журнала доков в момент записи/проведения конкретного документа блокируется для всех остальных юзеров, но - опять же, - вроде бы есть какой-то патч?

как можно пропатчить фичу?

нагрузку на скулевом серваке мониторил? что за сервак? характеристики? и последний вопрос на пять: какой релиз платформы, и какой скуль?

для первого смотреть надо для второго - посмотри гибкие блокировки от софтпоинта

2. Восьмиядерный проц, 4 гига оперативы 3. Платформа 27, sql 2000.

сомневаюсь, что 8 ядер нужны на 4Гб оперативки, но автору виднее. и не понятно, терминальный режим или голая сеть?

в терминале, ессно...

Акт сверки всегда был таким. И на больших базах блокирует таблицы и формируется долго. Выход - искать альтернативный акт сверки или освоить самому прямые запросы. Более НИКАК.

8 ядер на 10 пользователей? круть. попробуй 1cv7s.exe по ядрам пораскидывать в зависимости от пользователя - должно немного помочь start  /affinity номер_ядра /normal 1cv7s.exe enterprise /DПуть_к_базе

это не поможет вылечить блокировки.

А где бы можно глянуть описание полей 1SENTRY?

в 1cv7.dds :-)

Ага. А еще в QA :) Меня интересует, в первую очередь, описание содержимого его полей на  ч е л о в е ч е с к о м  языке :)

Можно переписать акт сверки на Прямые запросы. Если что-обращайся icq 201216890

Мне нужно просто подробное описание полей 1SENTRY. А переписывать акт сверки под прямые запросы я буду сам.

+14 усё, нашОль, вопрос снят.

А аккаунтрекордссет использовать религия не позволяет?

Как получить значение субконто Дт/Кт проводки из 1SENTRY? Про структуру файла можно уже не рассказывать, есличо.

+17 Пытаюсь выбрать из проводок поле DTSC0, он мне выдает ошибку: State 22018, native 245, message [Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the varchar value '   61H       ' to a column of data type int.

мож ты к полю Vdtsc0 обращаешься? Код нужно видеть.

дело в том, что 1с не использует БухЗапрос

Лови: SELECT

на ЭТОМ запросе валится ошибка? Или это уже что-то другое?

Да, ошибка именно в таком виде. Если убрать Проводки.DTSC0 As СубконтоДт1, то запрос выполняется успешно.

Поищи на Инфоstarte. Я переделывал для УСН, но смысл тот же. Заменил ВыбратьОперации с проводками  на использование бухитогов. Работает в разы быстрее.

показывай тогда остальной обвес. Ошибки в запросе нет. Или ты не все показываешь!

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

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

+27 всё, заработало :-) мой косяк был. В-общем, вариант в рабочий. Теперь возникает вопрос, как это значение привести к типу 1с?

усё, со всем разобрался вроде бы :-)

ппц, я в шоке... Вот ведь какая хрень: сделал замер скорости выполнения обычного акта сверки 1С и сделанного на прямом запросе (см. ), с одними и теми же условиями. Так вот что получилось: - время выполнения первого - 8 сек. - время выполнения второго - 98 сек... Прямые запросы меня начинают все больше разочаровывать... :((( Как такое вообще может быть?! Что делать?

см. в

То есть ускорить через прямой запрос эту фигню никак не получится?! :(((((((((((

Почитай про класс прямой запрос, там вроде ВТ несколько оптимизированы, да и писать удобнее.

хз

Попросить людей или сделать самому правильно. Чтобы сделать самому правильно, нужно попытаться понять, что ты своим запросом, с большой вероятностью, сканируешь кластерный индекс - отсюда и все проблемы.

ты жалуешься или хвастаешься? :-)

Можешь ткнуть в нужном направлении? Как можно оптимизировать запрос из , чтобы он шустрее работал?

Тебе же уже сказали - использовать виртуальные таблицы

Где про них можно почитать? Именно про таблицы для 1SEntry

тебе надо использовать один из классов на базе 1С++ Либо ПрямойЗапрос либо AccountsRecordset

Интересно... Что такого волшебного в этих классах, что только они позволяют ускорить запрос к таблице проводок?

Есличо, с классами вообще пока что не работал

они попадают в индексы получше, чем ты в . можно и без классов - посмотри на план выполнения и подумай

Чо за план, как куриццо?

Это я уже видел. Что там должно мне указать на то, как ускорить мой запрос?

Вот что нарыл: Там сначала чувак, задающий вопрос, приводит вот такой код без AccountRecordset: Товарищи, т.е. фактически получается, что вариант 2 будет быстрее выполняться по времени по сравнению с вариантом 1?

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

Отбор по _1SENTRY почти всегда будет неоптимальным и тормозным. Акт сверки (обороты в разрезе движений) надо формировать бухзапросом, с отбором по субконто Контрагенты. Причем, по моему опыту - лучше не запускать запрос по всем счетам, а вызвать его несколько раз, по каждому счету, где есть субконто Контрагенты, далее эти данные свернуть в таблице значений. Почему-то несколько бухзапросов по одному счету выполняются значительно быстрее, чем один бухзапрос по списку счетов.

Имеется в виду стандартный 1совский бухзапрос? Насколько быстрее?

если ты не в курсе, можно счета не указывать, а разворачивать по контрам, а потом по счетам смотри в сторону анализ субконто

это будет тормозить, если по контрам не включен отбор

Можно по-разному.. главное не запускать бухзапрос по списку счетов. И не использовать ВыбратьОперацииСПроводками. У нас на бухии изначально был акт сверки жутко тормозным, когда ушли от глобального бухзапроса по всем счетам - сразу стало всё летать, повышение скорости на порядок или на два. sql-версия.

Товарисчи - есть такой файл который называется Отбор проводок по субконто - _1sbkttl. Так вот именно его а также отбор проводок по счетам и надо использовать

нужно нужно смотреть только обороты

Как в данном случае его использовать?

это понятно. но без отбора по субконто это выльется в скан таблицы проводок

Перепиши акт сверки). Он все равно как был уе..ким так и остался. Памяти мало. SQL жрет дофига, а там еще терминальный сервер. Это ППЦ. Так то вообще изврат, но способ (SQL + TS) вошел прочно в обиход.

нет у БИ три таблицы : итоги/остатки/проводки будет по итогам идти

у тебя уже тяпница? :-) в таблице итогов нет данных о документах-регистраторах движений и таблиц там куда больше трех

+58 По момему проще памяти добросить - очевидно что ее мало. Потом написать нормальный акт сверки без всяких прямых запросов - они тут нафиг не нужны... имхо, и не трахать мозг, 10 пользователей всего. Ну любят люди извращаться на ровном месте.

а можно вопрос не в тему? Зачем бухгалтерскую базу с паршивым десятком пользователей сажать на sql? Терминал плюс dbf будут работать намного быстрее

Память не поможет - всё равно последовательный скан это сильно не ускорит.. даже если сервер полностью базу закэширует. Алгоритмы надо переписывать. В типовой алгоритмы под sql не всегда оптимально построены..

сколько больше ?

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

"Нормальный" - это какой?

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

Я тут подумал - из за акта может тормозить по одной причине - нехватает памяти. Так что наверное и переписывать ничего не надо. Хотя типовой уродский, писал свои давненько работали гораздо приятнее с использованием бух запроса обычного.

+68 Все делал в одном запросе, потом выюборка и все. Код был крайне компактный.

Стандартный бух. запрос?

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

Да

Но я его не на почве производительности писал. Прсто тогда актов вообще не было в типовых))) да было время)

+73 Или был совсем убогий

В таблице проводок хотя бы десяток мегазаписей есть? :)

было наверное, я хрен его знает. Непомню уже.

У человека тормозит не акт! Другие юзвери. Так что колбасить атк особого смысла не вижу.

Ладно, пока всем спасибо. Сегодня уже поздно, завтра буду проверять на работе все варианты. Что получится, отпишусь.

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

+77 Ну т.е смыс есть но после увеличения памяти. Но вообще я повторюсь SQL + TS это дурдом на мой взгляд. Это уж когда выхода нет. Клиенты дохлые совсем, а в DBF база не влазит.

С фига ли ее станет надо больше? Акт формируеться за определнный период по контретному контрагенту. Т.е. ясное дело SQL зажрет еще себе сколько влезет, но к акту никакого отношения это не имеет. Я вот что то думаю, что SQL столбит себе память, терминальные сессиям вероятно приходиться сосать... с диска). Както так. А править алгоритмы в данном конкретном случае тут дело третье. Добавте памяти страждущему. Ведь каждая сессия дофига жрет памяти а тут еще данные обработать надо. 4Гб для SQL + TS - фигово, как впрочем и сама конфигурация дурацкая - SQL + TS.

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

Кстати у меня один и тот же запрос Бух на SQL базе выполняеться в 10-ки раз быстрее чем на DBF. Практика. Правда я терминалы не сажу на SQL сервер)

Давать советы типа "добавьте памяти", не видя реального состояния системы, показаний счетчиков производительности в динамике, в часы наибольшей нагрузки и в среднем - по меньшей мере непрофессионально!

спс, гляну

А че тут видеть то? - Чисто из опыта 4ГБ ОЗУ одной SQL то было мало на сравнимой базе - предел по DBF и за, а тут еще сессии терминальные подвешены на серваке. Я бы и думать не стал удволи бы и все. Тут вопрос в винде сервачной - сожрет ли 8 и все. А так самое простое и экономически целесообразное решение.  Худже точно не будет, а дальше бы уже думать стал.

+86 если с памятью напряг подумал бы на перевод части юзверей с терминального клиента.

Напряг в дисковой подсистеме в первую очередь, а потом уже с памятью. Чтобы построить акт нужно перебрать за период горы данных тупым сканированием, хоть и, кластерного индекса. Физически это можно сравнить с тем, как золото добывают - большими экскаваторами выгребать руду, а потом искать писчинки золота. Вот ковш экскаватора это память скуля. И сессно, если ковш больше, то и загребать он сможет больше и, вроде как, дело пойдет быстрее. Но один фиг перебираем горы. Нужно искать подход такой, чтобы грести золотой песок - попадание в индекс. Как-то вот так :)

Хорошо сказано!

Ну, сранение красивое, не спорю :) Только теория она теория и есть. На данный момент самый быстрый вариант - акт сверки, о котором речь в . И это не прямой, а обычный, бухгалтерский запрос 1С.

(+88) Индекс в подобной аналогии - это подробный указатель координат точек, где этот золотой песок находится.. и рыть экскаватору приходится на порядки меньше.. и можно обойтись меньшим размером "ковша".

уже было сказано, что запрос ты нарисовал не верно. Логически он верен, конечно. Но часто решение в лоб не дает хороших результатов, что и доказал твой опыт. Вот смотри.. 0. sp_help '_1sentry' - вот тут тебе будет вся инфа по табличке. 1. изучаем индексы для этой таблички: PK__1SENTRY, ACCDTID, ACCKTID и другие не интересные. 2. твой запрос идет по идексу PK__1SENTRY - 100%, а это тупо проводки отсортированные по дате (упрощенно говоря), следовательно, чем больше период, тем страшнее. Вывод: нужно искать другие пути. Если у тебя включен отбор по Контрагентам (как уже тебе тут твердили) - Метаданные-ВидыСубконто-Контрагенты-Отбор, то у тебя в табличке _1ssbsel будет немного счастья. Потому как sp_help '_1ssbsel' кажет там индекс VALUE, из значений которого можно спозиционироваться в таблице _1SENTRY.

Где эти индексы находятся? В самой табличке _1SENTRY? Она у мну дюже здоровая... При попытке ее открыть QA мну на хутор за бабочками посылает :(

да.

Глянул. Тогда возникают след. вопросы: 1. По какому индексу оптимальнее строить запрос? 2. Как заставить RecordSet выполняться именно по этому индексу?

я, №;ять, на китайском написал чтоли?

"немного" счастья - это сколько? :)

_1ssbsel - это у нас таблица отбора субконто, я правильно понял?