Bug 109368
Summary: | rsync (all versions to 2.5.6) not returning memory properly | ||
---|---|---|---|
Product: | [Retired] Red Hat Linux | Reporter: | Phil Moses <pbmoses> |
Component: | rsync | Assignee: | Jay Fenlason <fenlason> |
Status: | CLOSED NOTABUG | QA Contact: | Mike McLean <mikem> |
Severity: | medium | Docs Contact: | |
Priority: | high | ||
Version: | 9 | CC: | jfeeney |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2003-11-07 15:42:02 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Phil Moses
2003-11-07 06:12:52 UTC
Difference in free RAM (from data above): (490 - 279) = 211 Difference in cache sizes (from to data above): (383 - 177) + (43 - 39) = 210 It didn't swallow your RAM, it just moved most of the free RAM to somewhere useful - in this case, the buffer/inode/dentry caches. Additionally, internal kernel data structures (vm, socket structures, cache entries, etc.) are allocated and freed all the time - even running 'free' affects them. I probably won't explain this perfectly, but here it comes: The data is cached based on the principle "Well, you just accessed this file's data, so I'm going to hold on to it incase you need it again ...". When you access new files or start other applications, I believe the least-recently-used cache data gets freed to make space for the incoming data/application. The reason the 'free' RAM 'jumps' when you remove the directory is simple: When you unlink (remove) a file, cache data about that file freed because they're no longer needed - if the file doesn't exist, you certainly won't be using its data any time soon. In this case, you're unlinking a lot of files. This means that a lot of cache information (that the system thought you might need) is freed. FYI - Running "cp -a <src> <dest>" should have a similar effect as using rsync. Clarification - rsync doesn't allocate/remove cache entries; this is one of the things the kernel does. Lon, Your explanation makes sense to me, thanks for that. ( I pretty much knew that if there were a problem it would have been noticed some time ago). This does however, raise a question which has been presented to me numerous times. According to your description, the least recently used cached data gets freed to make room for new applications. This being said, if it seemed as though 95% memory was used and an application such as Matlab is launched and run, then this least-recently-used would be allocated for the process such as Matlab which would explain why the swap space did not seem to be utilized. This is all making perfect sense now, thanks for the explanation. Indeed, Lon's behaviour explains things. The kernel will always try to keep files cached in RAM, because if a file was rsynced by the user there's a chance the user might want to use that file later on and it would be much faster if the file was already in RAM and didn't need to be read from disk. If an application needs the RAM, we can always reclaim it very easily. The data is already on disk, so we just forget that we had it in the cache and use the RAM for something else ... |