"Недостаточно памяти" при формировании Главной книги. #614806

Здравствуйте. Сервер 1С    - v8.2.14.540 [x86-64] Платформа    - 1С Предприятие v8.2.14.540 Конфигурация - БГУ v1.0.10.2 БД           - MS SQL Server 2008 R2 [x64] ОС сервера   - Windows 2008 Server R2 Enterprise [x64] ОЗУ сервера  - 48 ГБ Такая проблема: не могу сформировать отчет "Главная книга". Платформа долго формирует, затем выдает сообщение "Недостаточно оперативной памяти". Есть у кого соображения, в какую сторону рыть?

план счетов меняли?

Добавляли свои специфичные счета и субконто к некоторым стандартным.

Памяти  недостаточно на сервере, или на клиентском рабочем месте? На сервере, вроде, не должно.

ну вот туда и копать

И на сервере и на клиенте не хватает. Клиенты под терминалом. Пробовал всех выгонять, перезагружать сервер, делать заново. Все равно, занятая память достигает ~12 ГБ и выдается сообщение.

Каким образом?

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

Кстати, книгу формирую за месяц. При формировании 1-29 числа всё формируется (16 ГБ ОЗУ). При формировании 1-30 числа - не хватает памяти (при занятой 12 ГБ)

В диспетчере задач посмотри, какие процессы конкретно отбирают память.

Больше всех 1cv8.exe - 3 ГБ.

помогло?

SQL-серверу выделено 30 ГБ памяти. Ему должно хватать. Видимо, в платформе дело. Пытаюсь, мониторю...

ребутни сервер :)

уже много раз

в 30-х числах не игрались ручными операциями? другие отчеты формируются?

Ну все, 1С уперлась в ограничение 32-битного режима.

и тестировал, наверное, тоже?:)

Мне? Иногда помогает, по крайней мере, видно, что виснет, или postgresql(в моем случае) гребет под себя из-за плохого плана запроса, или rphost тупо и нудно что-то выполняет. Товарищу про и пока не очень хочется думать, поэтому до упора будут ковыряться платформа или SQL. Хотя то, что ты спрашиваешь, наиболее вероятно( именно у бюджетных бухгалтеров).

Погонял счетчики производительности.. печально. Сначала долго работает SQL, периодически прерываясь rphost'ом. Затем sqlservr утихает, rphost набирает 6 ГБ оперативки. Затем 1cv8 набирает ОЗУ > 3,9 ГБ и выдаёт оошибку :( Похоже, дело действительно в 32-bit клиенте. Нет решения?

Написать письмо в 1С, чтобы выпустили 64-bit клиента. Может в 8.3 будет, хотя бы под linux... А если формировать за предыдущие месяцы или с 1 по 29, то 1с8 в верхнюю планку не упирается, скорее всего. Оставь платформу в покое, прислушайся к DrShad.

DrShad, ручных операций у нас всегда много, к сожалению. Сказывается недопиленность конфига под организацию/удаленность от города/пофигизм. Остальные отчеты формируются.

ТС, а сколько всего максимум субконто у тебя?:)

- более понятно, максимальное количетво субконто сколько?

не больше 5 случайно?

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

максимальное количество субконто - 4 Если бы знать, как... что понимается под "кривизной"? По какиим признакам можно вычислить "кривые" данные?

Сформировал за предыдущий месяц - получилось. Видимо, проблема как раз в нужном мне месяце.

Интересно, а кто нибудь рассматривает вариант оптимизации запроса по главной книге? :)

Здравая мысль, имеющая смысл при соответствующих навыках.

Скриншот с проблемным участком кода. Думаю, вам это даст больше информации, чем мне.

Добавленные субконто определённого типа?

Нет. Где-то добавлены "Контрагенты", где-то "Направление деятельности"

К некоторым счетам добавлено даже по 2 субконто. Вот, еще заметил "Номенклатура" как доп. субконто.

А по памяти сколько заняла при формировании? Если много меньше предела - надо искать кривые данные. Для начала можно попробовать замером производительности вычислить, где крутится код во время роста памяти - и дальше там уже смотреть, нет ли чего необычного в данных. Найти эти кривые данные может быть непросто, т.к. кривизна может быть неявной, а в сочетании с другими данными. Попробуй заменить на и посмотри, что будет сформировано по первым 15 тыс. итераций. Возможно, зациклившиеся данные вылезут.

смотр пост ОН правильно говорит, тока я делал так я выводил кусками, брал общее количество кусов делил на 14 от общего количества памяти, и выводил эти куски отщепляя от итераций. Наглядно выглядит так. У меня массив был 34 000, его нужно было обработать, и почему то вылетало "Недостаточно памяти", все сразу не срабатывало. Памяти 4 000 МБ, 14=1000, и брал от массива куски по 1 000 , и пока количество начального массива 0 не будет, то обрабатывать это все.

Сделай ТиИ базы это раз, пересчет итогов это два (только про бэкап не забудь)

уверен на 99% что если эту базу выгрузить в файловую - отчет сформируется. Так что смотри в сторону ошибок БД

Мде. Даже 15000 оказалось много. Вываливается. Пробую меньше.

я же написал что 15 000 много сделай поменьше как я описал.

ТиИ не поможет, пробовал. В файловом режиме не формируется. Та же нехватка памяти. Делал даже А < 5, и даже в файловой базе, всё равно - медленное переполнение и нехватка памяти. А как запустить замер производительности 1С, чтобы можно было контролировать временную шкалу? Чтобы выяснить, в какой момент времени начинается рост памяти?