Есть БитФинанс. В нем распределение затрат по отделам-статьям расхода- федеральным округам-номенклатуре. На обработке за день всё нормально (то есть программной ошибки нету, да и работаем в бите не одни мы), за месяц (за любой - то есть дело не в каком-нибудь корявом документе) вылетает ошибка. Спец из БитФ говорит, что эта ошибка вылетает при нехватке памяти.
Во все время работы обработки доступная память на сервере не бывает менее 6гигов (в максимуме съедается 16-18 из 24), дискового пространства не мерено. То есть ресурсы есть.
Немного смущает количество получающихся строк, которые надо обработать в тразакции при обработке за месяц- порядка 6-8 миллионов. Может ли быть так, что либо SQL сервер либо 1Ссервер просто не "способны" работать с таблицами такой длины? Даже при наличии свободных ресурсов?
Немного коряво объяснил, но вроде понятно...

У меня 2 млн строк пакетно читалось и 1 млн пакетно записывался - полет нормальный.

(0) это у спеца из БитФ проблемы с вычислительной мощностью

Если конфа не выдерживает достаточно серезное железо жто проблема разработчиков конфы. Надо у них править кривые руки или в помойку такие конфы.

(0)Ошибка какая вываливается??

(0) скорее всего превышен объем памяти на клиенте (3Гб+)

(2) +1)))

(0)...даже не разбираясь с кодом есть решение в лоб - 64-х разрядный сервер 1с

+(6)...у 32-х разрядного ограничение по используемой оперативной памяти на один рабочий процесс (за 3Гб)...но как и  было верно замечено в (3) это скорее показатель не оптимального кода конфижки

(6) сервер64 не решит проблему, если память превышает лимит на клиенте

(0) Ошибку ты нам конечно не скажешь. И какая разрядность у сервера 1С тоже не скажешь - пусть сами догадываются

(5) вот про ресурсы на клиенте не подумал, спасибо.
(9) Разрядность сервера 1С - 32, но пока проблем не бывало. А я бывает по-быстрому ляпаю довольно тяжелые отчеты без малейшей оптимизации. Ошибку БитФ выдает о разрыве связи с сервером, но я там на бегу просмотрел код - это предупреждение будет выкидываться при целом ряде разных ошибок.

+++++++++++++++++++++++++++++++++++++++++++++++

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

>Разрядность сервера 1С - 32, но пока проблем не бывало

патамушта винда скорее всего 64... + рабочих процессов не один

Походу 1С-Сервер-32 не в состоянии всосать от MS-SQL сервера ваши 8млн. строк тупо из-за ограничения по памяти , в этом случае 1С-Сервер-64 должен помочь.

(11) Ну да.
А то,что в данном случае на один процесс могло потребоваться более 3гб - буду смотреть.

(12)Да, возможно.

>Походу 1С-Сервер-32 не в состоянии всосать от MS-SQL сервера ваши 8млн. строк тупо из-за ограничения по памяти

клиент расти начинает как на дрожжах при записи

+

запись на клиенте

было веселее у одних - на сервере винда 64, там хватало 3,5 Гб
на клиентской тачиле 32 - соответственно падает на 2 Гб

дубина из франя бубнила про покупку сервера 1с 64...

вот бы разрыв пукана был у бухов после покупки

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

(8) да не подумал) привык к терминалам)))

>>принципиальных ограничениях то ли 1С, то ли sql

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

текст ошибки то военная тайна? через 50 лет только узнаем? или я пропустил всё?

> в конце концов переход на 64-х разрядные операционки и приложения

имхо проще научить 1с нормально insert/update делать

(19) у них же вроде проблема с отчетом а не записью в таблицы? ( (0) " все время работы обработки")

(18) Ну не в конторе я был.

Ошибка выполнения запроса
Ошибка при выполнении запроса POST к ресурсу /e1cib/logForm:
по причине:
server_addr=tcp://1C8SQL2008:1561 descr=Ошибка сетевого доступа к серверу
(Windows Sockets - 10054(0x00002746). Удаленный хост принудительно разорвал существующее подключение. ) line=1030 file=Src\DataExchangeTcpClientImpl.cpp

(19) Всё 64 кроме 1С сервера. Как-то исторически сложилось. А пока работало, естественно, не трогал.

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

(20) а так понял что пишут чего-то

>Всё 64 кроме 1С сервера

п.э. и везло до поры до времени...

ради интересу можно попробовать навтыкать начать/зафиксировать транзакцию чтобы в цикле лупилась по 1000 заходов

(22) Пишем. Обработка сначаля считывает "сырьё", потом считает-распределяет прямые и косвенные затраты, потом ЗАПИСЫВАЕТ результат в регистр. И вот тут-то (такое у меня впечатление) и падает.

пардон, не в регистр, а в документ.

Проблема не в 1с и скл, а в кривом запросе от бит.. кривой запрос можно попробовать обойти анализом настройки и изменением распределения затрат..
А битовцу за "нехватке памяти"- настучать, жаль, некому))

а 99999 строк в ТЧ документа не предел разве? как в документ мильёны записать то?

Легко...

(0) Надо переделать, чтобы данные из запроса выгребались не полностью, а порциями по 10к записей, например