Posts: 666
Joined: Dec 2008
Reputation:
0
motd2k
Team-XBMC Developer
Posts: 666
Just a thought, do you have any RSS feeds configured?
Posts: 170
Joined: Jan 2009
Reputation:
0
Nope, none.... After running for another 2 days the memory consumption now has grown from 155M to 700M:
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
1083 xbmc 20 0 710m 96m 36m S 17 2.9 433:13.14 xbmc.bin
I'll wait for another 2-3 days till the main linuxport branch is stabilized a bit (after the merge of VDPAU) and try to upgrade to the latest SVN revision. Will see if it makes a difference (I'm still running a 'pre-merge' build I believe).
Also, the log file is small - 2Mb and seems to be rolled over to the '.old' when it gets to 5Mb.
Vlad
Posts: 3,555
Joined: Oct 2003
Reputation:
12
tslayer
Team-XBMC Developer
Posts: 3,555
It gets rolled to .old when you restart XBMC.
42.7% of all statistics are made up on the spot
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Posts: 170
Joined: Jan 2009
Reputation:
0
Oh, didn't know... In any case, the log file size is quite small - 1-2M - much less than memory utilization. Why in particular the _virtual_ memory utilization is so high?...
Posts: 3,555
Joined: Oct 2003
Reputation:
12
tslayer
Team-XBMC Developer
Posts: 3,555
VIRT isn't just RAM. That is what RES is.
I wouldn't worry too much about the VIRT unless you are seeing some problems.
VIRT -- Virtual Image (kb)
The total amount of virtual memory used by the task. It includes all code, data and shared libraries plus pages that have been swapped out.
42.7% of all statistics are made up on the spot
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Posts: 3,555
Joined: Oct 2003
Reputation:
12
tslayer
Team-XBMC Developer
Posts: 3,555
Here is a great explanation:
3. The difference among VIRT, RES, and SHR in top output
VIRT stands for the virtual size of a process, which is the sum of memory it is actually using, memory it has mapped into itself (for instance the video card's RAM for the X server), files on disk that have been mapped into it (most notably shared libraries), and memory shared with other processes. VIRT represents how much memory the program is able to access at the present moment.
RES stands for the resident size, which is an accurate representation of how much actual physical memory a process is consuming. (This also corresponds directly to the %MEM column.) This will virtually always be less than the VIRT size, since most programs depend on the C library.
SHR indicates how much of the VIRT size is actually sharable (memory or libraries). In the case of libraries, it does not necessarily mean that the entire library is resident. For example, if a program only uses a few functions in a library, the whole library is mapped and will be counted in VIRT and SHR, but only the parts of the library file containing the functions being used will actually be loaded in and be counted under RES.
42.7% of all statistics are made up on the spot
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Posts: 170
Joined: Jan 2009
Reputation:
0
Hmm... all right. Thanks for the detailed explanation... Still weird that VIRT memory grows uncontrollably. Is it a normal thing? Never noticed that in other processes...
Posts: 4,997
Joined: May 2004
Reputation:
12
It's probably just FS buffers. They persist until the system needs the RAM for something better at which point they're instantly and without exception revoked.
