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

Posté par  .
Étiquettes : aucune
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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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  (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.