Sziasztok!
Az alábbi problémával állok szembe, viszont sehogy se tudok rájönni a hibára.
Van 4db Dell R510-es szerverünk, melyeken Debian 8 rendszer fut NFS szerverként megosztott BTRFS kötetekkel. Mind a 4 szerver esetén egy Perc H700 mögött vannak a diszkek RAID1-es kötetekben.
3 szerver esetén előjön az alábbi kernel bug, ezután pedig NFS-en keresztül szinte elérhetetlen lesz (egy sima metadata lekérdezés is másodpercekbe kerül), viszont lokálisan úgy ahogy eldöcög (habár ilyenkor is teljesen belassul):
[Mon Jun 5 12:13:45 2017] general protection fault: 0000 [#1] SMP
[Mon Jun 5 12:13:45 2017] Modules linked in: nfsd auth_rpcgss oid_registry nfs_acl nfs lockd fscache sunrpc ttm joydev drm_kms_helper drm iTCO_wdt coretemp i2c_algo_bit i2c_core kvm_intel dcdbas acpi_power_meter evdev serio_raw pcspkr iTCO_vendor_support kvm shpchp lpc_ich mfd_core tpm_tis button tpm i7core_edac edac_core processor thermal_sys loop ipmi_watchdog ipmi_si ipmi_poweroff ipmi_devintf ipmi_msghandler fuse autofs4 ext4 crc16 mbcache jbd2 btrfs xor raid6_pq hid_generic usbhid hid sg sd_mod crc_t10dif crct10dif_generic ses enclosure crct10dif_common crc32c_intel psmouse ehci_pci uhci_hcd ehci_hcd megaraid_sas usbcore usb_common scsi_mod bnx2
[Mon Jun 5 12:13:45 2017] CPU: 0 PID: 3902 Comm: nfsd Tainted: G I 3.16.0-4-amd64 #1 Debian 3.16.43-2
[Mon Jun 5 12:13:45 2017] Hardware name: Dell Inc. PowerEdge R510/0DPRKF, BIOS 1.2.12 04/07/2010
[Mon Jun 5 12:13:45 2017] task: ffff8803f9fccbe0 ti: ffff8803f38cc000 task.ti: ffff8803f38cc000
[Mon Jun 5 12:13:45 2017] RIP: 0010:[] [] __d_lookup+0x68/0x150
[Mon Jun 5 12:13:45 2017] RSP: 0018:ffff8803f38cfb70 EFLAGS: 00010202
[Mon Jun 5 12:13:45 2017] RAX: ffffc90000e01d48 RBX: 1d29b4080d2d8e40 RCX: 000000000000000b
[Mon Jun 5 12:13:45 2017] RDX: ffffc90000016000 RSI: ffff8803f38cfc30 RDI: ffff88027431e918
[Mon Jun 5 12:13:45 2017] RBP: ffff88027431e918 R08: 0000000000000000 R09: 0000000000000008
[Mon Jun 5 12:13:45 2017] R10: 0000000000000000 R11: 0000000000000003 R12: ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] R13: 0000000000000010 R14: 0000000010ea836a R15: ffff880421368258
[Mon Jun 5 12:13:45 2017] FS: 0000000000000000(0000) GS:ffff88042fc00000(0000) knlGS:0000000000000000
[Mon Jun 5 12:13:45 2017] CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b
[Mon Jun 5 12:13:45 2017] CR2: 00007fa4dc621000 CR3: 0000000001813000 CR4: 00000000000007f0
[Mon Jun 5 12:13:45 2017] Stack:
[Mon Jun 5 12:13:45 2017] ffff880421368270 0000000000000000 000000000025efdc ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] ffff88027431e918 ffff8803f38cfc17 0000000000000000 ffff880421368258
[Mon Jun 5 12:13:45 2017] ffffffff811c2fe5 0000000000000000 ffff88027431e918 ffff8803f38cfc30
[Mon Jun 5 12:13:45 2017] Call Trace:
[Mon Jun 5 12:13:45 2017] [] ? d_lookup+0x25/0x40
[Mon Jun 5 12:13:45 2017] [] ? lookup_dcache+0x2b/0xc0
[Mon Jun 5 12:13:45 2017] [] ? __lookup_hash+0x1a/0x40
[Mon Jun 5 12:13:45 2017] [] ? lookup_one_len+0xcd/0x120
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_dirent+0xbe/0x3d0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_getattr+0x50/0x50 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_readdir+0x19f/0x2a0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_direct_splice_actor+0x20/0x20 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_readdir+0xee/0x200 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_encode_operation+0x75/0x190 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd4_proc_compound+0x24a/0x7e0 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_dispatch+0xb2/0x200 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? svc_process_common+0x451/0x6e0 [sunrpc]
[Mon Jun 5 12:13:45 2017] [] ? nfsd_destroy+0x70/0x70 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? svc_process+0x10c/0x160 [sunrpc]
[Mon Jun 5 12:13:45 2017] [] ? nfsd+0xbf/0x130 [nfsd]
[Mon Jun 5 12:13:45 2017] [] ? kthread+0xbd/0xe0
[Mon Jun 5 12:13:45 2017] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 5 12:13:45 2017] [] ? ret_from_fork+0x58/0x90
[Mon Jun 5 12:13:45 2017] [] ? kthread_create_on_node+0x180/0x180
[Mon Jun 5 12:13:45 2017] Code: 48 c1 e8 06 44 01 f0 69 c0 01 00 37 9e d3 e8 48 8d 04 c2 48 8b 18 48 83 e3 fe 75 0f eb 35 0f 1f 44 00 00 48 8b 1b 48 85 db 74 28 <44> 39 73 18 75 f2 4c 8d 7b 50 4c 89 ff e8 46 70 35 00 48 39 6b
[Mon Jun 5 12:13:45 2017] RIP [] __d_lookup+0x68/0x150
[Mon Jun 5 12:13:45 2017] RSP
[Mon Jun 5 12:13:45 2017] ---[ end trace f84a1b4e02c5b855 ]---
Eddig arra gyanakodtam, hogy a "rossz" szerverek esetén Debian Wheezy volt, a "jón" pedig Jessie, viszont az upgrade nem oldotta meg a problémát.
Amit még észrevettem, az a kernel verzió:
- Jó esetén: 3.16.7-ckt25-2+deb8u3
- Rosszak esetén most: 3.16.43-2
S most nem igazán tudom eldönteni, mi okozhatja ezt a problémát. Ami kiválthatta az egészet, az az, hogy pár hete elkezdtünk rajta lokálisan számolni foglaltságokat (eddig NFS-es megosztáson keresztül ment), azaz lokálisan a gépekre helyeztük ezt át (megzavarta volna a BTRFS cache lelki világát?).
A btrfs-tools verziószáma 3.17.
Nem tudom, hogy egy jessie-backoprts-os kernel image mennyit javítana a helyzeten, de minden észrevételt, kérdést, bármi egyebet szívesen fogadok.
- 975 megtekintés
Hozzászólások
Sajnos érdemben nem tudok segíteni, de a 3.16 nagyon régi, ha ez kernel hiba, van rá esély, hogy a kernel frissítés megoldja. (4.4 vagy újabb)
- A hozzászóláshoz be kell jelentkezni
Egy szerver esetén felmentem 4.9-re, s most várom ennek az eredményét. :)
Amit még észrevettem:
- A BTRFS kötetek ~1TB-osak, a hozzájuk tartozó Metadata mérete 10-12 GB általánosságban
- A szerverek memória mérete elég változó, viszont ha az összes metadata-t be szeretném tölteni, ahol számolás történik, akkor csak a "jó" szerver esetén férne el all-in-one a memóriában.
Vagy egy csúnya memory leak-re gondolok, vagy arra, hogy a metadata cache-t nem akarja üríteni, így egyszerűen felszívja az összes RAM-ot.
- A hozzászóláshoz be kell jelentkezni
Az egyik ügyfelünknél ugyan ez a probléma. Más gépek, más felhasználás (kb. 17 lxc container), más
file rendszer (ext4). Debian 8.8 Hetente kb. kétszer elhasal.
Nagyjából két hete az összes compute node-on nfsvers=3 opcióval mountoltam a storage-ot.
Azóta hibamentes működés van. A loadavg 5-ről 1-alá esett a storage-on.
További érdekességek, amit észleltem:
nfs4 esetén a showmount parancs nem, vagy nem megfelelő információkat ad a client-ekről.
Az /etc/default/nfs-kernel-server fileból:
# To disable NFSv4 on the server, specify '--no-nfs-version 4' here
Miért írták ezt ide?
- A hozzászóláshoz be kell jelentkezni