Forum Linux.noyau Problème d'OOM killer sur un NAS LaCie

Posté par .
Tags : aucun
0
19
fév.
2011

Bonjour,
J'utilise un nas Lacie Network Space 1To, et je rencontre des problèmes avec OOM killer qui se déclenche, alors que le swap n'est quasiment pas utilisé.

La machine dispose d'un (vieux) kernel 2.6.12.6-arm1, et ne fait tourner qu'un samba, un sshd et un ntpd :

PID USER VSZ STAT COMMAND
1 root 3296 S init
2 root 0 SWN [ksoftirqd/0]
3 root 0 SW< [events/0]
4 root 0 SW< [khelper]
5 root 0 SW< [kthread]
10 root 0 SW< [kblockd/0]
13 root 0 SW [khubd]
48 root 0 SW [pdflush]
49 root 0 SW [pdflush]
51 root 0 SW< [aio/0]
50 root 0 SW [kswapd0]
167 root 0 SW [scsi_eh_0]
201 root 0 SW [kjournald]
247 root 0 SW [kjournald]
249 root 0 SW [kjournald]
379 root 3296 S syslogd -m 0
390 root 3296 S klogd -c 2
409 root 0 SW< [xfslogd/0]
410 root 0 SW< [xfsdatad/0]
411 root 0 SW [xfsbufd]
442 root 7592 S /opt/sbin/nmbd -D
445 root 14188 S /opt/sbin/smbd -D
481 root 0 SW [xfssyncd]
754 root 3300 S /sbin/udhcpc -b -i egiga0 -p /var/run/udhcpc-egiga0.pid -s /etc/sysconfig/udhcpc.script -F monNas
783 root 1524 S /usr/sbin/ifplugd -i egiga0 -fwI -u10 -d0 --run=/etc/ifplugd/ifplugd.action
830 root 3164 S /usr/bin/ipconfd
857 root 3608 S /opt/sbin/sshd
873 root 1568 S < /sbin/udevd --daemon
930 root 4188 S ntpd
998 root 3300 S /sbin/getty 115200 ttyS0 vt100
999 root 3804 S sshd: root@ttyp0
1002 root 3456 S -sh
1146 root 15068 S /opt/sbin/smbd -D
1158 root 2756 R ps


Régulièrement, oom-killer se déclenche, alors que le swap n'a que 3Mo d'utilisé sur 128Mo, et tue le smbd :


total used free shared buffers
Mem: 13588 11988 1600 0 160
Swap: 128448 3056 125392
Total: 142036 15044 126992


J'ai essayé de bidouiller les paramètres vm.overcommit_memory et vm.swappiness mais sans succès. Voici leur valeur actuelle :


sysctl -a |grep vm
vm.swap_token_timeout = 300
vm.vfs_cache_pressure = 100
vm.block_dump = 0
vm.laptop_mode = 0
vm.max_map_count = 65536
vm.min_free_kbytes = 1200
vm.lowmem_reserve_ratio = 256 32
vm.swappiness = 99
vm.nr_pdflush_threads = 2
vm.dirty_expire_centisecs = 3000
vm.dirty_writeback_centisecs = 500
vm.dirty_ratio = 40
vm.dirty_background_ratio = 10
vm.page-cluster = 3
vm.overcommit_ratio = 99
vm.overcommit_memory = 2


Quelques infos supplémentaires sur le matériel :


Processor : ARM926EJ-Sid(wb) rev 0 (v5l)
BogoMIPS : 219.54
Features : swp half thumb fastmult
CPU implementer : 0x41
CPU architecture: 5TEJ
CPU variant : 0x0
CPU part : 0x926
CPU revision : 0
Cache type : write-back
Cache clean : cp15 c7 ops
Cache lockdown : format C
Cache format : Harvard
I size : 16384
I assoc : 1
I line length : 32
I sets : 512
D size : 16384
D assoc : 1
D line length : 32
D sets : 512

Hardware : Feroceon
Revision : 0000
Serial : 0000000000000000


MemTotal: 13588 kB
MemFree: 1552 kB
Buffers: 220 kB
Cached: 6392 kB
SwapCached: 672 kB
Active: 3480 kB
Inactive: 3860 kB
HighTotal: 0 kB
HighFree: 0 kB
LowTotal: 13588 kB
LowFree: 1552 kB
SwapTotal: 128448 kB
SwapFree: 125392 kB
Dirty: 1492 kB
Writeback: 0 kB
Mapped: 2864 kB
Slab: 2420 kB
CommitLimit: 141900 kB
Committed_AS: 9260 kB
PageTables: 296 kB
VmallocTotal: 499712 kB
VmallocUsed: 328 kB
VmallocChunk: 499384 kB


et le dmesg :


Linux version 2.6.12.6-arm1 (iminea@grp-horus) (gcc version 3.4.4 (release) (CodeSourcery ARM 2005q3-2)) #49 Wed Apr 9 15:29:15 CEST 2008
CPU: ARM926EJ-Sid(wb) [41069260] revision 0 (ARMv5TEJ)
CPU0: D VIVT write-back cache
CPU0: I cache: 16384 bytes, associativity 1, 32 byte lines, 512 sets
CPU0: D cache: 16384 bytes, associativity 1, 32 byte lines, 512 sets
Machine: Feroceon
Using UBoot passing parameters structure
Memory policy: ECC disabled, Data cache writeback
On node 0 totalpages: 4096
DMA zone: 4096 pages, LIFO batch:1
Normal zone: 0 pages, LIFO batch:1
HighMem zone: 0 pages, LIFO batch:1
Built 1 zonelists
Kernel command line: console=ttyS0,115200 root=/dev/sda7 ro boardType=mv88F6082 productType=Aston reset=0
mvBoardGpioIntMaskGet:Board intsGppMask 0
PID hash table entries: 128 (order: 7, 2048 bytes)
Console: colour dummy device 80x30
Dentry cache hash table entries: 4096 (order: 2, 16384 bytes)
Inode-cache hash table entries: 2048 (order: 1, 8192 bytes)
Memory: 8MB 8MB 0MB 0MB = 16MB total
Memory: 13480KB available (2233K code, 360K data, 84K init)
Calibrating delay loop... 219.54 BogoMIPS (lpj=1097728)
Mount-cache hash table entries: 512
CPU: Testing write buffer coherency: ok
NET: Registered protocol family 16
mvBoardMppGet mppGroupNum 0 mppGroup 4096
mvBoardMppGet mppGroupNum 1 mppGroup 17
Sys Clk = 166666667, Tclk = 133333333

CPU Interface
-------------
SDRAM_CS0 ....base 00000000, size 8MB
SDRAM_CS1 ....base 00800000, size 8MB
PEX0_MEM ....base e0000000, size 128MB
PEX0_IO ....base f2000000, size 1MB
INTER_REGS ....base f1000000, size 1MB
NFLASH_CS ....base f9000000, size 2MB
MFLASH_CS ....base f8000000, size 256KB
SPI_CS ....base fa000000, size 8MB
BOOT_ROM_CS ....base fc000000, size 1MB
DEV_BOOTCS ....base fc000000, size 1MB
CRYPT_ENG ....base f0000000, size 64KB

Marvell Development Board (LSP Version 2.2.2_NAS_GDP)-- RD-88F6082-NAS-PH Soc: MV88F6082 Rev 1
Detected Tclk 133333333 and SysClk 166666667
Marvell USB EHCI Host controller #0: c030cb00
PCI: bus0: Fast back to back transfers enabled
SCSI subsystem initialized
usbcore: registered new driver usbfs
usbcore: registered new driver hub
Fast Floating Point Emulator V0.9 (c) Peter Teichmann.
inotify device minor=63
Registering unionfs 1.1.5
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
ttyS0 at MMIO 0x0 (irq = 3) is a 16550A
io scheduler noop registered
Marvell Ethernet Driver 'mv_ethernet':
o Uncached descriptors in DRAM
o DRAM SW cache-coherency
o TCP segmentation offload enabled
o Checksum offload enabled
o Rx desc: 64
o Tx desc: 128
o Loading network interface o ethPortNumber 2 'egiga0' mvBoardPhyAddrGet: 8
mvBoardSpeedGet: 3
o ethPortNumber 2 'egiga1' mvBoardPhyAddrGet: 104
mvBoardSpeedGet: 5

ipddp.c:v0.01 8/28/97 Bradford W. Johnson <johns393@maroon.tc.umn.edu>
ipddp0: Appletalk-IP Encap. mode by Bradford W. Johnson <johns393@maroon.tc.umn.edu>
Intergrated Sata device found
scsi0 : Marvell SCSI to SATA adapter
Vendor: SAMSUNG Model: HD103UI Rev: 1AA0
Type: Direct-Access ANSI SCSI revision: 03
Attached scsi disk sda at scsi0, channel 0, <5>SCSI device sda: 1953525168 512-byte hdwr sectors (1000205 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 1953525168 512-byte hdwr sectors (1000205 MB)
SCSI device sda: drive cache: write back
sda: sda1 < sda5 sda6 sda7 sda8 sda9 sda10 > sda2
Attached scsi disk sda at scsi0, channel 0, id 0, lun 0
Attached scsi generic sg0 at scsi0, channel 0, id 0, lun 0, type 0
ehci_platform ehci_platform.70059: EHCI Host Controller
ehci_platform ehci_platform.70059: new USB bus registered, assigned bus number 1
ehci_platform ehci_platform.70059: irq 17, io mem 0x00000000
ehci_platform ehci_platform.70059: park 0
ehci_platform ehci_platform.70059: USB 0.0 initialized, EHCI 1.00, driver 10 Dec 2004
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
ohci_hcd: 2004 Nov 08 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
USB Universal Host Controller Interface driver v2.2
Initializing USB Mass Storage driver...
usbcore: registered new driver usb-storage
USB Mass Storage support registered.
usbcore: registered new driver usbhid
drivers/usb/input/hid-core.c: v2.01:USB HID core driver
mice: PS/2 mouse device common for all mice
DATA IN REG=2CE1
aston_power 1.0 initialised
i2c /dev entries driver
i2c-twsi - probe
i2c-twsi - get parent
i2c-twsi - set adapter
rs5c372_attach
rs5c372 detect
rs5c372 attach client
NET: Registered protocol family 2
IP: routing cache hash table of 512 buckets, 4Kbytes
TCP established hash table entries: 1024 (order: 1, 8192 bytes)
TCP bind hash table entries: 1024 (order: 0, 4096 bytes)
TCP: Hash tables configured (established 1024 bind 1024)
NET: Registered protocol family 1
NET: Registered protocol family 17
NET: Registered protocol family 5
Loading I2C based RTC driver device interface.
Found TWSI adapter with id: 0
Found I2C RTC rs5c372 @ 0x32
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing init memory: 84K
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
kjournald starting. Commit interval 5 seconds
EXT3 FS on sda9, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
SGI XFS with large block numbers, no debug enabled
fuse init (API version 7.8)
fuse distribution version: 2.7.3
Adding 128448k swap on /dev/sda5. Priority:-1 extents:1
XFS mounting filesystem sda2
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
egiga0: link down
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
mvBoardPhyAddrGet: 8
egiga0: link up, full duplex, speed 100 Mbps


Pour finir, le message d'erreur quand OOM killer se déclenche :

user.warn kernel: oom-killer: gfp_mask=0x2d0
user.warn kernel: DMA per-cpu:
user.warn kernel: cpu 0 hot: low 2, high 6, batch 1
user.warn kernel: cpu 0 cold: low 0, high 2, batch 1
user.warn kernel: Normal per-cpu: empty
user.warn kernel: HighMem per-cpu: empty
user.warn kernel:
user.warn kernel: Free pages: 6524kB (0kB HighMem)
user.warn kernel: Active:20 inactive:23 dirty:0 writeback:0 unstable:0 free:1631 slab:874 mapped:20 pagetables:90
user.warn kernel: DMA free:6524kB min:1200kB low:1500kB high:1800kB active:80kB inactive:92kB present:16384kB pages_scanned:41 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: DMA: 411*4kB 252*8kB 113*16kB 27*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6524kB
user.warn kernel: Normal: empty
user.warn kernel: HighMem: empty
user.warn kernel: Swap cache: add 24282, delete 24269, find 7705/11790, race 0+0
user.warn kernel: Free swap = 124768kB
user.warn kernel: Total swap = 128448kB
user.err kernel: Out of Memory: Killed process 453 (smbd).
user.warn kernel: oom-killer: gfp_mask=0x2d0
user.warn kernel: DMA per-cpu:
user.warn kernel: cpu 0 hot: low 2, high 6, batch 1
user.warn kernel: cpu 0 cold: low 0, high 2, batch 1
user.warn kernel: Normal per-cpu: empty
user.warn kernel: HighMem per-cpu: empty
user.warn kernel:
user.warn kernel: Free pages: 6620kB (0kB HighMem)
user.warn kernel: Active:0 inactive:35 dirty:0 writeback:1 unstable:0 free:1655 slab:874 mapped:0 pagetables:81
user.warn kernel: DMA free:6620kB min:1200kB low:1500kB high:1800kB active:0kB inactive:140kB present:16384kB pages_scanned:86 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: Normal free:0kB min:0kB low:0kB high:0kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB present:0kB pages_scanned:0 all_unreclaimable? no
user.warn kernel: lowmem_reserve[]: 0 0 0
user.warn kernel: DMA: 397*4kB 261*8kB 118*16kB 27*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6620kB
user.warn kernel: Normal: empty
user.warn kernel: HighMem: empty
user.warn kernel: Swap cache: add 24307, delete 24291, find 7705/11794, race 0+0
user.warn kernel: Free swap = 125024kB
user.warn kernel: Total swap = 128448kB
user.err kernel: Out of Memory: Killed process 1007 (smbd).



Qu'est ce qui est susceptible de limiter le swap, et comment puis-je empêcher le déclenchement d'OOM killer tant que toute la mémoire n'est pas réellement saturée ?

Je sais qu'il existe un firmware alternatif pour ce NAS, mais il nécessite un reformatage complet, ce que j'aimerais éviter.

Merci de m'avoir lu jusqu'au bout :-)
  • # SWAP != RAM

    Posté par (page perso) . Évalué à 2.

    Le swap n'est pas utilisé de la même façon que la RAM, et le kernel veut parfois allouer de la RAM, pas de la swap. Si yaplu, yaplu...

    http://linux-mm.org/OOM

    As tu installé des services supplémentaires ?
    • [^] # Re: SWAP != RAM

      Posté par (page perso) . Évalué à 2.

      Quelle est la conso en ram des services que tu fais tourner ?
      RSS ou RES
      • [^] # Re: SWAP != RAM

        Posté par . Évalué à 1.

        Je n'ai pas plus d'infos, le ps est un ps "busybox", et il ne m'affiche pas ces colonnes :-\
    • [^] # Re: SWAP != RAM

      Posté par . Évalué à 1.

      A part ce qui est affiché par la sortie de la commande ps, je n'ai rien installé d'autre. Par contre j'ai remarqué que le OOM se déclenchait souvent quand je lançais le démon ushare configuré pour lire des données sur un répertoire monté depuis le NAS, mais le démon ushare tourne sur une autre machine.
  • # fragmentation

    Posté par (page perso) . Évalué à 2.

    J'y connais rien en ARM mais ceci :

    user.warn kernel: DMA free:6524kB min:1200kB low:1500kB high:1800kB active:80kB inactive:92kB present:16384kB pages_scanned:41 all_unreclaimable? no
    

    signifie qu'il y a 6524kB de mémoire disponible et que l'OOM ne devrait pas se déclencher tant que ça ne passe pas en dessous de 1200kB. Sauf que :

    user.warn kernel: DMA: 411*4kB 252*8kB 113*16kB 27*32kB 1*64kB 1*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 6524kB
    

    signifique que la plus grande zone de mémoire consécutive disponible est de 128kB. Si quelque chose tente d'allouer 256kB consécutifs par exemple, ça peut causer un OOM. Tu n'as rien d'autre dans les logs noyau immédiatement avant l'OOM ? Ça se passe lors du chargement d'un module par exemple ?

    pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

    • [^] # Re: fragmentation

      Posté par (page perso) . Évalué à 3.

      L'idéal ça serait d'avoir un backtrace pour voir par quoi out_of_memory() a été appelé. On peut faire ça en activant le sysctl "panic_on_oom" et en ayant de quoi récupérer les logs console et possiblement un vmcore.

      pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

      • [^] # Re: fragmentation

        Posté par . Évalué à 0.

        Merci, je vais tester ça dès que je peux et je poste les logs

        • [^] # Re: fragmentation

          Posté par . Évalué à 1.

          Je viens de regarder vite fait, apparemment le "panic on oom" n'est pas supporté par mon noyau :

          sysctl -a |grep oom
          

          ne me renvoie rien.

          Par contre j'ai pas mal de lignes de ce style avant le déclenchement du OOM :

          user.err kernel: XFS: possible memory allocation deadlock in kmem_alloc (mode:0x2d0)
          

          Peut-être un bug du module XFS ? Je vais tenter un xfs_repair à tout hasard.

          • [^] # Re: fragmentation

            Posté par (page perso) . Évalué à 3.

            Les GFP flags de l'OOM correspondent à ceux du message XFS (0x2d0 == NOWARN | FS | IO | WAIT). Le message vient de là : http://lxr.linux.no/#linux+v2.6.12/fs/xfs/linux-2.6/kmem.c#L62

            43#define MAX_VMALLOCS    6
            44#define MAX_SLAB_SIZE   0x20000
            ..
            47void *
            48kmem_alloc(size_t size, int flags)
            49{
            50        int     retries = 0;
            51        int     lflags = kmem_flags_convert(flags);
            52        void    *ptr;
            53
            54        do {
            55                if (size < MAX_SLAB_SIZE || retries > MAX_VMALLOCS)
            56                        ptr = kmalloc(size, lflags);
            57                else
            58                        ptr = __vmalloc(size, lflags, PAGE_KERNEL);
            59                if (ptr || (flags & (KM_MAYFAIL|KM_NOSLEEP)))
            60                        return ptr;
            61                if (!(++retries % 100))
            62                        printk(KERN_ERR "XFS: possible memory allocation "
            63                                        "deadlock in %s (mode:0x%x)\n",
            64                                        __FUNCTION__, lflags);
            65                blk_congestion_wait(WRITE, HZ/50);
            66        } while (1);
            67}
            

            Faut croire que XFS essaie d'allouer un relativement gros bloque de mémoire contigüe. Ça marche pas donc ça déclenche un OOM. XFS réessai jusqu'à ce que les OOM aient défragmenté suffisamment de mémoire où jusqu'à ce qu'il abandonne et utilise de la mémoire non contigüe.

            M'étonnerait qu'un xfs_repair change grand chose. Il y a peut-être moyen de tuner XFS pour éviter ce genre de situation mais vu l'ancienneté du noyal, il est probable qu'il s'agisse d'un bug XFS qui requiert une mise à jour du driver.

            pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.

            • [^] # Re: fragmentation

              Posté par . Évalué à 1.

              Merci beaucoup pour ce diagnostic précis. Effectivement le xfs_repair n'a rien changé :-\ Je vais potasser la doc xfs pour voir si je peux m'en sortir en jouant avec les fs.xfs.* et sysctl Si jamais ça ne marche pas, il ne me restera plus qu'à espérer qu'il existe de quoi recompiler le module xfs avec une version plus récente pour l'archi de mon NAS.

              En tout cas, merci pour ton aide et bonne journée.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.