# kswapd0 takes 100% CPU **URL:** \ **Category:** SLES Configure-Administer\ **Created:** [November 28, 2013, 2:34pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818 "2013-11-28T14:34:27Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![tojanov](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@tojanov](https://forums.suse.com/u/tojanov)\ **Post date:** [November 28, 2013, 2:34pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/1 "2013-11-28T14:34:27Z")
Hi there, after updateing SLES 11 SP2 to SP3 i have different servers, which take 100% CPU (1 Core) für kswapd0. All servers are VM and running on same HyperV Cluster. Some machines have this bug, some not and i don’t know why. After reboot such a buggy system, everything runs fine for a few hours, in some cases for a few days. All systems are up to date and using the same Kernel. ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [November 28, 2013, 2:51pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/2 "2013-11-28T14:51:07Z")
Hi tojanov, a few things I’d like to know about the situation: - How’s memory usage when kswapd hits the roof? (“free -m”) - Do you have swap space configured? - Does it go away after some time, all by itself? - Does purging the cache help? (“sync;echo 3 \> /proc/sys/vm/drop\_caches”) - Could you please report the actual kernel version(s) of the affected systems? This would be helpful if forwarding this case to our SUSE back-ends… - Do you have an active support subscription (not only updates - may you open support requests)? This may quickly turn into a case a support engineer ought to have a look at, since the actual cause can be one of several. (I’d rule out bad memory as it has hit several servers after the update, so this may be a question of proper memory tuning or even a kernel problem). The usual conclusion for similar reports was that this can be caused by bad memory or a low memory situation. Regards, Jens ---
**Author:** ![tojanov](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@tojanov](https://forums.suse.com/u/tojanov)\ **Post date:** [November 28, 2013, 3:15pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/3 "2013-11-28T15:15:22Z")
Hi Jens, thanks for your quickly post. The systems are running with 4gb memory and 2gb of swap partition. Swap seems not to be needed, because memory usage at most time is under 50% inluded cache mem. ``` total used free shared buffers cached ``` Mem: 3825 1907 1918 0 248 1532 -/+ buffers/cache: 126 3699 Swap: 2055 0 2055 There is not more load ore some special activitiy which induces the problem. I only can resolve it by rebooting for some hours, is never go away by itself. But thanks für you advice by purging the cache …it works !!! But what does that mean for me?? I use Kernel 3.0.93-0.8-default and updated yesterday 1 machine to 3.0.101-0.8-default, but the problem still exists with this kernel version. Of course we have active support subscriptions, but first i would have a look if this is a known bug in the community and hope to be able to fix it myself. ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [November 28, 2013, 3:24pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/4 "2013-11-28T15:24:33Z")
Hi tojanov, [QUOTE=tojanov;17753] […]But thanks für you advice by purging the cache …it works !!! But what does that mean for me?? […] Of course we have active support subscriptions, but first i would have a look if this is a known bug in the community and hope to be able to fix it myself.[/QUOTE] it might be an upstream kernel problem, the net is full of reports on this. I’ll ask my SuSE contact for advice, since I cannot tell which fixes/improvement from later kernels were back-ported to the SLES kernels, that’s something the developers will have to answer. I’ll get back to you once I have a proper reply, but due to the holiday season, this may take a few days… Regards, Jens ---
**Author:** ![Jens-U](https://avatars.discourse-cdn.com/v4/letter/j/d78d45/32.png) [@Jens-U](https://forums.suse.com/u/Jens-U)\ **Post date:** [December 13, 2013, 1:36pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/5 "2013-12-13T13:36:33Z")
Hi tojanov, could you collect /proc/meminfo and /proc/vmstat while kswapd is at 100% CPU (taken every 1s or so)? This would help further diagnosing the effect. Is this by chance a NUMA machine? Regards, Jens ---
**Author:** ![tojanov](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@tojanov](https://forums.suse.com/u/tojanov)\ **Post date:** [December 23, 2013, 11:10am UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/6 "2013-12-23T11:10:09Z")
Hi and sorry for my late reply. here are the logs: > [@](#): > > cat /proc/meminfo > MemTotal: 3917640 kB > MemFree: 3018940 kB > Buffers: 223684 kB > Cached: 458328 kB > SwapCached: 0 kB > Active: 669160 kB > Inactive: 93120 kB > Active(anon): 68964 kB > Inactive(anon): 11496 kB > Active(file): 600196 kB > Inactive(file): 81624 kB > Unevictable: 0 kB > Mlocked: 0 kB > SwapTotal: 2104476 kB > SwapFree: 2104476 kB > Dirty: 280 kB > Writeback: 0 kB > AnonPages: 80304 kB > Mapped: 22688 kB > Shmem: 192 kB > Slab: 60184 kB > SReclaimable: 35048 kB > SUnreclaim: 25136 kB > KernelStack: 1608 kB > PageTables: 7308 kB > NFS\_Unstable: 0 kB > Bounce: 0 kB > WritebackTmp: 0 kB > CommitLimit: 4063296 kB > Committed\_AS: 464796 kB > VmallocTotal: 34359738367 kB > VmallocUsed: 35544 kB > VmallocChunk: 34359695356 kB > HardwareCorrupted: 0 kB > AnonHugePages: 26624 kB > HugePages\_Total: 0 > HugePages\_Free: 0 > HugePages\_Rsvd: 0 > HugePages\_Surp: 0 > Hugepagesize: 2048 kB > DirectMap4k: 44992 kB > DirectMap2M: 4149248 kB > [@](#): > > cat /proc/vmstat > nr\_free\_pages 754750 > nr\_inactive\_anon 2874 > nr\_active\_anon 17193 > nr\_inactive\_file 20408 > nr\_active\_file 150051 > nr\_unevictable 0 > nr\_mlock 0 > nr\_anon\_pages 13363 > nr\_mapped 5641 > nr\_file\_pages 170504 > nr\_dirty 84 > nr\_writeback 0 > nr\_slab\_reclaimable 8746 > nr\_slab\_unreclaimable 6290 > nr\_page\_table\_pages 1775 > nr\_kernel\_stack 197 > nr\_unstable 0 > nr\_bounce 0 > nr\_vmscan\_write 0 > nr\_vmscan\_immediate\_reclaim 0 > nr\_writeback\_temp 0 > nr\_isolated\_anon 0 > nr\_isolated\_file 0 > nr\_shmem 48 > nr\_dirtied 7422473 > nr\_written 6878676 > numa\_hit 1563044047 > numa\_miss 0 > numa\_foreign 0 > numa\_interleave 4894 > numa\_local 1563044047 > numa\_other 0 > nr\_anon\_transparent\_hugepages 13 > nr\_dirty\_threshold 378110 > nr\_dirty\_background\_threshold 94527 > pgpgin 71768191 > pgpgout 45388604 > pswpin 0 > pswpout 0 > pgalloc\_dma 9 > pgalloc\_dma32 1590204000 > pgalloc\_normal 16195 > pgalloc\_movable 0 > pgfree 1590975539 > pgactivate 4828774 > pgdeactivate 2884 > pgfault 5027834737 > pgmajfault 7267 > pgrefill\_dma 0 > pgrefill\_dma32 2368 > pgrefill\_normal 0 > pgrefill\_movable 0 > pgsteal\_dma 0 > pgsteal\_dma32 3461797 > pgsteal\_normal 0 > pgsteal\_movable 0 > pgscan\_kswapd\_dma 0 > pgscan\_kswapd\_dma32 3464385 > pgscan\_kswapd\_normal 599 > pgscan\_kswapd\_movable 0 > pgscan\_direct\_dma 0 > pgscan\_direct\_dma32 0 > pgscan\_direct\_normal 0 > pgscan\_direct\_movable 0 > pgscan\_direct\_throttle 0 > zone\_reclaim\_failed 0 > pginodesteal 0 > slabs\_scanned 24710144 > kswapd\_steal 3461797 > kswapd\_inodesteal 15784638 > kswapd\_low\_wmark\_hit\_quickly 0 > kswapd\_high\_wmark\_hit\_quickly 1115988083510 > kswapd\_skip\_congestion\_wait 0 > pageoutrun 1115988083512 > allocstall 0 > pgrotated 62 > compact\_blocks\_moved 0 > compact\_pages\_moved 0 > compact\_pagemigrate\_failed 0 > compact\_stall 0 > compact\_fail 0 > compact\_success 0 > htlb\_buddy\_alloc\_success 0 > htlb\_buddy\_alloc\_fail 0 > unevictable\_pgs\_culled 1305 > unevictable\_pgs\_scanned 0 > unevictable\_pgs\_rescued 6429 > unevictable\_pgs\_mlocked 6451 > unevictable\_pgs\_munlocked 6451 > unevictable\_pgs\_cleared 0 > unevictable\_pgs\_stranded 0 > unevictable\_pgs\_mlockfreed 0 > thp\_fault\_alloc 518 > thp\_fault\_fallback 0 > thp\_collapse\_alloc 29 > thp\_collapse\_alloc\_failed 0 > thp\_split 9 The HyperV hosts, where the SLES VM’s are running, use NUMA technology. But the problem only exists on a few of them. ---
**Author:** ![tojanov](https://avatars.discourse-cdn.com/v4/letter/t/a8b319/32.png) [@tojanov](https://forums.suse.com/u/tojanov)\ **Post date:** [January 23, 2014, 4:31pm UTC](https://forums.suse.com/t/kswapd0-takes-100-cpu/24818/7 "2014-01-23T16:31:51Z")
Your PM quota is full 😉 I can only select openSuse platform, if i would open a bug in the bugtracker. There is no SLES, is that right and should i chose this one?