Kern Sibbald schrieb: > > VUMEM004-sd Version: 3.0.3 (18 October 2009) x86_64-pc-linux-gnu debian > > 5.0.3 Daemon started 17-Mär010 14:45, 321 Jobs run since started. > > Heap: heap=308,527,104 smbytes=309,185,337 max_bytes=309,318,227 > > bufs=22,688 max_bufs=22,921 Sizes: boffset_t=8 size_t=8 int32_t=4 int64_t=8 > > > > Not that critical. > > OK. 300MB is a lot, but if the SD is busy, it could be OK.
The SD is not that busy, what I see in my cacti graphs for the SD process is that the memory usage is constantly growing and never decreases again. After some weeks I have to restart the SD. > As far as I can see everything is reasonably well configured. There is no > reason for the SD to consume a lot of memory. Regarding the SD: I'm still not sure why the memory usage grows over time up to the point where the server starts swapping. I'll have look at it and eventually send a new mail if the SD starts consuming >2 GB RAM again. > The Dir, can consume a lot of memory, possibly 100-200 bytes (just a guess) > for each file which means 200 X 7,000,000 which is only 1.4GB if I count > right, so it can get big when it is creating the in memory list, and perhaps > it will be double that if your database backend "caches" the files in memory. > > So, anything up to about 3GB is not terribly unusual, but the memory load > should go down once the bsr file has been built. Regarding the DIR: I can understand that it needs large amounts of memory. The sever has 4 GB RAM, I'll try to upgrade it to 8 GB. Here are some stats during the directory tree build. before starting the restore Mem: 4063148k total, 1240788k used, 2822360k free, 27380k buffers Swap: 1951856k total, 0k used, 1951856k free, 1021460k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13792 root 20 0 51236 3176 2560 S 0 0.1 0:00.00 bacula-console 13705 bacula 20 0 120m 3028 1652 S 0 0.1 0:00.01 bacula-dir 11656 root 20 0 154m 2724 692 S 0 0.1 180:29.96 bacula-fd 13681 bacula 20 0 71280 2236 1244 S 0 0.1 0:00.00 bacula-sd peak of 3.1 GB RAM while building of the directory tree Mem: 4063148k total, 4004944k used, 58204k free, 2872k buffers Swap: 1951856k total, 30496k used, 1921360k free, 590084k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13705 bacula 20 0 3268m 3.1g 1704 S 97 79.2 0:16.64 bacula-dir 13792 root 20 0 51236 3176 2560 S 0 0.1 0:00.00 bacula-console 13681 bacula 20 0 71280 2236 1244 S 0 0.1 0:00.00 bacula-sd 11656 root 20 0 154m 1952 692 S 0 0.0 180:29.96 bacula-fd then after the tree was build down to 2,4 GB RAM Mem: 4063148k total, 3420196k used, 642952k free, 1696k buffers Swap: 1951856k total, 1235452k used, 716404k free, 661036k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13705 bacula 20 0 3320m 2.4g 1208 S 0 61.8 0:20.20 bacula-dir 13792 root 20 0 51236 1244 1168 S 0 0.0 0:00.00 bacula-console 13681 bacula 20 0 71280 840 792 S 0 0.0 0:00.00 bacula-sd 11656 root 20 0 154m 588 540 S 0 0.0 180:29.96 bacula-fd 1,6 GB after aborting the restore at the "OK to run?" prompt Mem: 4063148k total, 2599588k used, 1463560k free, 2216k buffers Swap: 1951856k total, 1223024k used, 728832k free, 668804k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 13705 bacula 20 0 2499m 1.6g 1460 S 0 41.4 0:20.98 bacula-dir 13792 root 20 0 51236 1264 1176 S 0 0.0 0:00.00 bacula-console 13681 bacula 20 0 71280 840 792 S 0 0.0 0:00.00 bacula-sd 11656 root 20 0 154m 588 540 S 0 0.0 180:29.96 bacula-fd Then bacula-dir then staid at 1,6 GB for the next 30 minutes. Ralf ------------------------------------------------------------------------------ Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev _______________________________________________ Bacula-devel mailing list Bacula-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bacula-devel
