06.09.17 — 08:02
Добрый день,прошу помощи в решении проблемы
пользую 1с 8.3.9.2309 + PostgreSql 9.4.2-1.1C происходит ошибка при загрузке базы dt ,ошибка 53200 error out of memory detail failed on request of size 536870912
ОС windows server 2016 standard,аналогичная проблема и на других ос
Пробовал менять настройки конфига pg,сейчас они такие
Это из основных как я полагаю интересующих :
shared_buffers = 64MB # min 128kB
temp_buffers = 256MB # min 800kB
work_mem = 128MB # min 64kB
maintenance_work_mem = 256MB # min 1MB
effective_cache_size = 6GB
——————————————
Всего оперативной памяти 16gb
Причём конкретно только одна база не загружается (она исправна,её тестировал БП 2.0)
ещё пробовал увеличить файл подкачки на диске С
Помогите кто сталкивался с такой же проблемой?кто её решил?
1 — 06.09.17 — 08:10
разрядность PostgreSql какая?
2 — 06.09.17 — 08:12
(1) 64 разрядная как и windows server
3 — 06.09.17 — 08:21
В логе вот что пишет:
pg_authid_rolname_index: 1024 total in 1 blocks; 552 free (0 chunks); 472 used
MdSmgr: 8192 total in 1 blocks; 6544 free (0 chunks); 1648 used
LOCALLOCK hash: 8192 total in 1 blocks; 2880 free (0 chunks); 5312 used
Timezones: 79320 total in 2 blocks; 5968 free (0 chunks); 73352 used
ErrorContext: 8192 total in 1 blocks; 8176 free (0 chunks); 16 used
2017-09-04 18:55:43 MSK ERROR: out of memory
2017-09-04 18:55:43 MSK DETAIL: Failed on request of size 536870912.
2017-09-04 18:55:43 MSK CONTEXT: COPY config, line 328, column binarydata
2017-09-04 18:55:43 MSK STATEMENT: COPY Config FROM STDIN BINARY
4 — 06.09.17 — 08:21
попробуй в work_mem указать немного больше чем от тебя просят
5 — 06.09.17 — 08:22
ставил 256 и 512
6 — 06.09.17 — 08:22
и да, этот ДТ куда-то вообще загружается? Он точно не битый?
7 — 06.09.17 — 08:23
(5) переведи «on request of size 536870912»
8 — 06.09.17 — 08:25
(6) Да как файловая база он загружается
9 — 06.09.17 — 08:27
(6) и точно не битый делал тестирование и исправление и chdbfl,без ошибок
10 — 06.09.17 — 08:30
(7)размер по запросу 536870912,полагаю что не хватает памяти загрузить какую то таблицу
11 — 06.09.17 — 08:31
а где её увеличить!?или может какой то другой параметр нужно увеличить
12 — 06.09.17 — 08:34
(11) 536 больше 512?
13 — 06.09.17 — 08:36
(12) я понял к чему ты,я пробовал и 1024 ставить
14 — 06.09.17 — 08:36
(12) но вот только не везде
15 — 06.09.17 — 08:39
Попробую work_mem выставить > 536 ,но смогу попробовать вечером
16 — 06.09.17 — 08:52
(15) сделай сразу побольше чтобы наверняка
17 — 06.09.17 — 09:07
(16) да 1024 поставлю,отпишусь по результату
18 — 06.09.17 — 09:20
и temp_buffers тоже.
19 — 06.09.17 — 09:30
shared_buffers рекомендуется делать побольше. 1/4 — 1/3 RAM.
maintenance_work_mem в 1/2 RAM или больше (до RAM-shared_buffers)
20 — 06.09.17 — 09:40
(19) если не ошибаюсь то пробовал я ставить и больше 1 gb в
shared_buffers или temp_buffers служба pg перестаёт запускаться
21 — 06.09.17 — 11:01
(16) Попробывал,выставить 1024 work_mem,shared_buffers,temp_buffers ошибка всё равно выходит
22 — 06.09.17 — 11:04
Увидел вот какой момент,в свойствах Pg есть строка версии где написано PostgreSQL 9.4.2,complited by Visual C++ build 1500, 32-bit
23 — 06.09.17 — 11:06
мне эта строка не нравится,типа используются компоненты Visual C++ 32 бита,посмотрел на давно созданном сервере тоже на pg там 64 стоит м.б дело в этом!?
24 — 06.09.17 — 11:26
Похоже что да,вроде как ура..грузит ,но ошибку не выкидывает
25 — 06.09.17 — 11:36
победа,парни дико извиняюсь,3 дня не в ту сторону смотрел,не тот дистрибутив поставил поставил общий,а надо было postgresql-9.4.2-1.1C_x64
26 — 06.09.17 — 11:49
(25) Теперь научился отличать приложения х64 от х86?
27 — 06.09.17 — 11:55
(12) они равны
Johan
28 — 06.09.17 — 12:35
(26) Да,я поставил не посмотрев,а в описании в pg и сервис написано 64 Bit,а вот когда увидел строку версии ,тогда меня смутило
DBA’s occasionally experience “out of memory” errors that can cause failed queries and degrade system performance. Fortunately, the Greenplum Database provides facilities to avoid this.
We will discuss two of those facilities: the gp_vmem_protect_limit parameter, and Greenplum resource queues. The parameters and techniques mentioned here are explained in detail in the Greenplum Database Administrator Guide.
The gp_vmem_protect_limit parameter: The “gp_vmem_protect_limit” parameter sets the amount of memory that all processes of an active segment instance can consume. Queries that cause the limit to be exceeded will be cancelled.
Note that this is a local parameter and must be set for each segment in the system. The system must be restarted for parameter changes to take effect.
How to set the gp_vmem_protect_limit
As a general rule-of-thumb, gp_vmem_protect_limit should be set to:
( X * physical_memory_in_MB ) /#_of_primary_segments
X should be a value between 1.0 and 1.5. A value of X=1.0 offers the best overall system performance; a value of X=1.5 may impact system performance because of swap activity but will result in fewer canceled queries.
For example, to set gp_vmem_protect_limit conservatively (X=1.0) on a segment host with 16GB (16384 MB) of physical memory with 4 primary segment instances, the calculation would be: (1 * 16384) / 4 = 4096.
The MEMORY_LIMIT parameter for Greenplum Resource Queues:Greenplum resource queues provide a way to manage and prioritize workloads. Resource queues can be created with a MEMORY_LIMIT setting to restrict the total amount of memory that queries can consume in any segment instance. Queries that cause a queue to exceed the MEMORY_LIMIT must wait until queue resources are free before they can execute.
By assigning each user to a queue and limiting the amount of memory queues can consume, administrators can ensure proper resource allocation across the system.
Note that roles with the SUPERUSER attribute are exempt from queue limits.
How to set MEMORY_LIMIT to avoid Out of Memory errors:As a general rule-of-thumb, the sum of all the MEMORY_LIMITs across all the queues should be no more than 90% of the gp_vmem_protect_limit.
Common Out of Memory Errors
The two most common errors are described below. They look similar but have different reasons and solutions.
Error code 53200
Example:
«ERROR»,»53200″,»Out of memory. Failed on request of size 156 bytes. (context ‘CacheMemoryContext’) (aset.c:840)»
Description:
The system canceled a query because a segment server’s OS did not have enough memory to satisfy a postmaster process allocation request.
How to Avoid
1. Set gp_vmem_protect_limit according to the formula above.
2. Adding memory can help greatly if lowering gp_vmem_protect_limit results in too many canceled queries.(Gp_vmem_protect_limit can be raised after adding memory.)
3. Adding swap space may help, although increased swap activity will impact system performance.
Error code 53400
Example
«ERROR»,»53400″,»Out of memory (seg13 slice13 sdw1-1:40001 pid=10183)»,»VM Protect failed to allocate 8388608 bytes, 6 MB available»
Description
The system canceled a query because a postmaster process tried to request more memory than the gp_vmem_protect_limit parameter allows.
How to Avoid
1. Make sure the sum of all MEMORY_LIMITs across all active queues is <= 90% of gp_vmem_protect_limit.
2. Increase gp_vmem_protect_limit, if possible, using the formula described above.
3. Ensure the system is not unbalanced (i.e., some segments down). Use gpstate -e to verify.
Collectives™ on Stack Overflow
Find centralized, trusted content and collaborate around the technologies you use most.
Learn more about Collectives
Asked
4 years, 6 months ago
Viewed
627 times
I’m getting the following error:
ERROR: out of memory DETAIL: Failed on request of size 23.
********** Error **********ERROR: out of memory SQL state: 53200 Detail: Failed on request of
size 23.
Can somebody help me understand how to resolve it?
- postgresql
- pgadmin-4
asked Aug 5, 2018 at 6:26
3
-
I can’t help as I’ve never had this issue, but maybe you should say what exactly yo’re doing to get the error.
Aug 5, 2018 at 14:52
-
First you’ll have to figure out if the errors comes from the server or the client. If from the server, share the memory dump from the log. Make sure to add the offending query to the question.
Aug 6, 2018 at 6:04
-
@LaurenzAlbe Increased RAM of the host. Seemed to solve the issue. This error did not occur again.
Aug 10, 2018 at 6:56
- The Overflow Blog
- Featured on Meta
Related
Hot Network Questions
-
Did Malaysia flight 370 have a ELT on board?
-
How would I create a flowing, gradually turning UV Map for a model? (Have pictures)
-
How to exactly calculate the volume?
-
Is there a word for ‘evangelism’ that doesn’t necessarily specify the religion?
-
Should one’s bum be behind, or merely over, the lowered saddle on steeper descents?
-
Why would the government invest in creating skilled labor, and then send them to work overseas?
-
Why are some pH standard solutions 6.86 and 9.18?
-
How to get better at taking constructive criticism
-
How to temporarily catch leaks trickling down the outside of a pipe
-
What does squaring a vector mean?
-
I screwed up a talk — how to move on
-
singly linked list optimally defined over operations in C?
-
I’m new to D&D: where to begin?
-
Are most real functions non-linear?
-
Why expl3 conflicts with «gather» environment?
-
Income limits between 401k and IRAs
-
Leaking Bathroom Sink Water Supply Valve
-
Most amiable coastal geographic conditions for harbors?
-
The Celtic word «al» in Latin?
-
Any idea what this keyboard layout is?
-
How can I make a reliable tick tock sound electro-mechanically?
-
Does the Hamiltonian formulation of classical mechanics require an inner product on physical space?
-
Can a DC voltage source be used for a transformer?
-
Can PC1 explain more than 90% of variance?
more hot questions
Question feed
Your privacy
By clicking “Accept all cookies”, you agree Stack Exchange can store cookies on your device and disclose information in accordance with our Cookie Policy.
Описание ошибки:
Платоформа 1С: Предприятие 8.3.16.1148. Клиент-серверный вариант работы базы на СУБД PostgreSQL. Ошибка втречалась при попытке выгрузить базу через «Администрирование» — «Выгрузить информационную базу…», т.е. при попытке выгрузить информационную базу в архив .dt.
Найденные решения:
Как было указано в кратком описании ошибки — база клиент-серверная на СУБД PostgreSQL. Логично, если перевести формулировку «out of memory for query result» — «недостаточно памяти для результата запроса». Так же само «Ошибка СУБД» отправляет решать проблему не на стороне 1С, а на сторону СУБД. Поэтому необходимо изменить параметры использования ресурсов сервера — естественно в сторону увеличения объема используемых ресурсов. В СУБД PostgreSQL это делается путем редактирования соответствующего файла «postgresql.conf», который по умолчанию находится (при установке с параметрами «по умолчанию») в «C:Program Files (x86)PostgreSQL9.4.2-1.1Cdata» для x32-версии и в «C:Program FilesPostgreSQL9.4.2-1.1Cdata» для x64-версии.
В этот статье нет смысла описывать актуальные параметры настроек файла конфигурации «postgresql.conf», в помощь по этому вопросу соответствующая исчерпывающая публикация на сайте профессионального сообщества infostart.ru:
Настройка PostgreSQL для работы в связке с 1С 8.х на ОС Windows
После изменения и сохранения параметров в «postgresql.conf». Необходимо перезапустить службу «PostgreSQL Database Server …» в «Службах» операционной системы Windows сервера, чтобы новые параметры вступили в силу.
Если все-таки не получилось изменить параметры использования ресурсов в файле конфигурации СУБД «postgresql.conf» по каким-либо причинам, то попробуйте выполнить операцию, которая завершается ошибкой «Ошибка СУБД: out of memory for query result» не на самом сервере, а на одном из клиентских рабочих мест. Если не получится на одном, то попробуйте на другом — на практике так получалось обходить ошибку.
Оцените, помогло ли Вам предоставленное описание решения ошибки?
© www.azhur-c.ru 2014-2020. Все права защищены. Использование текстов и изображений с данной страницы без письменного разрешения владельца запрещено. При использовании материалов с данной страницы обязательно указание ссылки на данную страницу.
22-09-2020
Журавлев А.С.
(Сайт azhur-c.ru)
Добрый день. Есть ли какой-то примерный порядок поиска источника ошибки
out of memory (куда копать)?
Сегодня начала падать ошибка сначала в запросе мониторинга select size, twice_used, dirty from mamonsu.buffer_cache() затем, буквально через пару минут, начали валиться самые разные запросы и так продолжалось в половине сессий из пула вплоть до рестарта БД. Возможно, какое-то из расширений течёт, но как выяснить, какое?
Ошибки в логах примерно такие:
TopMemoryContext: 354816 total in 12 blocks; 65144 free (230 chunks); 289672 used
… (детализация памяти)
Grand total: 85437656 bytes in 13128 blocks; 23729928 free (3503 chunks); 61707728 used
2022-04-05 14:59:44 MSK [15654]: [49-1] ERROR: out of memory
2022-04-05 14:59:44 MSK [15654]: [50-1] DETAIL: Failed on request of size 5064 in memory context «ExecutorState».
2022-04-05 14:59:44 MSK [15654]: [51-1] STATEMENT: … (запросы падают самые разные)
Версия postgresql 12.10. Настройки БД примерно такие:
shared_buffers=6GB
work_mem=64MB;
shared_preload_libraries=pg_stat_statements, pg_wait_sampling;
Используемые расширения: btree_gin, btree_gist, dblink, lo, pg_background, pg_trgm, pgcrypto, plpgsql, plpgsql_check, plpython3u, tablefunc, pg_buffercache, pg_stat_statements, pg_wait_sampling
Всего на сервере 16Гб, в момент появления массовых ошибок, судя по мониторингу, на сервере оставалось доступно 4Гб.
russian
programming
pgsql
17
ответов
cat /proc/sys/vm/overcommit_memory
ну вот и причина. попробуй 0 
Mikhail Zhilin
ну вот и причина. попробуй 0
Не надо такое советовать на СУБД.
Mikhail Zhilin
ну вот и причина. попробуй 0
эм… там всё как надо, собственно. если сделать 0, то придёт OOM и сложит всю базу
Скорее всего, память сильно фрагментирована, при попытке выделись целым куском, ОС показывает СУБД кукиш. Соответственно, надо поиграться с huge pages (сам не игрался, деталей по этому не подскажу).
ЗЫ. Праздного интересу для вопрос: вот этот весь список — он реально необходим, или обсуждаемый инстанс — он для разработки и прочих поиграться?
Михаил Шурутов
ЗЫ. Праздного интересу для вопрос: вот этот весь с…
Если вы про расширения, то:
btree_gin, btree_gist, pgcrypto, lo, pg_background, pg_trgm, plpgsql, plpython3u — используются напрямую в проекте в той или иной степени
plpgsql_check — нужна, чтобы не развернуть кривой код (настроен триггер, который проверяет код при create function)
dblink, tablefunc — вот эти, наверное, относятся к устаревшему функционалу
pg_buffercache, pg_stat_statements, pg_wait_sampling — ну а это мониторинг
На разработческом инстансе еще пара расширения стоит (включая pldbgapi)
Михаил Шурутов
Скорее всего, память сильно фрагментирована, при п…
Для ликвидации безграмотности подскажите пожалуйста что такое фрагментация памяти и как ее измерить?
Victor Yegorov
эм… там всё как надо, собственно. если сделать 0, …
Возможно. Хотя ведь и сейчас базе и так приходит ошибка, хотя память ещё свободная есть. Какой может быть совет в данном случаи? Поднимать уровень оверкоммита?
Mikhail Zhilin
Возможно. Хотя ведь и сейчас базе и так приходит о…
сейчас обламывается один запрос. когда придёт OOM — сложится вся база (перезапуск с восстановлением из транзакционного лога от последней контрольной точки)
надо смотреть на кол-во памяти, настройки и сам запрос
Victor Yegorov
сейчас обламывается один запрос. когда придёт OOM …
Это похоже на какоето преуменьшение проблемы. Человек пишет что 30 минут база просто лежала, и помог только рестарт. Откуда информация про один запрос? 🤔
Mikhail Zhilin
Это похоже на какоето преуменьшение проблемы. Чел…
а что значит “просто лежала”? если основные запросы падали с ошибкой, то могло выглядеть как отказ базы для приложения.
а что происходило на сервере с базой? какие там, помимо самой базы, программы работают?
как долго сессии в базе живут?
что происходит в сессиях — есть ли курсоры? если ли prepared statement-ы? используются ли временные таблицы?
Victor Yegorov
а что значит “просто лежала”? если основные запрос…
на сервере кроме СУБД только мониторинг и системные сервисы. Когда проблема началась, в htop процесс postgres: checkpointer занимал 38% памяти. БД, вроде, работала (мне кажется, простые запросы даже проходили, но запросы посложнее — нет).
С БД работают около 10 разных пулов подключений, в каждом пуле в пределе может быть от 5 до 25 подключений (25 только в двух из них). idle-сессии из пулов прибиваются, но поддерживается минимум по 2-5 подключений, так что, в теории, могут быть сессии, живущие по много дней.
Явно объявленные курсоры не используются. Prepared statement-ы могут создаваться (вроде, jdbc-драйвер их создаёт только после пары запусков одинакового запроса). Да, есть несколько запросов с текстом длиннее 20кб (если это имеет значение)
Михаил Шурутов
Скорее всего, память сильно фрагментирована, при п…
Впервые слышу, что такое возможно.
Ну, по идее: фрагмениацыя до отсутствия contiguous segment у 64 бит виртуальной памяти — просто невозможна. Неуспеть, да и не забить дажэ самыми маленькими сегментами.
А фрагментацыю физической на 4к страницы — так их всегда можно перетасовать как угодно (дажэ вообще в своп выгрузить).
В момент — хорошо бы strace напустить на процэсс. Посмотреть, что он там не можэт — brk() иои mmap /dev/zero, или что-то ещё. Можэт, там open обламывается и дескрипторов нехватает!
Плюс, лимиты процэсса посмотреть.