LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Software (https://www.linuxquestions.org/questions/linux-software-2/)
-   -   rsync memory usage over ssh (https://www.linuxquestions.org/questions/linux-software-2/rsync-memory-usage-over-ssh-585707/)

tajamari 09-18-2007 11:07 PM

rsync memory usage over ssh
 
Hello,

FAQ of rsync tsays that it uses a lot of memory and it uses more with -H and --delete options. The faq says about 100 bytes per file, which should translate to about 800MB. But on my rsync procedure, it ate up almost 97% of my 4gb memory on its initial run, and retain as it is. Is this because I am using --stats --recursive --delete -auvz options and over ssh? Im running rsync script every 20 minutes

What is the per-file overhead when all of those options are used? Is there a way to release the memory usage after the initial run of rsync? Thanks.

Taja

syg00 09-18-2007 11:52 PM

Quote:

Originally Posted by tajamari (Post 2896439)
But on my rsync procedure, it ate up almost 97% of my 4gb memory on its initial run, and retain as it is.

What makes you think that ???.

tajamari 09-19-2007 12:52 AM

Quote:

Originally Posted by syg00 (Post 2896473)
What makes you think that ???.

thats why im asking because if my theory is correct.im not saying am right.

syg00 09-19-2007 01:08 AM

I meant what evidence do you have - "free" sar, something else ???.
Show us the evidence so we can (hopefully) help explain it.

tajamari 09-19-2007 04:04 AM

Quote:

Originally Posted by syg00 (Post 2896509)
I meant what evidence do you have - "free" sar, something else ???.
Show us the evidence so we can (hopefully) help explain it.

ah ok. when i monitor realtime using top comand. Its always 97% utilized. on the sar output, the average for daily utlilizarion is 94.79%.

tajamari 09-19-2007 04:05 AM

Quote:

Originally Posted by tajamari (Post 2896592)
ah ok. when i monitor realtime using top comand. Its always 97% utilized. on the sar output, the average for daily utlilizarion is 94.79%.

here's the sar output

00:00:02 kbmemfree kbmemused %memused kbbuffers kbcached kbswpfree kbswpused %swpused kbswpcad
00:10:01 16920 4024616 99.58 623304 54276 12586748 140 0.00 108
00:20:02 45352 3996184 98.88 544060 16600 12586680 208 0.00 68
00:30:01 17920 4023616 99.56 648524 16312 12586680 208 0.00 0
00:40:02 45048 3996488 98.89 559316 16100 12586680 208 0.00 0
00:50:01 17088 4024448 99.58 645052 16044 12586680 208 0.00 0
01:00:01 474440 3567096 88.26 578052 18308 12586680 208 0.00 0
01:10:02 16064 4025472 99.60 626544 16328 12586680 208 0.00 0
01:20:01 474240 3567296 88.27 574412 19636 12586680 208 0.00 0
01:30:02 17008 4024528 99.58 629168 16424 12586680 208 0.00 0
01:40:01 43448 3998088 98.92 559504 15980 12586680 208 0.00 0
01:50:01 15904 4025632 99.61 634476 16488 12586680 208 0.00 0
02:00:01 478840 3562696 88.15 571100 16284 12586680 208 0.00 0
02:10:02 16440 4025096 99.59 635876 16040 12586680 208 0.00 0
02:20:01 477904 3563632 88.18 573504 16396 12586680 208 0.00 0
02:30:01 311328 3730208 92.30 632292 17652 12586680 208 0.00 0
Average: 164530 3877006 95.93 602346 19258 12586685 203 0.00 12

syg00 09-19-2007 03:25 PM

Nothing obviously wrong to me in that - need to know a "baseline" before your rsync. Presumably you couldn't see any obvious "bad" memory consumers when you were in top.

I'd be thinking inode/dentry consumption - this can be seen in /proc/slabinfo, or slabtop. Later kernels allow you to free these caches - I'd be looking to drop the caches, save the slabinfo, run the rsync, then re-save the slabinfo, and compare them.
drop_caches is likely to have an adverse effect (for a while) on a fileserver, so might not be acceptable depending on your situation. It's documented in the source tree at ../Documentation/filesystems/proc.txt, or "man proc" if you have the feature available on your kernel level.

Of course, having all the memory utilized may not be harming your systems ability to do the work, so you may be worrying needlessly too.That's for you to decide.

tajamari 09-19-2007 10:45 PM

Quote:

Originally Posted by syg00 (Post 2897145)
Nothing obviously wrong to me in that - need to know a "baseline" before your rsync. Presumably you couldn't see any obvious "bad" memory consumers when you were in top.

I'd be thinking inode/dentry consumption - this can be seen in /proc/slabinfo, or slabtop. Later kernels allow you to free these caches - I'd be looking to drop the caches, save the slabinfo, run the rsync, then re-save the slabinfo, and compare them.
drop_caches is likely to have an adverse effect (for a while) on a fileserver, so might not be acceptable depending on your situation. It's documented in the source tree at ../Documentation/filesystems/proc.txt, or "man proc" if you have the feature available on your kernel level.

Of course, having all the memory utilized may not be harming your systems ability to do the work, so you may be worrying needlessly too.That's for you to decide.

Thanks syg. There's no "bad" memory consumers, only ntp, snmp and heartbeat are running aside from the system reqired applications. on my baseline, after a fresh reboot, memory usage is only about 300 t0 400 MB, then when i ran the rsync, it peaks to 3.8 gig,

Im using 2.6.9-55.0.6.ELsmp kernel for CentOS 4.5.

chrism01 09-20-2007 04:02 AM

With Linux, if RAM is avail (ie unused), then Linux will use as much as possible to speed up the current program & cache it for further usage.
If you ran other progs as well, you'd see Linux re-proportion the usage amongst all the running progs.

syg00 09-20-2007 05:52 AM

Generally true, but the data presented doesn't support this being the case here. buffer/cache numbers don't account for the "extra" usage.


All times are GMT -5. The time now is 04:24 AM.