Bug #1177
closedNa mentat.cesnet.cz se občas ozve OOM-killer
0%
Description
Trochu jsem zkoumal a myslím, že už si zaslouží vlastní bug, ať máme info pohromadě.
Příklad:
Aug 26 16:20:55 mentat kernel: [11855389.517745] mentat-sensor invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 Aug 26 16:20:55 mentat kernel: [11855389.517752] mentat-sensor cpuset=/ mems_allowed=0-1 Aug 26 16:20:55 mentat kernel: [11855389.517756] Pid: 21940, comm: mentat-sensor Not tainted 2.6.32-5-amd64 #1 Aug 26 17:22:49 mentat kernel: [11859102.984747] mentat-wardenin invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 Aug 26 17:22:49 mentat kernel: [11859102.984752] mentat-wardenin cpuset=/ mems_allowed=0-1 Aug 26 17:22:49 mentat kernel: [11859102.984756] Pid: 21985, comm: mentat-wardenin Not tainted 2.6.32-5-amd64 #1 Aug 27 16:34:32 mentat kernel: [11942606.528269] mongod invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 Aug 27 16:34:32 mentat kernel: [11942606.528274] mongod cpuset=/ mems_allowed=0-1 Aug 27 16:34:32 mentat kernel: [11942606.528277] Pid: 26758, comm: mongod Not tainted 2.6.32-5-amd64 #1 Aug 27 16:34:32 mentat kernel: [11942606.680278] nrpe invoked oom-killer: gfp_mask=0x201da, order=0, oom_adj=0 Aug 27 16:34:32 mentat kernel: [11942606.680283] nrpe cpuset=/ mems_allowed=0-1 Aug 27 16:34:32 mentat kernel: [11942606.680286] Pid: 22628, comm: nrpe Not tainted 2.6.32-5-amd64 #1
Zaregistroval jsem, když mi pod rukama zmizel mongod, navíc v okamžiku, kdy jsem nic nedělal.
Zjistili jsme, že vmem a rmem vyletí, když běží dotaz, který prochází celou db, např.:
db.alerts.aggregate({$group:{_id:"$Alert.Analyzer.@name", cnt:{$sum:1}}})
Po čase (bez vytěžujících dotazů) namapovaná paměť spadne, jádro nadále nepoužívané mmapnuté bloky databázových souborů posléze discardne (také poté, co případně zapsalo dirty bloky).
Updated by Pavel Kácha over 11 years ago
Dnes mě ale Mekova poznámka o hlášce mongo-shellu přivedla na podezření.
MongoDB shell version: 2.4.6 connecting to: test Server has startup warnings: Wed Aug 28 12:42:04.337 [initandlisten] Wed Aug 28 12:42:04.337 [initandlisten] ** WARNING: You are running on a NUMA machine. Wed Aug 28 12:42:04.337 [initandlisten] ** We suggest launching mongod like this to avoid performance problems: Wed Aug 28 12:42:04.337 [initandlisten] ** numactl --interleave=all mongod [other options] Wed Aug 28 12:42:04.337 [initandlisten]
Měl jsem za to, že NUMA (Non-unified Memory Access) stroje jsou farmy nezávislých strojů se sdílenou pamětí. Vypadá to ale, že to tak dneska už není, NUMA je používaná na dnešních běžných multiprocesorových architekturách, kde každý procesor má "snazší" přístup k určité části paměti.
root@mentat:~# numactl --hardware available: 2 nodes (0-1) node 0 cpus: 0 2 3 4 5 6 node 0 size: 16374 MB node 0 free: 117 MB node 1 cpus: 1 7 8 9 10 11 node 1 size: 16384 MB node 1 free: 161 MB node distances: node 0 1 0: 10 16 1: 16 10
(Distances udávají relativní "cenu" přístupu k paměťovému bloku.)
Dokumentace Mongo:
http://docs.mongodb.org/manual/administration/production-notes/#production-numa
A následně Jeremy Cole:
http://blog.jcole.us/2010/09/28/mysql-swap-insanity-and-the-numa-architecture/
A také Robert Chase:
http://www.oracle.com/technetwork/articles/servers-storage-admin/oom-killer-1911807.html
Preference procesoru bližšího paměťového bloku jednoho databázového threadu může vést k tomu, že se linux snaží aktivně odswapovat data z onoho bloku, aby mohl splnit preferenci, čímž trpí výkon db víc, než kdyby alokoval paměť libovolně, resp. přibližně rovnoměrně z bližších i vzdálenějších bloků. Co je ale zajímavější:
Jeremy Cole:
Using large-pages will keep mysqld from being swapped out, but it won’t keep the system from swapping something out. And, if it really needs memory on a particular node, and can’t swap out pages for mysqld, it will swap something else which might be more important to the function of the system, fail the allocation, or OOM-kill a process (likely mysqld).
Robert Chase:
Many NUMA architecture–based systems can experience OOM conditions because of one node running out of memory triggering an OOM in the kernel while plenty of memory is left in the remaining nodes. More information about OOM conditions on machines that have the NUMA architecture can be found in the "See Also" section of this article.
Takže máme řekl bych hlavního podezřelého.
Updated by Pavel Kácha over 11 years ago
- Assignee changed from Pavel Kácha to Jan Mach
Z dokumentace Monga:
To disable NUMA for MongoDB, use the numactl command and start mongod in the following manner:
numactl --interleave=all /usr/bin/local/mongod
Adjust the proc settings using the following command:
echo 0 > /proc/sys/vm/zone_reclaim_mode
To fully disable NUMA you must perform both operations. However, you can change zone_reclaim_mode without restarting mongod. For more information, see documentation on Proc/sys/vm.
Z dokumentace proc/sys/vm (https://www.kernel.org/doc/Documentation/sysctl/vm.txt):
zone_reclaim_mode: Zone_reclaim_mode allows someone to set more or less aggressive approaches to reclaim memory when a zone runs out of memory. If it is set to zero then no zone reclaim occurs. Allocations will be satisfied from other zones / nodes in the system. This is value ORed together of 1 = Zone reclaim on 2 = Zone reclaim writes dirty pages out 4 = Zone reclaim swaps pages
Vypadá to, že skripty monga jsou na to připravené, a pokud existuje numactl, volají ho. Takže jsem ho nainstaloval. Nicméně je chyba ve skriptech, musel jsem upravit startovací skript monga:
< NUMACTL_ARGS="--interleave=all" > NUMACTL_ARGS="-- --interleave=all"
Zone reclaim jsem také zapnul, ručně, po restartu ale zřejmě bude v defaultu, chtělo by zakomponovat někam do startovacích skriptů, přehazuju na Meka, ať to nerozstřelím víc, než je nezbytně nutné.
A uvidíme, zda na OOM narazíme znovu.
Updated by Pavel Kácha over 11 years ago
Ještě poznámka - narazili jsme na to zřejmě proto, že jde o Opteron (176HE, 2.4, 6MB, Opteron Magney Core, Decision One), podle Jeremyho Colea by podobnou architekturu měly mít ale i nové Nehalemy.
The new architecture for multiple processors, starting with AMD’s Opteron and Intel’s Nehalem2 processors (we’ll call these “modern PC CPUs”), is a Non-Uniform Memory Access (NUMA) architecture, or more correctly Cache-Coherent NUMA (ccNUMA).
Updated by Jan Mach over 11 years ago
- Category set to 6
- Status changed from New to Feedback
- Assignee changed from Jan Mach to Pavel Kácha
Pokud souhlasíš, tak bych ten zone_reclaim příkaz přidal přím do startovacího skriptu mongo, hned někde vedle volby NUMACTL_ARGS, ať je to u sebe, což? Nebo možná ještě někam do funkce, které se provádí při spouštění Monga (akce start). Nebo máš ještě nějakej jinej nápad, kde by to bylo vhodné?
Updated by Pavel Kácha over 11 years ago
vm.zone_reclaim_mode = 0 v /etc/sysctl.conf?
Updated by Jan Mach over 11 years ago
- Status changed from Feedback to Resolved
- Assignee changed from Pavel Kácha to Jan Mach
Vypnul jsem permanentně zone reclaim, na internetu jsem k tomu našel spoustu článků včetně jednoho s výmluvným titulkem http://www.poempelfox.de/blog/2010/03/, tak snad jsme se tohoto problému už zbavili.
Updated by Jan Mach over 8 years ago
- Status changed from Resolved to Closed
Zavírám, neaktuální a pravděpodobně i vyřešeno.