#1 Map memory wrong

closed
nobody
None
5
2007-10-13
2007-10-09
Vieugy
No

Collectl reports wrong value for "map memory". For example, I know my application maps 3.5 Gb but it reports a very small value (168) in the ".tab" file during the whole job. Below is the beginning of the ".tab" file.

################################################################################
# Collectl: V2.3.2 HiRes: 1 Options: -r00:01,7 -F60 -oz
# Host: o184i086 DaemonOpts:
# Date: 20071001-203835 Secs: 1191263915 TZ: +0200
# SubSys: cdmnstx SubOpts: Options: z Interval: 2 NumCPUs: 4
# HZ: 100 Arch: x86_64-linux-thread-multi PageSize: 4096
# Cpu: GenuineIntel Speed(MHz): 2999.000 Cores: 2 Siblings: 2
# Kernel: 2.6.16.46-0.12-smp Memory: 32963232 kB Swap: 2104504 kB
# NumDisks: 2 DiskNames: c0d0 c1d0
# NumNets: 6 NetNames: lo eth0 eth1 sit0 ib0 ib1
# IConnect: NumHCAs: 1 PortStates: 11 IBVersion: 1.2.5
################################################################################
#Date Time [CPU]User% [CPU]Nice% [CPU]Sys% [CPU]Idle% [CPU]Wait% [CPU]Totl% [CPU]Intrpt/sec [CPU]Ctx/sec [CPU]Proc/sec [CPU]ProcQue [CPU]ProcRun [CPU]L-Avg1 [CPU]L-Avg5 [CPU]L-Avg15 [MEM]Tot [MEM]Used [MEM]Free [MEM]Shared [MEM]Buf [MEM]Cached [MEM]Slab [MEM]Map [MEM]Commit [MEM]SwapTot [MEM]SwapUsed [MEM]SwapFree [MEM]Dirty [MEM]Clean [MEM]Laundry [MEM]Inactive [MEM]PageIn [MEM]PageOut [SOCK]Used [SOCK]Tcp [SOCK]Orph [SOCK]Tw [SOCK]Alloc [SOCK]Mem [SOCK]Udp [SOCK]Raw [SOCK]Frag [SOCK]FragMem [NET]RxPktTot [NET]TxPktTot [NET]RxKBTot [NET]TxKBTot [NET]RxCmpTot [NET]RxMltTot [NET]TxCmpTot [NET]RxErrsTot [NET]TxErrsTot [DSK]ReadTot [DSK]WriteTot [DSK]OpsTot [DSK]ReadKBTot [DSK]WriteKBTot [DSK]KbTot [DSK]ReadMrgTot [DSK]WriteMrgTot [DSK]MrgTot [IB]InPkt [IB]OutPkt [IB]InKB [IB]OutKB [IB]Err [TCP]PureAcks [TCP]HPAcks [TCP]Loss [TCP]FTrans
20071001 20:38:38 0 0 2 73 25 27 12950 5717 15 159 0 1 1 1 32963232 253200 32710032 0 2304 110776 26400 16352 174668 2104504 168 2104336 44376 0 0 93608 391 0 216 24 0 31 30 16 22 0 0 0 8193 5607 11966 553 0 0 0 0 0 7 0 7 782 0 782 0 0 0 2 2 1 1 16 0 898 0 0
20071001 20:38:40 0 0 1 74 24 26 12909 5529 1 159 0 1 1 1 32963232 298584 32664648 0 2304 154980 26900 16352 173348 2104504 168 2104336 66776 0 0 138328 0 0 216 24 0 31 30 24 22 0 0 0 8214 5629 11977 556 0 0 0 0 0 0 0 0 0 0 0 0 0 0 3 3 1 1 16 0 890 0 0
20071001 20:38:42 0 0 1 75 24 25 12935 5587 1 159 0 1 1 1 32963232 344044 32619188 0 2412 200104 27364 16352 172876 2104504 168 2104336 89440 0 0 183416 0 54 216 24 0 31 30 24 22 0 0 0 8207 5613 11978 555 0 0 0 0 0 0 1 1 0 108 108 0 12 12 2 2 1 1 16 0 894 0 0

Discussion

  • Logged In: NO

    can you supply more info? For example does it do this when you run it in brief or verbose mode (not with -P)? The main reason I ask is all that collectl does is report what's in /proc/meminfo, so if it's reporting the wrong value it's a bug in collectl, otherwise it's a problem with the kernel.

    In fact, the easiest thing to do is if you can repeat this, do a cat of /proc/meminfo and see what it says.

     
  • Vieugy
    Vieugy
    2007-10-11

    Logged In: YES
    user_id=1909093
    Originator: YES

    I checked /proc/meminfo and the problem is with the kernel SLES 10 SP1. You can close this bug.
    Thanks.

     
  • Mark Seger
    Mark Seger
    2007-10-13

    • status: open --> closed