OOM, незважаючи на наявну пам'ять (кеш)

Ми натрапили на вбивцю OOM, незважаючи на те, що майже половину нашої пам'яті використовується для кешу FS. Ми реєстрували статистику пам'яті один раз на хвилину (як повідомляється вгорі), але, схоже, є достатня кількість доступності.

...

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

...

Деталі OOM з 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
...

Ми можемо спробувати збільшити роздільну здатність їх приблизно раз на секунду, але чи існуватиме якась причина для МОМ? (Ми бачили http://bl0rg.krunch.be/oom-frag.html, але ми працюємо зі значно більшими абсолютними обсягами пам'яті, більшість з яких займає кеш-пам'ять FS ядра.)

Також, включаючи відповідні частини нашого postgresql.confнижче:

shared_buffers = 6GB
effective_cache_size = 8GB

postgresql oom

— Ян
джерело

Обговорення в чаті, пов'язане

— Ян

Гм ... 3.2.0-43? Час оновлення. Вбивця OOM з часом зазнав багатьох (занадто багато) змін. Деякі версії насправді були дуже задумливими щодо обліку використання спільної пам'яті ... як PostgreSQL 9.2 та старші shared_buffers.

— Крейг Рінгер

@CraigRinger На жаль, є й інші міркування, зокрема дотримання ядра в дистрибутиві Ubuntu 12.04 для LTS, сумісності, оновлень безпеки тощо. Нас просто цікавить, якщо хтось знає, як пояснити, що відбувається тут - якщо це допомагає, зроби вигляд, що ми не зацікавлений у зміні статусу / усуненні проблеми. BTW shared_buffersвсе ще знаходиться в PG9.3.

— Ян

Так, shared_buffersце все ще в 9.3, але це більше не поділена пам'ять POSIX у 9.3. Його замінено на анонімний mmap()edрегіон. Це оточує деякі проблеми з конфігурацією ядра та проблеми з усуненням, хоча я сумніваюся, що це зробить вбивцю OOM менш заплутаною.

— Крейг Рінгер

Можливо, дублікат сервера defaultfault.com/questions/288319/… , який має потенційну відповідь.

— richvdh

Відповіді:

Здається, у вас (і у випадку з дуже схожими симптомами) у вас справді не вистачає пам’яті і їх плутає cachedчисло.

Мабуть, є випадки, коли Linux не звільняє кеш-пам'ять великого диска, коли попит на пам'ять збільшується

Зокрема (я не дуже розумію, чому), про постгреси shared_buffersможна повідомити у розділі "Кешування" (кеш сторінки). У вашому випадку 6481852k cachedв topматчах цього рядка в журналі ООМ-вбивці:

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

(1615243 * 4KB ~ = 6481852k) - значить кеш сторінки дійсно не було відкинуто до виклику OOM-убивці.

Тим не менш, є декілька файлів, що підтримуються файлами (я припускаю, що active_file:98 inactive_file:168це схоже на Active / файл / proc / meminfo's (файл) / Неактивні (файл) ), тому це не ті сторінки, які можна скасувати, які ми знаємо і любимо.

Публікація за адресою https://www.depesz.com/2012/06/09/how-much-ram-is-postgresql-using/ демонструє приклад сеансу, коли вимкнення постгресів призводить до зменшення "кешованих" розмірів shared_buffers(прокрутіть до "І більша частина цього вийшла з дискового кешу - як очікувалося, тому що він використовувався для shared_buffers." ) - на жаль, він не вказує версію поштових повідомлень та ядро, яке було використано для експерименту.

Я використовую 3.13.0-67 x86_64 з PG 9.3. У 9.3 вони перейшли з використання спільної пам’яті Sys V ( shmget) на анонімнуmmap(...R+W, MAP_SHARED|MAP_ANONYMOUS|MAP_HASSEMAPHORE...)+fork() (у 9.4 це стало налаштовуватися за допомогою динамичного_типу__типового_типу ). Але я не зміг знайти жодних пояснень, чому ці mmap (s) повинні відображатися в "кешованому" режимі і чому, лише https://access.redhat.com/solutions/406773, що говорить "Кешовано: Пам'ять у pagecache (дисковий кеш і спільна пам'ять) "

Враховуючи, що існує багато видів спільної пам'яті, я і просвітлений, і розгублений ...

— Миколай
джерело

Через кілька років це набагато краща відповідь, дякую. Досі залишається питання, чому це вважається кешованим, але я зараз відзначаю це прийнятим.

— Ян

Для любові до всього хорошого у світі налаштуйте простір на своїх серверах .
Вам дійсно потрібен обмінний простір . Я не єдиний, хто так говорить , це майже універсальна правда . (<- це три посилання)
Ви, звичайно, повинні мати достатню кількість оперативної пам’яті, щоб сервер вашої бази даних не регулярно мінявся - якщо ви не вирішите це гроші (які ви берете у свого постачальника і використовуєте для придбання більшої кількості оперативної пам’яті) .
Оскільки тепер у вас є адекватна оперативна пам’ять, і ви можете її замінити, якщо щось пішло не так, ви можете відключити вбивцю OOM (відключивши перезарядку пам'яті), як говорять вам люди Postgres .
(Ви також можете застосувати їх альтернативне рішення і сказати УМО-вбивці ніколи не вбивати Postgres - але тоді ви просто граєте в російську рулетку з рештою процесів вашої системи ...)
(необов’язково) Напишіть відповідь на помилку сервера, де детально пояснюється, чому поведінка за замовчуванням у більшості дистрибутивів Linux погана, неправильна та порушує специфікацію POSIX щодо того, як має вести себе malloc () . Повторюйте це, поки всім не нудно почути про це.

Також зауважте, що кешована пам'ять ядра доступна для постгресів (або будь-якої іншої програми), яку слід використовувати - ви повинні враховувати її як вільну / доступну пам'ять у своїх розрахунках.

Якби мені довелося загрожувати здогадками щодо того, що відбувається тут, я б сказав, що у вас складний запит, Postgres просить оперативної пам’яті виконати його, а не казати «У мене немає такої оперативної пам’яті» Linux повідомляє Postgres «Звичайно, ти можеш її мати ».
Тоді , коли Postgres на насправді намагається використовувати оперативну пам'ять це було (імовірно) даний Linux розуміє , що це НЕ МАТИ оперативну пам'ять він обіцяв Postgres (бо вона перевантажена) - ОИЙ вбивця сказав , щоб звільнити оперативну пам'ять, і слухняно вбиває програму , використовуючи сама пам'ять - ваш сервер бази даних.

Postgres - це добре розроблена програма. Якщо йому сказано, що не може мати оперативної пам’яті, вона запитує, вона буде справлятись це витончено (або робити менше, або припиняючи повідомлення користувачеві).

— voretaq7
джерело

Дякую за розробку щодо свопу, але це не відповідає на моє запитання, чому це відбувається в першу чергу . Так, я розумію основну передумову, що Linux за замовчуванням переборює, і що OOM є, коли ми втрачаємо оперативну пам’ять - я міг би сказати це багато в своєму первісному запитанні. Але питання полягає в тому, чому це стартує, коли в мене ще багато оперативної пам’яті (значна частина просто сидить у кеш-пам'яті FS)? Припустимо, мене навіть не цікавить щось змінити - що вбивця OOM добре, доки я розумію, чому це спрацьовує.

— Ян

Переглянувши посилання, на жаль, існує ряд тверджень без підтвердження доказів або конкретних технічних пояснень. Звичайно, існує безліч середовищ Linux, де своп - це навіть не варіант (наприклад: дивіться далі, ніж Live CD, де вже не існує існуючого локального розділу для повторного використання). Крім того, ми не зацікавлені в тому, щоб забезпечити простоту, базуючись на власному досвіді та оточенні - ми швидше матимемо ОМУ. Відповідь на оригінальне запитання буде вдячна.

— Ян

@Yang Я припускаю, що якщо ви будуєте сервер для Postgres, ви хочете дотримуватися рекомендацій проекту Postgres. Моя відповідь - робити те, що вони вам скажуть (вимкніть вбивцю OOM). Якщо ви хочете зачекати і побачити, чи хтось пропонує вам іншу відповідь, ви, безумовно, можете це зробити, але мені не комфортно пропонувати будь-яке інше рішення - на мою думку, вбивця OOM поганий, неправильний і порушує POSIX. Це може бути прийнятним на робочому столі / станції, але вимкнути його на серверах - IMO, The Right Thing To Do.

— voretaq7

Я зіткнувся з цією ситуацією на сервері, який має своп, і після насичення доступної пам’яті + своп, вбивця OOM був використаний замість ядра, що відновлює «кешовану» пам’ять, яка, очевидно, якось заблокована. Я ніколи не вирішував це питання, але оригінальне запитання @ Ян не відповідає тут.

— Патрік

Заміна - це не відповідь, вона лише змушує проблему з’явитися пізніше. Вам потрібен swap, коли оперативна пам'ять заповнена, і вам потрібен OOM Killer, коли RAM + своп буде заповнений. Якщо сума свопу дорівнює нулю, вам знадобиться OOM Killer раніше, але ви не можете уникнути OOM Killer за допомогою своп.

— Мікко Ранталайнен