При формировании отчета по валовой прибыли вываливается ошибка: "Ошибка СУБД out of memory"

Форум Учет и отчетность Складской учет и логистика (WMS)

1С:Управление торговлей 10 Платформа 1С v8.3

1. Doomer 11.01.14 20:27 Сейчас в теме

Типовая УТ 10.3 крутится на postgres 8.4.3. База большая порядка 30 ГБ. Формируют отчет за период с 2012-2013 год. Выдается сообщение: "Ошибка СУБД out of memory failed on request". Если перевести эту же базу в файловый режим, то выдается сообщение "не достаточно памяти". Платформы использовал разные и 8.2.18 и 8.2.19. Как заставить отчет работать?

Ответы

Подписаться на ответы Инфостарт бот

Свернуть все

2. Alex_E 2363 12.01.14 01:36 Сейчас в теме

(1) Doomer, И там и там ошибка одна - не хватает памяти. Сообщение конечно не страдает информативностью, но здесь речь идет не о малом размере ОЗУ, а не хватает размера файла подкачки, разрешенном в настойках ОС. По крайней мере у меня пару раз помогло установка не фиксированного размера, а "Определяется операционной системой". Не факт что поможет - если ОС 32-битная, то может просто не сможет адресовать большой файл (это временный файл на диске, который создается при формировании отчета с большим количеством данных). Попробовать установить 64-битную ОС. Если и это не поможет - формировать отчет "кусками", за более мелкие периоды.
З.Ы. Никогда не смогу понять, зачем доводить базу до таких размеров?
Плюс видится один - всегда под рукой любой период.
Минусов вагон и маленькая тележка, начиная с "неповоротливости" такой базы. Практически невозможно сделать ТИИ. Обновления занимаю непозволительно большое время, и зачастую могут оканчиваться тем же сообщением и недостаточно памяти.

3. jigourt 31 12.01.14 01:52 Сейчас в теме

(2) Alex_E, у нас из-за того что не типовая доросла до 43 гигов и ничего с этим сделать нельзя. даже на своей локальной машине файловую в итоге развернуть не получается
(1) Doomer, а я все-таки считаю проблема в оперативке, хотя не знаю как работает постгрес

есть еще вопрос, запускаете отчет на сервере?

4. Alex_E 2363 12.01.14 02:08 Сейчас в теме

(3) jigourt, Про оперативку можно считать что угодно - я просто привел пример из реальной жизни (вообще винда при недостатке оперативной памяти начинает свопировать данные на диск - и вот тут срабатывает ограничение размера файла подкачки). С "недостатком памяти" встречался не раз, и на практике убедился, что 1с при больших объемах пишет всё подряд на диск. Засекал при формировании "больших" и один показательный случай - при обновлении БП 2.0 (релиз не помню - но тут даже предлагался способ обновить, что бы обойти эту же ситуацию) - пользователь загрузил ВЕСЬ адресный классификатор, а в обновление была его реструктуризация. Обновление хронически вылетало по недостатку памяти на 32-битной ОС, но за двое суток таки прошло на 64, при равном размере ОЗУ.
Большие отчеты естественно лучше запускать на сервере, ведь даже в клиент-серверном варианте работы на клиент должна перетащить огромная таблица, которая в ОЗУ может и не "влезть" и будет писать на диск, плюс время на трафик по сети то же айс получится.

5. jigourt 31 12.01.14 02:17 Сейчас в теме

(4) Alex_E, не, я конечно не утверждаю, что мой пост про оперативку догма, но смущает текст ошибки. как себя ведет 1С многие знают, но тут же есть еще СУБД ))) и повторюсь, как работает она я не знаю ))

6. Alex_E 2363 12.01.14 02:39 Сейчас в теме

(5) jigourt, Я сейчас такой злой, потому что время третий час, а у меня идет ТИИ вторые сутки клиентской файловой БП 2.0 размером всего то 6Г (обычно то я белый и пушистый)!!! Хочу дождаться, и свернуть к едрене фене, потому что у клиента на его старозаветном железе работать стало практически невозможно.
Вопрос просто в тему оказался.
У клиента 32-битная ОС (хрюша) упала по этой же самой ошибке после 6-ти часов. Взял себе, зесь под W8.1 16Г процесс идет вторые сутки, пере до мной диспетчер задач - так вот в нем в ОЗУ занято 4Г, причем достаточно стабильно (открыто сейчас 3 конфигуратора и одна база в режиме предприятия). Загруз винта, где база с ТИИ 100%, но не вываливается. Файл подкачки на всех винтах - определяется ОС. Когда стоял 1Г - вылетало опять таки по недостатку памяти, хотя в ОЗУ её вагон.
Про постргрис - пробовал сравнивать с мелсовчатым скулем - сравнение далеко не в пользу постгрис - работает намного хуже, жрет больше ресурсов, но - есть клиент, у которого клиент-сервная гна скуле так же не обновляется, пот тойже ошибке, и уже полгоада обновляю в файле и на своей машине, правда постгрис уже не ставлю (стоял, теперь снес - слишком медленно все на нем получается) - просто не хочется гемороя, и базы сверну, как год закроют.
Но и скуль и постгрис так же используют временные файлы, и так же тут есть файл подкачки, ну и соответственно важно ОС 64-бит - на ней все ж таки такое случается реже, точнее (тфу тфу тфу) у меня пока не было, да и не надо мне :-)
А по поводу базы в 30Г мне бы хотелось услышать причину, т.к.типовая/нетиповая здесь как то не аргумент, аргумент, что в любом случае, что бы сохранить какое то изменение, особливо связаное с реструктуризацией какого нито большого массива данных при таком объеме практически невозможно, особенно при непрерывной работе. Свернуть можно любую базу, типовую или нет, мне непонятна позиция - небудем сворачивать- будем мучаться :-)

7. deniseek77 86 12.01.14 10:07 Сейчас в теме

(5) jigourt, Недостаток памяти это не недостаток ПЗУ, ОЗУ или память программиста. Действительно, речь идет о размерах темпа, бывало, что в момент обновления темп файл вырастал до неприлично больших размеров. Например при размере базы в 3 Гб- темп 400 Гб. Далее оверлок и... ну Вы сами знаете.

10. Doomer 12.01.14 12:36 Сейчас в теме

(3) jigourt, Отчет запускали и на сервере и на клиентах. Результат одинаковый.

11. Doomer 12.01.14 12:38 Сейчас в теме

(2) Alex_E, Руководителю нужна аналитическая информация за 2 года. Вообще, по моему СУБД для того и придуманы чтобы оперировать большими объемами данных. Все минусы которые вы привели существуют, но они носят технический характер. Я не очень представляю как объяснить что на большой базе сложно сделать ТиИ.

12. Alex_E 2363 12.01.14 13:05 Сейчас в теме

(11) Doomer,

по моему СУБД для того и придуманы чтобы оперировать большими объемами данных

- согласен, но тогда нужно идти до конца - нужны большие объемы, а отчет вылетает, базу сворачивать не можем - руководство не поймет, но ведь тут на поверхности всё опять лежит:
Большому ~~кораблю~~ объему - большой компьютер. В этом случае даже по объему ОЗУ видно, что на "большой компьтер" денег тот же руководитель не дает. Замкнутый круг - или пилить базу, или менять железо и все легко объяснимо.
По поводу

объяснить что на большой базе сложно сделать ТиИ.

, так я вообще то не только про ТИИ сказал. При больших объемах нужно уже не персоналка с гордым название сервер, настоящий сервер (кластер серверов) и уж как минимум раздельно СУБД и сервер 1с существовать должны, а это уже 2 сервере. Всё должно соответствовать одно другому. Почему утверждение, что СУБД преждназаначено для обработки больших объемов понимается что должно работать в любом случае и на любом компьютере?
Вот то что в стакан нельзя поллитровую бутылку налить за раз понимают.....

13. Doomer 12.01.14 13:26 Сейчас в теме

(12) Alex_E, Там стоит IBM-кий сервак с 2-мя процами и 5 SAS-винтами. Оперативки там должно быть в 2 раза больше, но поставщик подвел. Ждем в течении месяца остальную память. Но из обсуждения видно что проблема не в оперативки. Она при формировании отчета не используется в полном объеме. Я не уверен, что смена железа поможет.

8. ansh15 12.01.14 10:43 Сейчас в теме

(1) Doomer,
Поставить все - ОС, PostgreSQL, сервер приложений 1С x86-64, оперативной памяти добавить(если нет) до 64ГБ, хотя бы. PostgreSQL последних версий, 9.1.9 или 9.2.4, на выбор. Удивительно, как база у вас еще выгрузилась в dt, http://downloads.v8.1c.ru/content/Platform/8_2_19_83/Err_Other.htm
Можно еще базе сделать vacuum full analyze, размер базы может ощутимо уменьшиться. ТиИ опять же.
Перечисленное - не панацея, но тот необходимый минимум, для того что бы смотреть дальше, если проблема не уйдет.

9. Doomer 12.01.14 12:31 Сейчас в теме

На сервере 16ГБ ОЗУ. При формировании отчета используется не более 4ГБ ОЗУ. Файл подкачки и так стоит "По выбору системы" по всем дискам. vacuum full analyze делается каждые выходные.

14. Doomer 12.01.14 13:29 Сейчас в теме

+И серверов там 2. Сначала ставил СУБД на один, а сервер 1С:Предприятие на другой. Но после долгих экспериментов пришли к тому то на первом сервере крутятся бухгалтерские базы, а на втором управленческая. Сервера стоят в стойке, в отдельном помещении с кондиционером.

15. Alex_E 2363 12.01.14 13:41 Сейчас в теме

(14) Doomer, Операционки и сервер 1с 64?
Вообще то схема с раздельными серверами 1с и СУБД предпочтительнее, но то что н таком объема проблема именно с железом - СУБД то работает, ошибка связана с нехваткой ресурсов. Есть кстати ещё одн вариант - раз база нетиповая, может стоит посмотреть на тот отчет, из которого она вываливается - бывают случаи, когда простой оптимизацией алгоритма можно получить увеличение быстродействия при снижении ресурсоёмкости.

16. Doomer 13.01.14 00:02 Сейчас в теме

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

17. jigourt 31 13.01.14 00:09 Сейчас в теме

(16) Doomer, глупость конечно, но все-таки, а сама СУБД х64?? ))

18. Doomer 13.01.14 00:17 Сейчас в теме

Нет 32 битная. Попробуем перевести на 64. Но это не простая задача. Предприятие работает очень интенсивно. Только в воскресенье можно будет отключить сервер.

Оставьте свое сообщение

E-mail: