machine load extreme peaking for short periods....mouse not moving etc.

[Rashkae]

On 01/17/2013 03:25 PM, NoOp wrote:
> On 01/16/2013 05:19 AM, Rashkae wrote:
>> On 01/15/2013 09:43 PM, Peter Teuben wrote:
>>>
>>> free
>>>                total       used       free     shared    buffers     cached
>>> Mem:       3743260    3495904     247356          0      27360     755152
>>> -/+ buffers/cache:    2713392    1029868
>>> Swap:      3918844    1451692    2467152
>>>
>>>
>>>
>>> cat /proc/meminfo
>>> MemTotal:        3743260 kB
>>> MemFree:          277100 kB
>>> Buffers:           27108 kB
>>> Cached:           752332 kB
>>> SwapCached:       329216 kB
>>> Active:          2145832 kB
>>> Inactive:        1032840 kB
>>> Active(anon):    1941936 kB
>>> Inactive(anon):   900320 kB
>>> Active(file):     203896 kB
>>> Inactive(file):   132520 kB
>>> Unevictable:         120 kB
>>> Mlocked:             120 kB
>>> SwapTotal:       3918844 kB
>>> SwapFree:        2467096 kB
>>> Dirty:                52 kB
>>> Writeback:             0 kB
>>> AnonPages:       2189272 kB
>>> Mapped:           184252 kB
>>> Shmem:            442996 kB
>>> Slab:             106148 kB
>>> SReclaimable:      50592 kB
>>> SUnreclaim:        55556 kB
>>> KernelStack:        5592 kB
>>> PageTables:        69228 kB
>>> NFS_Unstable:          0 kB
>>> Bounce:                0 kB
>>> WritebackTmp:          0 kB
>>> CommitLimit:     5790472 kB
>>> Committed_AS:    9227052 kB
>>> VmallocTotal:   34359738367 kB
>>> VmallocUsed:      406168 kB
>>> VmallocChunk:   34359270300 kB
>>> HardwareCorrupted:     0 kB
>>> AnonHugePages:         0 kB
>>> HugePages_Total:       0
>>> HugePages_Free:        0
>>> HugePages_Rsvd:        0
>>> HugePages_Surp:        0
>>> Hugepagesize:       2048 kB
>>> DirectMap4k:      738496 kB
>>> DirectMap2M:     3147776 kB
>>
>> I did not think so at first, but your problem is indeed memory
>> consumption.  I am not, however, at all convinced that compiz has
>> anything to do with that.
>>
>> However, as shown here, your total memory commit is over 9 GB, (and your
>> commit limit should be 5 GB, which means your in territory where the
>> kernel will feel free to start OOM killing, which would explain your
>> periods of 'freezing up' while memory is sorting itself out.)   This is
>> really not normal.  *Something* has to be grabbing all that memory.
>
> I'm confused. Commit limit is correct if the
> /proc/sys/vm/overcommit_ratio is set to default of 50, isn't it?
>
> $ cat /proc/sys/vm/overcommit_ratio
> 50
>
> CommitLimit = ('vm.overcommit_ratio' * Physical RAM) + Swap
> (.50 x 3743260) + 3918844 = 5790472
>
> Commit_AS 9227052 is approx 63% of CommitLimit (579042) which doesn't
> seem unreasonable (to me).

You're misplacing decimal places all over the place.  Look at those 
numbers again.  (Change your e-mail font to fixed if you need help to 
lign up the digits.)

His Commit Limit is 5.something GB.  His Commit AS is over 9GB  (almost 
twice the commit limit.)  And his swap usage is already above 1.4GB. 
There is a memory leak there I could drive a truck through.