Problembeschreibung Auf mehreren Rechnern wurden in letzter Zeit zu unterschiedlichen Tageszeiten folgende Warnmeldungen angezeigt: 26. März 20:55:03 Host1-Kernel: WARNUNG: bei fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs]() 26. März 20:55:03 Host1-Kernel: Eingebundene Module: nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack iptable_filter ip_tables ebtable_filter ebtables ip6table_ Filter IP6_Tabellen Devlink Brücke STP LLC XT_Multiport SunRPC DM_Mirror DM_Region_Hash DM_Log DM_Mod Intel_Powerclamp Coretemp Intel_Rapl iOSF_MBI KVM_Intel KVM IRQBYPA ss crc32_pclmul ghash_clmulni_intel aesni_intel lrw gf128mul glue_helper ablk_helper cryptd iTCO_wdt iTCO_vendor_support dcdbas ipmi_devintf ipmi_si sg pcspkr ipmi_msg Handler shpchp i2c_i801 lpc_ich nfit libnvdimm acpi_power_meter kgwttm(OE) xfs libcrc32c sd_mod crc_t10dif crct10dif_generic crct10dif_pclmul crct10dif_common crc32c_i ntel mgag200 drm_kms_helper igb syscopyarea sysfillrect sysimgblt ptp fb_sys_fops ttm pps_core dca ahci drm i2c_algo_bit libahci megaraid_sas i2c_core libata 26. März 20:55:03 Host1-Kernel: fjes [zuletzt entladen: nf_defrag_ipv4] 26. März 20:55:03 Host1 Kernel: CPU: 10 PID: 224 Comm: kswapd0 Tainted: G OE ------------ 3.10.0-514.21.2.el7.x86_64 #1 26. März 20:55:03 Host1-Kernel: Hardwarename: Dell Inc. PowerEdge R640/0W23H8, BIOS 1.3.7 08.02.2018 26. März 20:55:03 Host1-Kernel: 000000000000000 00000000e02a0d05 ffff88103c7ebaa0 ffffffff81687073 26. März 20:55:03 Host1-Kernel: ffff88103c7ebad8 ffffffff81085cb0 ffffea0000687620 ffffea0000687600 26. März 20:55:03 Host1-Kernel: ffff88004a71daf8 ffff88103c7ebda0 ffffea0000687600 ffff88103c7ebae8 26. März 20:55:03 Host1-Kernel: Aufrufverfolgung: 26. März 20:55:03 Host1-Kernel: [<ffffffff81687073>] dump_stack+0x19/0x1b 26. März 20:55:03 Host1-Kernel: [<ffffffff81085cb0>] warn_slowpath_common+0x70/0xb0 26. März 20:55:03 Host1-Kernel: [<ffffffff81085dfa>] warn_slowpath_null+0x1a/0x20 26. März 20:55:03 Host1-Kernel: [<ffffffffa038bfdb>] xfs_vm_releasepage+0xcb/0x100 [xfs] 26. März 20:55:03 Host1-Kernel: [<ffffffff81180b22>] try_to_release_page+0x32/0x50 26. März 20:55:03 Host1-Kernel: [<ffffffff81196ad6>] shrink_active_list+0x3d6/0x3e0 26. März 20:55:03 Host1-Kernel: [<ffffffff81196ed1>] shrink_lruvec+0x3f1/0x770 26. März 20:55:03 Host1-Kernel: [<ffffffff811972c6>] shrink_zone+0x76/0x1a0 26. März 20:55:03 Host1-Kernel: [<ffffffff8119857c>] balance_pgdat+0x48c/0x5e0 26. März 20:55:03 Host1-Kernel: [<ffffffff81198843>] kswapd+0x173/0x450 26. März 20:55:03 Host1-Kernel: [<ffffffff810b1b20>] ? 26. März 20:55:03 Host1-Kernel: [<ffffffff811986d0>] ? 26. März 20:55:03 Host1-Kernel: [<ffffffff810b0a4f>] kthread+0xcf/0xe0 26. März 20:55:03 Host1-Kernel: [<ffffffff810b0980>] ? kthread_create_on_node+0x140/0x140 26. März 20:55:03 Host1-Kernel: [<ffffffff81697698>] ret_from_fork+0x58/0x90 26. März 20:55:03 Host1-Kernel: [<ffffffff810b0980>] ? kthread_create_on_node+0x140/0x140 26. März 20:55:03 Host1-Kernel: --- [Ende der Ablaufverfolgung 24823c5c7a1ea2be] --- Die Kernel- und Anwendungsabsturzinformationen dieser Maschinen werden vom abrtd-Dienst übernommen. Sie können die zusammenfassenden Informationen über abrt-cli anzeigen: # abrt-cli-Liste --seit 1547518209 Nr. 2181dce8f72761585cb6a904dbff1806c1315c27 Grund: WARNUNG: bei fs/xfs/xfs_aops.c:1045 xfs_vm_releasepage+0xcb/0x100 [xfs]() Zeit: Sa 23. März 2019 20:30:45 CST Befehlszeile: BOOT_IMAGE=/boot/vmlinuz-3.10.0-514.16.1.el7.x86_64 root=/dev/sda1 ro crashkernel=auto net.ifnames=0 biosdevname=0 Paket: Kernel Benutzer-ID: 0 (Root) Anzahl: 1 Verzeichnis: /var/spool/abrt/oops-2019-03-23-20:30:45-163925-0 Die Kernelversionen sind wie folgt:
Analytische Verarbeitung Red Hat Wissensdatenbank Weitere Informationen finden Sie im Red Hat Knowledgebase-Dokument. Diese Art von XFS-Warnmeldung wird ausgegeben, wenn das XFS-Modul den Codepfad durchläuft, was die Hostnutzung nicht beeinflusst. Sie können den Kernel auf kernel-3.10.0-693.el7 aktualisieren, um diese Warnmeldung zu vermeiden. Weitere Informationen finden Sie unter: redhat-access-2893711
Code-Analyse In der Red Hat Knowledge Base werden keine Informationen zum Speicherrecycling erwähnt, aber den Stapelinformationen zufolge scheint es durch das Speicherrecycling des Kernels verursacht zu werden. Die Speichernutzung zum entsprechenden Zeitpunkt ist wie folgt: 16:30:01 Uhr kbmemfree kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty ...... 20:40:01 Uhr 513940 130976220 99,61 876 104616380 28610584 21,76 92439660 34840920 524 20:50:01 Uhr 479896 131010264 99,64 876 104666496 28557292 21,72 92513872 34804240 400 21:00:01 Uhr 455948 131034212 99,65 876 104675712 28588852 21,74 92418724 34926132 572 21:10:01 Uhr 556980 130933180 99,58 876 104610352 28552656 21,71 94287212 32983892 900 # sysctl vm.min_free_kbytes vm.min_free_kbytes = 90112 Der verfügbare Speicher hat sich zwischen 20:50 und 21:00 nicht erhöht, was bedeutet, dass das System möglicherweise keine Speicherwiederherstellungsvorgänge durchgeführt hat. Wir können die Funktionsaufrufbeziehung anhand der Stapelinformationen des Kernelprotokolls sehen: shrink_active_list -> versuche_Seite_freizugeben -> xfs_vm_releasepage //Quelle/mm/filemap.c 3225 int try_to_release_page(Struktur Seite *Seite, gfp_t gfp_mask) 3226 { 3227 Struktur Adressraum * const Mapping = Seite->Mapping; ...... 3233 wenn (Zuordnung und Zuordnung->a_ops->Releasepage) 3234 returniere Mapping->a_ops->Releasepage(Seite, GFP-Maske); xfs_vm_Releasepage 3235 returniere try_to_free_buffers(Seite); 3236 } //Quelle/fs/xfs/xfs_aops.c 1034 STATISCH int 1035 xfs_vm_releasepage( 1036 Strukturseite *Seite, 1037 gfp_t gfp_mask) 1038 { 1039 int delalloc, ungeschrieben; 1040 1041 trace_xfs_releasepage(Seite->Mapping->Host, Seite, 0, 0); 1042 1043 xfs_count_page_state(Seite, &delalloc, &ungeschrieben); 1044 1045 wenn (WARN_ON_ONCE(delalloc)) 1046 gibt 0 zurück; 1047 if (WARN_ON_ONCE(ungeschrieben)) 1048 gibt 0 zurück; 1049 1050 returniere try_to_free_buffers(Seite); 1051 } ...... 1827 const struct Adressraumoperationen xfs_Adressraumoperationen = { 1833 .releasepage = xfs_vm_releasepage, Entsprechend dem Kernel-Protokoll kernel: WARNUNG: bei fs/xfs/xfs_aops.c:1045 ist ersichtlich, dass die Stapelinformationen in Zeile 1045 der Quelldatei source/fs/xfs/xfs_aops.c gedruckt werden. Tatsächlich wird try_to_free_buffers nicht ausgeführt und es hat bereits zurückgegeben: 1045 wenn (WARN_ON_ONCE(delalloc)) 1046 gibt 0 zurück; WARN_ON_ONCE ist relativ einfach und kann in der Quelldatei source/include/asm-generic/bug.h gefunden werden: 73 #define __WARN() warn_slowpath_null(__FILE__, __LINE__) 85 #define WARN_ON(Bedingung) ({ \ ... 88 __WARN(); \ 136 #define WARN_ON_ONCE(Bedingung) ({ \ .... 140 wenn (unwahrscheinlich(__ret_warn_once)) \ 141 wenn (WARN_ON(!__warned)) \ Die Funktion __WARN ruft die Funktion warn_slowpath_null in den Stapelinformationen auf und ruft dann die Funktion warn_slowpath_common auf, um die Stapelinformationen auszudrucken: //Quelle/Kernel/Panic.c 517 void warn_slowpath_null(const char *Datei, int Zeile) 518 { 519 warn_slowpath_common(Datei, Zeile, __builtin_return_address(0), 520 TAINT_WARN, NULL); 521 } 463 static void warn_slowpath_common(const char *Datei, int Zeile, void *Anrufer, 464 vorzeichenloser Makel, Struktur slowpath_args *args) 465 { 466 deaktivieren_trace_on_warning(); 467 468 printk(KERN_WARNING "------------[ hier schneiden ]------------\n"); 469 printk(KERN_WARNING "WARNUNG: bei %s:%d %pS()\n", Datei, Zeile, Anrufer); 470 471 wenn (Argumente) 472 vprintk(Argumente -> fmt, Argumente -> Argumente); ...... 485 Druckmodule(); 486 Fehlercode(s); 487 print_oops_end_marker(); Wir können grob erkennen, dass diese Stapelnachricht lediglich eine Warnung ist, die mit der Beschreibung in der Red Hat Knowledge Base übereinstimmt und die Verwendung des Hosts nicht beeinträchtigt. Zusammenfassung Mit den Funktionen in der obigen Quelldatei ist es möglich, Stapelinformationen zu drucken, solange xfs_vm_releasepage aufgerufen wird, wenn kswapd Speicher zurückfordert. Wenn der Stapel gedruckt wird, wird der Vorgang try_to_free_buffers nicht ausgeführt, sodass der verfügbare Speicher beim Überprüfen der Speichernutzung nicht zunimmt. Wenn Sie nicht möchten, dass die Stapelinformationen angezeigt werden, können Sie die Stapelabfrage deaktivieren, indem Sie den Kernelparameter kernel.traceoff_on_warning aktivieren, der der Funktion disable_trace_on_warning entspricht. Andere Kernelinformationen werden jedoch nach dem Deaktivieren nicht mehr gedruckt. Aus dieser Sicht kann diese Information also nur durch ein Upgrade der Kernelversion vermieden werden. Das ist alles für diesen Artikel. Ich hoffe, dass der Inhalt dieses Artikels für Ihr Studium oder Ihre Arbeit von gewissem Referenzwert ist. Vielen Dank für Ihre Unterstützung von 123WORDPRESS.COM. Das könnte Sie auch interessieren:
|
<<: MySQL-Sortierung zum Abrufen eines Ranking-Beispielcodes
>>: Detaillierte Erklärung des Unterschieds zwischen $router und $route in Vue
Das Protokoll der Ressourcendatei weglassen Es wi...
1. Zusammenfassung: Im Allgemeinen können sie in ...
1. Geben Sie den Befehl mysqld --skip-grant-table...
Wenn die Tabelle Zehntausende Datensätze enthält,...
Da Frameset und Body auf derselben Ebene liegen, k...
Inhaltsverzeichnis Vorwort Was ist ein Filter So ...
Sie werden oft HTML mit Datenattributen sehen. Die...
Das <script>-Tag In HTML5 hat Skript die fo...
Inhaltsverzeichnis Text LOCK-Parameter ALGORITHMU...
Inhaltsverzeichnis 1. Einführung in FastDFS 1. Ei...
Problemerklärung: Wenn Sie die CSS-Eigenschaft „a...
In diesem Artikel werden die spezifischen Schritt...
In diesem Artikel werden die Installationsschritt...
Daten in MySQL-Datenbank einfügen. Bisher häufig ...
Tatsächlich haben viele Unternehmen ähnliche Funk...