The system use xinetd to bind ~6K process, that works with many nfs mounts, and one USB card for some caching... At normal load the %sys is ~5%, in 3/4 days with the same workload, its grows to 100%... With a echo 3 > /proc/sys/vm/drop_caches the %sys load goes to normal state (~5%)
Created attachment 22784 [details] kernel config
Created attachment 22785 [details] cpuinfo
Created attachment 22786 [details] munin cpu graph
Created attachment 22787 [details] munin memory graph
Comment on attachment 22786 [details] munin cpu graph the down at 10h is when i did the drop_caches
Comment on attachment 22787 [details] munin memory graph the down at 10h is when i did the drop_caches
This morning, sys load is yet about ~65% freeing pagecache (echo 1) does nothing freeing dentries and inodes (echo 2) does the sys load goes down at ~5%
Created attachment 22859 [details] readprofile1
Created attachment 22860 [details] readprofile2
Created attachment 22861 [details] readprofile3
Created attachment 22862 [details] readprofile4
(delay between profiles = 10mn) readprofile1 & 2 normal after reboot readprofile3 & 4 => 4 cores are fully used by the system...
I post 4 new readprofiles of today 2009-08-27... I cleaned the counters before getting the reports... The firsts 2 are before drop_caches, 2 others are after... It seems that rpcauth_lookup_credcache takes all the time...
Created attachment 22874 [details] readprofile - 2009-08-27 - before drop_caches - delay 10s after a reset
Created attachment 22875 [details] readprofile - 2009-08-27 - before drop_caches - delay 60s after a reset
Created attachment 22876 [details] readprofile - 2009-08-27 - after drop_caches - delay 10s after a reset
Created attachment 22877 [details] readprofile - 2009-08-27 - after drop_caches - delay 60s after a reset
Created attachment 22986 [details] 2009-09-03 - with the debug/profiling kernel
Created attachment 22987 [details] 2009-09-03 - 60s readprofile