OOM mặc dù có bộ nhớ (bộ nhớ cache)


12

Chúng tôi đã chạy vào kẻ giết người OOM mặc dù gần một nửa bộ nhớ của chúng tôi được sử dụng cho bộ đệm FS. Chúng tôi đã ghi lại số liệu thống kê bộ nhớ một lần mỗi phút (như được báo cáo bởi đầu trang), nhưng dường như có rất nhiều tính khả dụng.

...

Mem:  15339640k total, 15268304k used,    71336k free,     3152k buffers
Swap:        0k total,        0k used,        0k free,  6608384k cached

Mem:  15339640k total, 14855280k used,   484360k free,    13748k buffers
Swap:        0k total,        0k used,        0k free,  6481852k cached

[OOM killer: postgres killed]

Mem:  15339640k total,  8212200k used,  7127440k free,    32776k buffers
Swap:        0k total,        0k used,        0k free,  2394444k cached

...

Chi tiết OOM từ syslog:

...
Jun 10 05:45:25 db kernel: [11209156.840462] wal-e invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:25 db kernel: [11209156.840469] wal-e cpuset=/ mems_allowed=0
Jun 10 05:45:25 db kernel: [11209156.840474] Pid: 7963, comm: wal-e Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:25 db kernel: [11209156.840477] Call Trace:
Jun 10 05:45:25 db kernel: [11209156.840498]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:25 db kernel: [11209156.840502]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:25 db kernel: [11209156.840506]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
Jun 10 05:45:25 db kernel: [11209156.840511]  [<ffffffff8111f823>] __alloc_pages_nodemask+0x8c3/0x8e0
Jun 10 05:45:25 db kernel: [11209156.840520]  [<ffffffff81216e00>] ? noalloc_get_block_write+0x30/0x30
Jun 10 05:45:25 db kernel: [11209156.840528]  [<ffffffff811566c6>] alloc_pages_current+0xb6/0x120
Jun 10 05:45:25 db kernel: [11209156.840534]  [<ffffffff81116637>] __page_cache_alloc+0xb7/0xd0
Jun 10 05:45:25 db kernel: [11209156.840539]  [<ffffffff81118602>] filemap_fault+0x212/0x3c0
Jun 10 05:45:25 db kernel: [11209156.840553]  [<ffffffff81138c32>] __do_fault+0x72/0x550
Jun 10 05:45:25 db kernel: [11209156.840557]  [<ffffffff8113c2ea>] handle_pte_fault+0xfa/0x200
Jun 10 05:45:25 db kernel: [11209156.840562]  [<ffffffff8100638e>] ? xen_pmd_val+0xe/0x10
Jun 10 05:45:25 db kernel: [11209156.840567]  [<ffffffff81005309>] ? __raw_callee_save_xen_pmd_val+0x11/0x1e
Jun 10 05:45:25 db kernel: [11209156.840571]  [<ffffffff8113d559>] handle_mm_fault+0x269/0x370
Jun 10 05:45:25 db kernel: [11209156.840576]  [<ffffffff8100a56d>] ? xen_force_evtchn_callback+0xd/0x10
Jun 10 05:45:25 db kernel: [11209156.840581]  [<ffffffff8100ad42>] ? check_events+0x12/0x20
Jun 10 05:45:25 db kernel: [11209156.840589]  [<ffffffff8165b3cb>] do_page_fault+0x14b/0x520
Jun 10 05:45:25 db kernel: [11209156.840594]  [<ffffffff81160d64>] ? kmem_cache_free+0x104/0x110
Jun 10 05:45:25 db kernel: [11209156.840600]  [<ffffffff811ba2c8>] ? ep_remove+0xa8/0xc0
Jun 10 05:45:25 db kernel: [11209156.840604]  [<ffffffff811bb133>] ? sys_epoll_ctl+0xb3/0x3d0
Jun 10 05:45:25 db kernel: [11209156.840614]  [<ffffffff81658035>] page_fault+0x25/0x30
Jun 10 05:45:25 db kernel: [11209156.840617] Mem-Info:
Jun 10 05:45:25 db kernel: [11209156.840618] Node 0 DMA per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840622] CPU    0: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840624] CPU    1: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840627] CPU    2: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840629] CPU    3: hi:    0, btch:   1 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840631] Node 0 DMA32 per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840634] CPU    0: hi:  186, btch:  31 usd:  30
Jun 10 05:45:25 db kernel: [11209156.840637] CPU    1: hi:  186, btch:  31 usd:  47
Jun 10 05:45:25 db kernel: [11209156.840639] CPU    2: hi:  186, btch:  31 usd:  15
Jun 10 05:45:25 db kernel: [11209156.840641] CPU    3: hi:  186, btch:  31 usd:   2
Jun 10 05:45:25 db kernel: [11209156.840643] Node 0 Normal per-cpu:
Jun 10 05:45:25 db kernel: [11209156.840646] CPU    0: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840648] CPU    1: hi:  186, btch:  31 usd:  14
Jun 10 05:45:25 db kernel: [11209156.840650] CPU    2: hi:  186, btch:  31 usd:   0
Jun 10 05:45:25 db kernel: [11209156.840653] CPU    3: hi:  186, btch:  31 usd:   1
Jun 10 05:45:25 db kernel: [11209156.840658] active_anon:3616567 inactive_anon:4798 isolated_anon:0
Jun 10 05:45:25 db kernel: [11209156.840660]  active_file:98 inactive_file:168 isolated_file:20
Jun 10 05:45:25 db kernel: [11209156.840661]  unevictable:1597 dirty:73 writeback:0 unstable:0
Jun 10 05:45:25 db kernel: [11209156.840662]  free:16921 slab_reclaimable:17631 slab_unreclaimable:7534
Jun 10 05:45:25 db kernel: [11209156.840663]  mapped:1614529 shmem:1613928 pagetables:124012 bounce:0
Jun 10 05:45:25 db kernel: [11209156.840666] Node 0 DMA free:7888kB min:4kB low:4kB high:4kB active_anon:0kB inactive_anon:0kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:7632kB mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:0kB slab_unreclaimable:0kB kernel_stack:0kB pagetables:0kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840681] lowmem_reserve[]: 0 4016 15112 15112
Jun 10 05:45:25 db kernel: [11209156.840686] Node 0 DMA32 free:48368kB min:4176kB low:5220kB high:6264kB active_anon:3776804kB inactive_anon:28kB active_file:0kB inactive_file:20kB unevictable:932kB isolated(anon):0kB isolated(file):0kB present:4112640kB mlocked:932kB dirty:0kB writeback:0kB mapped:1458536kB shmem:1458632kB slab_reclaimable:17604kB slab_unreclaimable:8088kB kernel_stack:1872kB pagetables:190616kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:437 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840698] lowmem_reserve[]: 0 0 11095 11095
Jun 10 05:45:25 db kernel: [11209156.840703] Node 0 Normal free:11428kB min:11548kB low:14432kB high:17320kB active_anon:10689464kB inactive_anon:19164kB active_file:528kB inactive_file:652kB unevictable:5456kB isolated(anon):0kB isolated(file):80kB present:11362176kB mlocked:5456kB dirty:292kB writeback:0kB mapped:4999580kB shmem:4997080kB slab_reclaimable:52920kB slab_unreclaimable:22048kB kernel_stack:2584kB pagetables:305432kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:1974 all_unreclaimable? yes
Jun 10 05:45:25 db kernel: [11209156.840715] lowmem_reserve[]: 0 0 0 0
Jun 10 05:45:25 db kernel: [11209156.840720] Node 0 DMA: 2*4kB 3*8kB 1*16kB 3*32kB 3*64kB 3*128kB 2*256kB 1*512kB 2*1024kB 2*2048kB 0*4096kB = 7888kB
Jun 10 05:45:25 db kernel: [11209156.840752] Node 0 DMA32: 5813*4kB 2636*8kB 114*16kB 15*32kB 5*64kB 1*128kB 1*256kB 0*512kB 1*1024kB 0*2048kB 0*4096kB = 48372kB
Jun 10 05:45:25 db kernel: [11209156.840776] Node 0 Normal: 1888*4kB 10*8kB 46*16kB 4*32kB 3*64kB 2*128kB 1*256kB 1*512kB 0*1024kB 1*2048kB 0*4096kB = 11760kB
Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages
Jun 10 05:45:25 db kernel: [11209156.840790] 0 pages in swap cache
Jun 10 05:45:25 db kernel: [11209156.840801] Swap cache stats: add 0, delete 0, find 0/0
Jun 10 05:45:25 db kernel: [11209156.840803] Free swap  = 0kB
Jun 10 05:45:25 db kernel: [11209156.840805] Total swap = 0kB
Jun 10 05:45:25 db kernel: [11209156.909794] 3934192 pages RAM
Jun 10 05:45:25 db kernel: [11209156.909804] 99282 pages reserved
Jun 10 05:45:25 db kernel: [11209156.909809] 18899146 pages shared
Jun 10 05:45:25 db kernel: [11209156.909811] 2198511 pages non-shared
Jun 10 05:45:25 db kernel: [11209156.909817] [ pid ]   uid  tgid total_vm      rss cpu oom_adj oom_score_adj name
Jun 10 05:45:25 db kernel: [11209156.909835] [  332]     0   332     4308      109   1       0             0 upstart-udev-br
Jun 10 05:45:25 db kernel: [11209156.909845] [  346]     0   346     5384      271   2     -17         -1000 udevd
Jun 10 05:45:25 db kernel: [11209156.909851] [  408]     0   408     5364      174   2     -17         -1000 udevd
...
Jun 10 05:45:25 db kernel: [11209156.910703] [ 7963]   111  7963    17456     2966   0       0             0 wal-e
Jun 10 05:45:25 db kernel: [11209156.910707] [ 7968]   111  7968  1639372     2351   3       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910711] [ 7969]   111  7969  1639371     1934   2       0             0 postgres
Jun 10 05:45:25 db kernel: [11209156.910716] Out of memory: Kill process 12443 (postgres) score 418 or sacrifice child
Jun 10 05:45:25 db kernel: [11209156.910733] Killed process 12443 (postgres) total-vm:6555152kB, anon-rss:4600kB, file-rss:6396572kB
Jun 10 05:45:30 db kernel: [11209159.293083] postgres invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0, oom_score_adj=0
Jun 10 05:45:31 db kernel: [11209159.293091] postgres cpuset=/ mems_allowed=0
Jun 10 05:45:31 db kernel: [11209159.293095] Pid: 6508, comm: postgres Not tainted 3.2.0-43-virtual #68-Ubuntu
Jun 10 05:45:31 db kernel: [11209159.293098] Call Trace:
Jun 10 05:45:31 db kernel: [11209159.293111]  [<ffffffff81119711>] dump_header+0x91/0xe0
Jun 10 05:45:31 db kernel: [11209159.293115]  [<ffffffff81119a95>] oom_kill_process+0x85/0xb0
Jun 10 05:45:31 db kernel: [11209159.293119]  [<ffffffff81119e3a>] out_of_memory+0xfa/0x220
...

Chúng ta có thể thử tăng độ phân giải của chúng lên khoảng một lần mỗi giây, nhưng liệu có lý do nào cho một OOM ở đây không? (Chúng tôi đã thấy http://bl0rg.krunch.be/oom-frag.html nhưng chúng tôi đang làm việc với số lượng bộ nhớ tuyệt đối lớn hơn nhiều, hầu hết được lấy bởi bộ đệm FS của kernel.)

Cũng bao gồm các phần có liên quan postgresql.confdưới đây của chúng tôi :

shared_buffers = 6GB
effective_cache_size = 8GB


Ừm ... 3.2.0-43? Cập nhật thời gian. Kẻ giết người OOM đã trải qua nhiều (quá nhiều) thay đổi theo thời gian. Một số phiên bản thực sự khá hại não về việc sử dụng bộ nhớ dùng chung ... như PostgreQuery 9.2 và máy cũ shared_buffers.
Craig Ringer

@CraigRinger Thật không may, có những cân nhắc khác bao gồm việc gắn với kernel trong bản phân phối Ubuntu 12.04 cho LTS, khả năng tương thích, cập nhật bảo mật, v.v. không quan tâm đến việc thay đổi hiện trạng / làm cho vấn đề biến mất. BTW shared_buffersvẫn còn trong PG9.3.
Yang

shared_buffersvẫn còn trong 9.3, nhưng nó không còn là bộ nhớ chia sẻ POSIX trong 9.3. Nó đã được thay thế bằng một mmap()edkhu vực ẩn danh . Điều đó xoay quanh một số vấn đề cấu hình kernel icky và các vấn đề ghim, mặc dù tôi nghi ngờ nó sẽ khiến kẻ giết OOM bớt bối rối.
Craig Ringer

1
Có thể là bản sao của serverfault.com/questions/288319/ , có câu trả lời tiềm năng.
richvdh

Câu trả lời:


3

Có vẻ như bạn (và tôi trong một trường hợp có triệu chứng rất giống nhau) đã thực sự hết bộ nhớ và đã bị nhầm lẫn bởi con cachedsố.

Rõ ràng có những trường hợp khi Linux không giải phóng bộ nhớ cache đĩa lớn khi nhu cầu bộ nhớ tăng lên

Cụ thể (tôi không thực sự hiểu lý do tại sao), postgres ' shared_bufferscó thể được báo cáo trong phần "Bộ nhớ cache" (bộ đệm trang). Trong trường hợp của bạn 6481852k cachedtopphù hợp với dòng này trong nhật ký các oom-killer của:

Jun 10 05:45:25 db kernel: [11209156.840788] 1615243 total pagecache pages

(1615243 * 4KB ~ = 6481852k) - có nghĩa là bộ đệm trang thực sự không bị loại bỏ trước khi gọi OOM-killer.

Tuy nhiên, có một số trang được hỗ trợ tệp (tôi giả sử active_file:98 inactive_file:168là tương tự với / Proc / meminfo ' Active (tệp) / Không hoạt động (tệp) ), vì vậy đó không phải là các trang bị loại bỏ mà chúng tôi biết và yêu thích.

Bài đăng tại https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-USE/ thể hiện một phiên ví dụ trong đó việc tắt postgres dẫn đến giảm "bộ nhớ cache" theo kích thước của shared_buffers(cuộn đến "Và hầu hết trong số đó đã tắt bộ đệm đĩa - như mong đợi, vì nó được sử dụng cho shared_buffers." ) - thật không may, nó không chỉ ra phiên bản của postgres cũng như kernel được sử dụng cho thử nghiệm.

Tôi đang sử dụng 3.13.0-67 x86_64 với PG 9.3. Trong 9.3, họ đã chuyển từ sử dụng bộ nhớ chia sẻ Sys V ( shmget) sang ẩn danhmmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() (trong 9,4, điều này đã trở thành cấu hình thông qua Dynamic_spl_memory_type ). Nhưng tôi không thể tìm thấy bất kỳ lời giải thích nào về lý do tại sao các mmap () này được hiển thị trong "bộ nhớ cache" và tại sao, chỉ https://access.redhat.com/solutions/406773 có nội dung "Bộ nhớ cache: Bộ nhớ trong pagecache (Diskcache và Bộ nhớ dùng chung) "

Cho rằng có nhiều loại ký ức được chia sẻ, tôi vừa giác ngộ vừa bối rối ...


Sau vài năm, đây là một câu trả lời tốt hơn nhiều, cảm ơn bạn. Vẫn còn câu hỏi tại sao điều này được tính là lưu trữ, nhưng tôi đánh dấu điều này được chấp nhận cho đến bây giờ.
Dương

8
  1. Đối với tình yêu của mọi thứ tốt trên thế giới, hãy định cấu hình không gian hoán đổi trên máy chủ của bạn .
    Bạn thực sự cần không gian trao đổi . Tôi không phải là người duy nhất nói như vậy , đó là một sự thật phổ quát ở đây . (<- Đó là ba liên kết)
    Tất nhiên bạn nên có đủ RAM mà máy chủ cơ sở dữ liệu của bạn không trao đổi thường xuyên - nếu bạn không giải pháp là tiền (bạn lấy nhà cung cấp của bạn và sử dụng để có thêm RAM) .

  2. Vì hiện tại bạn có đủ RAM và trao đổi để sử dụng nếu có sự cố, bạn có thể vô hiệu hóa trình diệt OOM (bằng cách vô hiệu hóa bộ nhớ quá mức), giống như Postgres mà mọi người nói với bạn .
    (Bạn cũng có thể áp dụng giải pháp thay thế của họ và nói với OOM-Killer đừng bao giờ giết Postgres - nhưng sau đó bạn chỉ chơi Russian Roulette với các quy trình còn lại của hệ thống ...)

  3. (tùy chọn) Viết câu trả lời trên Server Fault chi tiết tại sao hành vi mặc định trong hầu hết các bản phân phối Linux là Xấu, Sai và vi phạm đặc tả POSIX về cách hành xử của malloc () . Lặp lại nó cho đến khi mọi người phát ốm vì nghe về nó.


Cũng lưu ý rằng bộ nhớ được lưu trong bộ nhớ cache của hạt nhân có sẵn cho các postgres (hoặc bất kỳ ứng dụng nào khác) để sử dụng - bạn nên tính nó là bộ nhớ trống / có sẵn trong các tính toán của mình.

Nếu tôi phải mạo hiểm đoán xem chuyện gì đang xảy ra ở đây tôi sẽ nói rằng bạn có một truy vấn phức tạp, Postgres đang yêu cầu RAM thực thi nó, và thay vì nói "Tôi không có RAM đó" Linux nói với Postgres "Chắc chắn, bạn có thể có nó."
Sau đó, khi Postgres thực sự cố gắng sử dụng RAM, được cho là Linux đã nhận ra rằng nó không RAM mà nó đã hứa với Postgres (vì nó quá mức) - kẻ giết người OOM được yêu cầu giải phóng RAM và giết chết chương trình một cách nghiêm túc bộ nhớ nhiều nhất - máy chủ cơ sở dữ liệu của bạn.

Postgres là một chương trình được thiết kế tốt. Nếu được bảo là không có RAM, nó sẽ yêu cầu nó xử lý một cách duyên dáng (bằng cách thực hiện với ít hơn hoặc hủy bỏ bằng tin nhắn cho người dùng).


4
Cảm ơn bạn đã xây dựng trao đổi, nhưng điều này không trả lời câu hỏi của tôi về lý do tại sao điều này xảy ra ở nơi đầu tiên . Vâng, tôi hiểu tiền đề cơ bản rằng Linux vượt quá mặc định và OOM là khi chúng tôi hết RAM - tôi có thể đã nói điều này nhiều trong câu hỏi ban đầu của tôi. Nhưng câu hỏi đặt ra là tại sao nó lại khởi động khi tôi vẫn còn nhiều RAM (phần lớn chỉ nằm trong bộ đệm của FS)? Giả sử tôi thậm chí không quan tâm đến việc thay đổi bất cứ điều gì - rằng kẻ giết người OOM vẫn ổn, miễn là tôi hiểu tại sao nó được kích hoạt.
Yang

2
Sau khi xem xét các liên kết, không may có một số xác nhận mà không có bằng chứng ủng hộ hoặc giải thích kỹ thuật cụ thể. Chắc chắn có nhiều môi trường Linux nơi trao đổi thậm chí không phải là một tùy chọn (ví dụ: không tìm kiếm gì ngoài Live CD nơi không có phân vùng trao đổi cục bộ hiện có để sử dụng lại). Hơn nữa, chúng tôi không quan tâm đến việc kích hoạt tính dễ thay đổi dựa trên kinh nghiệm và môi trường của chính chúng tôi - chúng tôi muốn có OOM. Một câu trả lời cho câu hỏi ban đầu sẽ được đánh giá cao.
Yang

1
@Yang Tôi giả sử rằng nếu bạn đang xây dựng một máy chủ cho Postgres, bạn sẽ muốn làm theo các đề xuất của dự án Postgres. Câu trả lời của tôi là làm những gì họ nói với bạn (tắt kẻ giết người OOM). Nếu bạn muốn chờ xem ai đó cung cấp cho bạn một câu trả lời khác, bạn chắc chắn sẽ tự do làm điều đó, nhưng tôi không thoải mái đưa ra bất kỳ giải pháp nào khác - Theo tôi, kẻ giết người OOM là Xấu, Sai và vi phạm POSIX. Nó có thể được chấp nhận trên máy tính để bàn / worstation, nhưng vô hiệu hóa nó trên các máy chủ là, IMO, Điều phải làm.
voretaq7

2
Tôi đã chạy qua tình huống này trên một máy chủ có trao đổi và sau khi bão hòa bộ nhớ khả dụng + hoán đổi, kẻ giết người OOM đã được sử dụng thay vì kernel lấy lại bộ nhớ "đã lưu trong bộ nhớ cache, rõ ràng đã bị khóa. Tôi không bao giờ giải quyết vấn đề, nhưng câu hỏi ban đầu của @ Yang không được trả lời ở đây.
Patrick

2
Hoán đổi không phải là câu trả lời, nó chỉ làm cho vấn đề xuất hiện sau đó. Bạn cần trao đổi khi RAM đầy và bạn cần OOM Killer khi RAM + trao đổi đầy. Nếu số lượng trao đổi bằng 0, bạn cần OOM Killer sớm hơn nhưng bạn không thể tránh OOM Killer bằng trao đổi.
Mikko Rantalainen
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.