kswapd0 hoher load bei hdd mounten

S

sm4rty

Foren As
der titel sagt alles.....

kswapd hat bei mir nen load von 100% sowie ich nur versuche meine HDD zu mounten.

das gleiche passiert, wenn ich nen script starte, was datein in nen tar archiv packt.

ka wobei es noch alles passiert.

habt ihr ideen wo ich mit der fehlersuche beginnen kann?
 
Läuft der Swap dabei tatsächlich voll? kswapd sollte ja eigentlich nur Last verursachen, wenn tatsächlich in den Swap geschrieben oder daraus gelesen wird. Ist evtl. bei dir eh sehr viel Kram im Swap, so dass bei System-Aktionen die beteiligten Programme darauf zugreifen müssen?
 
ich weiß nicht ob der swap volläuft.

ich weiß nur dass er komischerweise nicht rumrödelt, wenn ich die platte zum boot gleich mitmounten lasse mit der fstab
 
Dann solltest du evtl. das Verhalten mittels 'free', 'top' etc. mal genauer beobachten.
 
hab ich versucht, sowie ich mount benutzt hab, hat er angefangen zu swappen...

war mir zu umständlich da noch weiter zu suchen, weil ich noch nicht so viel eingerichtet hatte....
hab einfach nochmal neu installiert eben.

trotzdem vielen dank für die hilfe
 
Das ist aber nicht wirklich die Problemlösung - Böse Swapper kommen manchmal wieder.
Beim nächsten mal sinnigerweise Ursachenforschung betreiben - nur so lernt man sein System kennen,
alldieweil bei Linux ja alles offen ist.
 
jop fehelr ist wieder da *kotz*

nur ich weiß nicht woran es liegen kann :(

das is htop ausgabe vor dem mounten der platte.....
hab swap mal deaktiviert, weil es leider bei der install nicht anders ging.
wg:~# htop

1 [ 0.0%] Tasks: 28 total, 1 running
2 [ 0.0%] Load average: 0.44 0.44 0.18
3 [ 0.0%] Uptime: 00:02:55
4 [ 0.0%]
Mem[||| 19/1003MB]
Swp[ 0/0MB]

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
2677 root 20 0 2412 1132 932 R 1.1 0.1 0:00.12 htop
1 root 20 0 2100 688 588 S 0.0 0.1 0:02.01 init [2]
1130 root 16 -4 2288 788 488 S 0.0 0.1 0:00.34 udevd --daemon
2023 daemon 20 0 1892 508 416 S 0.0 0.0 0:00.00 /sbin/portmap
2034 statd 20 0 1956 720 620 S 0.0 0.1 0:00.02 /sbin/rpc.statd
2083 root 18 -2 2180 412 288 S 0.0 0.0 0:00.00 dhclient3 -pf /var
2269 root 20 0 28292 1432 940 S 0.0 0.1 0:00.00 /usr/sbin/rsyslogd
2270 root 20 0 28292 1432 940 S 0.0 0.1 0:00.00 /usr/sbin/rsyslogd
2267 root 20 0 28292 1432 940 S 0.0 0.1 0:00.08 /usr/sbin/rsyslogd
2278 root 20 0 1764 584 496 S 0.0 0.1 0:00.00 /usr/sbin/acpid
2296 root 20 0 5412 1016 664 S 0.0 0.1 0:00.00 /usr/sbin/sshd
2563 Debian-e 20 0 6248 900 612 S 0.0 0.1 0:00.00 /usr/sbin/exim4 -b
2589 root 20 0 7064 1528 1100 S 0.0 0.1 0:00.00 /usr/sbin/nmbd -D
2591 root 20 0 12484 2576 1940 S 0.0 0.3 0:00.02 /usr/sbin/smbd -D


wie man sieht sind 19mb belegt.

und das beim mounten:


wg:~# htop

1 [|||||||||| 31.6%] Tasks: 1340 total, 1 running
2 [|||||||||| 29.4%] Load average: 0.23 0.20 0.14
3 [||||||||||| 34.8%] Uptime: 00:10:43
4 [|||||||| 25.0%]
Mem[||||||||||||||| 980/1003MB]
Swp[ 0/0MB]

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
6062 root 20 0 5184 1740 424 S 100. 0.2 0:00.00 -bash
6086 root 20 0 5220 1776 424 S 100. 0.2 0:00.00 -bash
6104 root 20 0 5248 1804 424 S 100. 0.2 0:00.00 -bash
6119 root 20 0 5268 1824 424 S 100. 0.2 0:00.00 -bash
6174 root 20 0 5348 1904 424 S 100. 0.2 0:00.00 -bash
6274 root 20 0 5492 2048 424 S 100. 0.2 0:00.00 -bash
6349 root 20 0 5596 2152 424 S 100. 0.2 0:00.00 -bash
6369 root 20 0 5628 2184 424 S 100. 0.2 0:00.00 -bash
6375 root 20 0 5636 2192 424 S 100. 0.2 0:00.00 -bash
6511 root 20 0 5832 2388 424 S 100. 0.2 0:00.00 -bash
6598 root 20 0 5956 2512 424 S 100. 0.2 0:00.00 -bash
6605 root 20 0 5964 2520 424 S 100. 0.2 0:00.00 -bash
2677 root 20 0 2936 1176 472 R 11.2 0.1 0:06.69 htop
6085 root 20 0 5216 1772 424 S 2.2 0.2 0:00.04 -bash

woran kann es liegen, dass er den ram so vollknallt beim mounten?

vollkommen egal was ich mach, alles geht.
aber sowie der befehl mit mount anfängt rödelt er rum und kackt ab.
sogar wenn ich mount --help eingebe knallt er den ram voll und schmiert ab
 
Zuletzt bearbeitet:
Klingt sehr nach einem Bug im Mount-Programm. Hast du da wirklich soviele Shells offen, oder werden die durch's Mounten geöffnet? Sieht ja fast aus wie bei einer Forkbombe. ;) Ist 'mount' bei deiner Distro evtl. ein Skript?
 
hmm ok jetzt hat er das auch bei apt-get update gemacht.
ich hab keine ahnugn wo ich anfangen kann zu suchen ...


/usr/local/bin/mount: fork: Nicht genügend Hauptspeicher verfügbar
/usr/local/bin/mount: line 2: 15831 Getötet truecrypt /mnt/sda5/conti.tc --filesystem=none
/usr/local/bin/mount: line 2: 15829 Getötet truecrypt /mnt/sda5/conti.tc --filesystem=none
/usr/local/bin/mount: line 2: 15824 Getötet truecrypt /mnt/sda5/conti.tc --filesystem=none
/usr/local/bin/mount: line 2: 15822 Getötet truecrypt /mnt/sda5/conti.tc --filesystem=none

das kam jetzt bei df -h

das kuriose ist, gestern ging alles problemlos, mounten unmounten alles ging problemlos, sogar nach mehreren neustarts ging es und heute hab ich das teil hochgefahren und die probleme waren da
 
Zuletzt bearbeitet:
Ich würde mal bei truecrypt anfangen zu suchen und mal einen Memtest durchlaufen lassen. Gerade die letzte Meldung von wegen nicht genug Hauptspeicher sieht eher nach einem defekten RAM aus.
 
das lustige is, gestern ging alles und heute plötzlich kam das.
und es war das gleiche wie bei der letzten install.... erst ging alles und dann dieser fehler.

an truecrypt liegt es nicht, weil der scheiß auch kommt, wenn truecrypt nicht läuft.

an der hardware und an truecrypt kann es nicht liegen.
hat jemand ne idee wo ich ansetzen kann?
also softwaremäßig.

außerdem geht das image was ich von dem debian erstellt hab noch genauso wie gestern ohne diese hänger.

ist aber leider nur nen image was relativ klein ist und nicht alle funktionen enthält, damit das debian ausm ram laufen kann, was es auch so tut wie ich es will. nur wenn ich debian normal von der plate aus starte treten diese fehler auf.

oder kann es irgendwie sein, dass beim runterfahren der ram irgendwie voll bleibt und deswegen das debian diese fehlermeldung ausspuckt?
 
Zuletzt bearbeitet:
Der RAM bleibt beim Runterfahren mit Sicherheit nicht voll. Sobald der keinen Strom mehr hat, ist er auch leer und ich wage zu bezweifeln, dass du einen batteriegepufferten RAM wie in Memory-Caching-Servern hast. ;) Lass mal memtest durchlaufen. Für mich klingt das bisher eher nach einem defekten RAM, dessen Werte vom System nicht mehr korrekt ermittelt werden können und/oder der nicht mehr korrekt adressierbar ist. Im Worst-Case hat's eine Controller-Unit auf dem Motherboard zerhauen, was zwar möglich aber unwahrscheinlicher als ein simpler RAM-Fehler ist.
 
ja hast natürlich recht, dass der ram nicht erhalten bleibt, aber ich meine eher so ruhezustand mäßig, beim runterfahren des ramdisk debian schmeißt der irgendwas auf die platte und beim booten des normalen debian von platte klatscht der das wieder in ram und debian merkt quasi nicht, dass er voll ist.

naja jedenfalls liegts nicht am ram.
Ich betreibe mein debian grad aus dem ram heraus also ein 500mb großes debian was nur im ram liegt und alles von da aus läuft.
und ich kann die festplatten mounten umounten truecrypt nutzen wie ich will, es geht einfach nur.

nur wenn ich es von der festplatte aus starte, von der das ramimage gezogen ist treten diese fehler auf. (image wurde erstellt wo alles fehlerfrei lief) so und jetzt gehts von hd nicht mehr bekomme imemr diese ram fehlermeldungen, wenn ich aber alles in den ram schaufel und dann nur aus dem ram laufen lasse geht alles.

es liegt irgendwo am debian
es ist nicht der ram
 
Hm, das ist ja mal ein sehr seltsames Verhalten. In dem Fall solltest du mal schauen ob es evtl. Fehlermeldungen vom Kernel in /var/log/messages gibt, wenn du eine Partition mounten willst.
 
ich melde mich am sonntag wieder zecks dem problem, fahr jetzt übers WE heim und hab weder PC noch inet^^
 
so
bin grad wieder am rumtesten, hab aber absolut keine ahnung mehr woran es liegen kann.
in den ganzen scheiß log dateien war nichts in erfahrung zu bringen....

bin am verzweifeln, will das teil nicht schon wieder neumachen

das einzige was ansatzweise nach problem aussieht ist das hier:
Feb 8 17:50:00 wg kernel: [ 0.496154] system 00:01: iomem range 0xfed13000-0xfed19fff has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496171] system 00:06: ioport range 0x4d0-0x4d1 has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496177] system 00:06: ioport range 0x800-0x87f has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496183] system 00:06: ioport range 0x480-0x4bf has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496189] system 00:06: ioport range 0x900-0x90f has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496195] system 00:06: iomem range 0xfed1c000-0xfed1ffff has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496201] system 00:06: iomem range 0xfed20000-0xfed8ffff has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496216] system 00:08: iomem range 0xffc00000-0xfff7ffff could not be reserved
Feb 8 17:50:00 wg kernel: [ 0.496231] system 00:09: iomem range 0xfec00000-0xfec00fff has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496237] system 00:09: iomem range 0xfee00000-0xfee00fff could not be reserved
Feb 8 17:50:00 wg kernel: [ 0.496249] system 00:0a: ioport range 0x280-0x28f has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496254] system 00:0a: ioport range 0x290-0x29f has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496267] system 00:0b: iomem range 0xf0000000-0xf3ffffff has been reserved
Feb 8 17:50:00 wg kernel: [ 0.496279] system 00:0c: iomem range 0x0-0x9ffff could not be reserved
Feb 8 17:50:00 wg kernel: [ 0.496285] system 00:0c: iomem range 0xc0000-0xcffff could not be reserved
Feb 8 17:50:00 wg kernel: [ 0.496291] system 00:0c: iomem range 0xe0000-0xfffff could not be reserved
Feb 8 17:50:00 wg kernel: [ 0.496297] system 00:0c: iomem range 0x100000-0x3f7fffff could not be reserve

und hier ist noch nen bisschen was, was für mich verdächtig aussieht:

Feb 4 15:41:49 wg kernel: [ 528.281482] 20 pages mapped
Feb 4 15:41:49 wg kernel: [ 528.281486] 6852 pages slab
Feb 4 15:41:49 wg kernel: [ 528.281490] 12258 pages pagetables
Feb 4 15:41:49 wg kernel: [ 528.281497] Out of memory: kill process 2549 (exim4) score 1562 or a child
Feb 4 15:41:49 wg kernel: [ 528.282338] Killed process 2549 (exim4)
Feb 4 15:42:27 wg kernel: [ 578.050953] bash invoked oom-killer: gfp_mask=0x1201d2, order=0, oomkilladj=-17
Feb 4 15:42:27 wg kernel: [ 578.050966] Pid: 7858, comm: bash Not tainted 2.6.26-2-686 #1
Feb 4 15:42:27 wg kernel: [ 578.050993] [<c015915a>] oom_kill_process+0x4f/0x195
Feb 4 15:42:27 wg kernel: [ 578.051029] [<c0159584>] out_of_memory+0x14e/0x17f
Feb 4 15:42:27 wg kernel: [ 578.051054] [<c015b4ec>] __alloc_pages_internal+0x2b8/0x34e
Feb 4 15:42:27 wg kernel: [ 578.051078] [<c015b58e>] __alloc_pages+0x7/0x9
Feb 4 15:42:27 wg kernel: [ 578.051087] [<c015cf04>] __do_page_cache_readahead+0x86/0x163
Feb 4 15:42:27 wg kernel: [ 578.051106] [<c015d31b>] do_page_cache_readahead+0x3d/0x4a
Feb 4 15:42:27 wg kernel: [ 578.051122] [<c01589fa>] filemap_fault+0x164/0x35a
Feb 4 15:42:27 wg kernel: [ 578.051141] [<c0102b89>] setup_sigcontext+0x105/0x189
Feb 4 15:42:27 wg kernel: [ 578.051155] [<c0161d92>] __do_fault+0x42/0x34d
Feb 4 15:42:27 wg kernel: [ 578.051189] [<c0163f49>] handle_mm_fault+0x2d2/0x690
Feb 4 15:42:27 wg kernel: [ 578.051218] [<c011fa1b>] task_new_fair+0xbc/0xd5
Feb 4 15:42:27 wg kernel: [ 578.051235] [<c011b6fc>] default_wake_function+0x0/0x8
Feb 4 15:42:27 wg kernel: [ 578.051250] [<c0115b8f>] do_page_fault+0x2a3/0x5c0
Feb 4 15:42:27 wg kernel: [ 578.051265] [<c01158ec>] do_page_fault+0x0/0x5c0
Feb 4 15:42:27 wg kernel: [ 578.051265] [<c02b9eea>] error_code+0x72/0x78
Feb 4 15:42:27 wg kernel: [ 578.051265] =======================


_______________________________________________________________________________________________________________________________


Feb 4 15:42:27 wg kernel: [ 578.051265] free:2464 slab:6912 mapped:21 pagetables:12253 bounce:0
Feb 4 15:42:27 wg kernel: [ 578.051265] DMA free:4028kB min:68kB low:84kB high:100kB active:8956kB inactive:0kB present:16256kB pages_scanned:15910 all_unreclaimable? yes
Feb 4 15:42:27 wg kernel: [ 578.051265] lowmem_reserve[]: 0 873 991 991
Feb 4 15:42:27 wg kernel: [ 578.051265] Normal free:5716kB min:3744kB low:4680kB high:5616kB active:773548kB inactive:0kB present:894080kB pages_scanned:1204344 all_unreclaimable? yes
Feb 4 15:42:27 wg kernel: [ 578.051265] lowmem_reserve[]: 0 0 950 950
Feb 4 15:42:27 wg kernel: [ 578.051265] HighMem free:112kB min:128kB low:252kB high:380kB active:118604kB inactive:1180kB present:121600kB pages_scanned:10418 all_unreclaimable? no
Feb 4 15:42:27 wg kernel: [ 578.051265] lowmem_reserve[]: 0 0 0 0
Feb 4 15:42:27 wg kernel: [ 578.051265] DMA: 3*4kB 0*8kB 1*16kB 1*32kB 0*64kB 1*128kB 1*256kB 1*512kB 1*1024kB 1*2048kB 0*4096kB = 4028kB
Feb 4 15:42:27 wg kernel: [ 578.051265] Normal: 1*4kB 0*8kB 1*16kB 0*32kB 3*64kB 5*128kB 3*256kB 0*512kB 0*1024kB 0*2048kB 1*4096kB = 5716kB
Feb 4 15:42:27 wg kernel: [ 578.051265] HighMem: 0*4kB 0*8kB 1*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 112kB


_______________________________________________________________________________________________________________________________

Feb 4 16:16:47 wg modprobe: WARNING: Error inserting padlock_aes (/lib/modules/2.6.26-2-686/kernel/drivers/crypto/padlock-aes.ko): No such device

_______________________________________________________________________________________________________________________________

Feb 4 17:46:29 wg kernel: [ 0.004000] Memory: 1020532k/1040064k available (1770k kernel code, 18812k reserved, 750k data, 244k init, 122560k highmem)
 
Zuletzt bearbeitet:
Standard bitte mit d...
Er hat bereits eine Neuinstallation hinter sich. Und das ist unter Linux nicht direkt der beste Weg einen Fehler zu eliminieren.

Laut http://kerneltrap.org/mailarchive/linux-kernel/2008/6/5/2040464 ist das wohl eher kein Hinweis auf einen Fehler. Probier doch mal einen neueren Kernel (zur Not aus den Sourcen kompiliert) Ansonsten könntest du dich mit der Fehlermeldung an die Kernelmailingliste wenden..
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Noch was: Hast du das System mal ohne exim laufen lassen? Der hat ja oben den "Out of Memory"-Fehler. Evtl. ist da ja was kaputt..
 
Zuletzt bearbeitet:
nein hab ich nicht aber ich gugg mal ob ich es hinbekomm

ps: ich weiß nicht ob mir ne ubuntu doku was bringt bei nem debian, ja es basiert auf debian, aber es gibt ja doch grundlegende unterschiede

so: exim gekillt und wieder versucht ne platte zu mounten.
gleiche kacke wieder, ram läuft bis aufs letzte mb voll.
alle 4 kerne komplett ausgelastet und baaaaam nix passiert mehr
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Using username "root".
root@192.168.2.105's password:
Linux wg.serv 2.6.26-2-686 #1 SMP Sat Dec 26 09:01:51 UTC 2009 i686

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Mon Feb 8 18:56:39 2010
wg:~# htop

1 [|||||||||||||||||| 45.6%] Tasks: 2070 total, 2 running
2 [||||||| 16.2%] Load average: 1.72 0.48 0.19
3 [||||||||||||| 32.3%] Uptime: 00:12:42
4 [||||||| 17.7%]
Mem[|||||||||||||||||||||||||||990/1003MB]
Swp[ 0/0MB]

PID USER PRI NI VIRT RES SHR S CPU% MEM% TIME+ Command
6945 root 18 -2 10312 6452 4 S 100. 0.6 0:02.03 -bash
6946 root 18 -2 10316 6456 4 S 100. 0.6 0:00.76 -bash
2619 root 18 -2 2804 888 240 R 26.9 0.1 0:11.71 htop
6947 root 18 -2 10316 6488 36 R 18.9 0.6 0:03.00 -bash
2613 root 18 -2 8156 468 8 S 2.2 0.0 0:01.01 sshd: root@pts/0
2567 root 20 0 3424 164 4 S 2.2 0.0 0:00.26 /usr/sbin/cron
2646 root 18 -2 72380 1148 4 S 2.0 0.1 0:00.24 truecrypt /mnt/sda5/conti.tc --f
2644 root 18 -2 72380 1148 4 S 2.0 0.1 0:00.24 truecrypt /mnt/sda5/conti.tc --f
1 root 20 0 2100 112 8 S 1.2 0.0 0:03.09 init [2]
6944 root 18 -2 10312 6452 4 S 1.0 0.6 0:03.35 -bash
6916 root 18 -2 10272 6412 4 S 0.0 0.6 0:00.08 -bash
6917 root 18 -2 10276 6416 4 S 0.0 0.6 0:00.00 -bash
6921 root 18 -2 10280 6420 4 S 0.0 0.6 0:00.12 -bash
6922 root 18 -2 10280 6420 4 S 0.0 0.6 0:00.00 -bash
6926 root 18 -2 10288 6428 4 S 0.0 0.6 0:00.02 -bash
6927 root 18 -2 10288 6428 4 S 0.0 0.6 0:00.00 -bash
6938 root 18 -2 10304 6444 4 S 0.0 0.6 0:00.04 -bash
6939 root 18 -2 10304 6444 4 S 0.0 0.6 0:00.02 -bash
6940 root 18 -2 10308 6448 4 S 0.0 0.6 0:00.00 -bash
6943 root 18 -2 10312 6452 4 S 0.0 0.6 0:01.52 -bash
2620 root 18 -2 8156 464 4 S 0.0 0.0 0:01.01 sshd: [accepted]
6920 root 18 -2 10276 6416 4 S 0.0 0.6 0:00.32 -bash
6925 root 18 -2 10288 6428 4 S 0.0 0.6 0:00.12 -bash
6937 root 18 -2 10304 6444 4 S 0.0 0.6 0:00.08 -bash
6915 root 18 -2 10272 6412 4 S 0.0 0.6 0:00.16 -bash
6713 root 18 -2 9980 6120 4 S 0.0 0.6 0:00.00 -bash
6836 root 18 -2 10160 6300 4 S 0.0 0.6 0:00.00 -bash
6871 root 18 -2 10212 6352 4 S 0.0 0.6 0:00.00 -bash
6900 root 18 -2 10252 6392 4 S 0.0 0.6 0:00.00 -bash
6869 root 18 -2 10204 6344 4 S 0.0 0.6 0:00.09 -bash
6870 root 18 -2 10208 6348 4 S 0.0 0.6 0:00.14 -bash
6712 root 18 -2 9980 6120 4 S 0.0 0.6 0:00.02 -bash
6835 root 18 -2 10160 6300 4 S 0.0 0.6 0:00.02 -bash
6899 root 18 -2 10252 6392 4 S 0.0 0.6 0:00.02 -bash
6189 root 18 -2 9228 5368 4 S 0.0 0.5 0:00.00 -bash
6288 root 18 -2 9368 5508 4 S 0.0 0.5 0:00.00 -bash
F1Help F2Setup F3SearchF4InvertF5Tree F6SortByF7Nice -F8Nice +F9Kill F10Quit

so exim gekillt und versucht das verschlüsselte truecrypt teil zu mounten.
gleicher kack wieder wie man hier sieht.

mir fällt aber auf, dass er ein haufen bash's öffnet was eigentlich nicht sein sollte.

achja es liegt nicht am truecrypt, weil das öffnen des verschlüsselten containers geht.
nur dann der /dev/dm-0 lässt sich dann nicht mounten, da läuft er dann über.

verhält sich übrigens mit jedem datenträger den ich mounten will so.
manchmal passiert das auch bei apt-get install

ansonsten geht alles fehlerfrei
 
Zuletzt bearbeitet:
Auch wenn du einen USB-Stick mountest passiert das?? Mounten erfordert aber keine bash.. Ist das ein Standardsystem? Oder sind das irgendwelche eigenen Medien?
 

Ähnliche Themen

Windows clients können nicht mehr auf lange laufendes System zugreifen

Ubuntu X / dbus problem

CGI laesst sich nicht ausfuehren

Zurück
Oben