Sql error 53200

Популярные сообщения из этого блога

06.09.17 — 08:02

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) они равны

(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.

Thanks for contributing to pgloader by reporting an
issue! Reporting an issue is the only way we can solve problems, fix bugs,
and improve both the software and its user experience in general.

The best bug reports follow those 3 simple steps:

1. My command file:

LOAD DATABASE
    FROM mysql://dps:@localhost/XXXXXXX
    INTO postgresql://xxxxx:xxxxx@192.168.xx.xx/XXXXXXX

WITH workers = 4, concurrency = 2;

1. Results

Heap exhausted during garbage collection: 0 bytes available, 48 requested.
 Gen StaPg UbSta LaSta LUbSt Boxed Unboxed LB   LUB  !move  Alloc  Waste   Trig    WP  GCs Mem-age
   0:     0     0     0     0     0     0     0     0     0        0     0 42949672    0   0  0.0000
   1:     0     0     0     0     0     0     0     0     0        0     0 42949672    0   0  0.0000
   2:     0     0     0     0     0     0     0     0     0        0     0 42949672    0   0  0.0000
   3: 123995 123996     0     0 13084 73279   227     0   226 2817738000 19643120 1271620360    0   1  1.2103
   4: 130992 131071     0     0  5735 28068  6051     0     2 1295775984 10159888  2000000    0   0  0.0000
   5:     0     0     0     0     0     0     0     0     0        0     0  2000000    0   0  0.0000
   6:     0     0     0     0  3437  1191     0     0     0 151650304     0  2000000 3270   0  0.0000
   Total bytes allocated    = 4265164288
   Dynamic-space-size bytes = 4294967296
GC control variables:
   *GC-INHIBIT* = true
   *GC-PENDING* = true
   *STOP-FOR-GC-PENDING* = false
fatal error encountered in SBCL pid 2093(tid 140737042183936):
Heap exhausted, game over.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.

Additionally, further attempts to modify the schema directly with PSQL give the following error:

psql (10.6 (Ubuntu 10.6-0ubuntu0.18.04.1))
Type "help" for help.

xxxxx=# DROP SCHEMA xxxxxxxxx CASCADE;
ERROR:  out of shared memory
HINT:  You might need to increase max_locks_per_transaction.

Additionally, further attempts to preform the load result in the following:

2019-01-17T20:14:35.034000Z NOTICE Starting pgloader, log system is ready.
2019-01-17T20:15:22.600000Z NOTICE Prepare PostgreSQL database.
2019-01-17T20:15:22.606000Z NOTICE DROP SCHEMA xxxxxxxxxxx CASCADE;
2019-01-17T20:15:22.807000Z ERROR Database error 53200: out of shared memory
HINT: You might need to increase max_locks_per_transaction.
QUERY: DROP SCHEMA xxxxxxxxxxxx CASCADE;
2019-01-17T20:15:22.807000Z FATAL Failed to create the schema, see above.
2019-01-17T20:15:22.807000Z LOG report summary reset
       table name       read   imported     errors      total time       read      write
-----------------  ---------  ---------  ---------  --------------  ---------  ---------
  fetch meta data       9908       9908          0         13.231s                     
   Create Schemas          0          0          0          0.000s                     
-----------------  ---------  ---------  ---------  --------------  ---------  ---------

1. explain how the result is not what you expected.

I have loaded prior versions of the same schema with pgloader without error.
I would expect this schema to work the same.

In the case of pgloader, here’s the information I will need to read in your
bug report. Having all of this is a big help, and often means the bug you
reported can be fixed very efficiently as soon as I get to it.

Please provide the following information:

• pgloader —version

pgloader version «3.4.1»
compiled with SBCL 1.3.3.debian

and

pgloader version «3.5.2~devel»
compiled with SBCL 1.4.14

Both have the same issue

• did you test a fresh compile from the source tree?
  Yes
• did you search for other similar issues?
  Yes
• how can I reproduce the bug?
  The data is propriety