Wow, whats the most RAM your install uses?

[moriturimax]

OS Windows 7, 8GB of memory, AMD Turion II Neo N40L Dual-Core Processor 1.5GHz

My main computer that I use to sync things from all the other computers is at about 850,000KB to 980,00KB normal usage. Most files in any folder is about 65,000. Seems like I am having to restart Sync every half hour or so, it just starts giving me the "Not Responding" header on the window when I click in it.

So what is the most RAM you guys/gals have seen?

Love the program but man, I wish they would release a fix for the memory problem if nothing else.

[GreatMarko]

Please see the unofficial FAQ entry "Why is BitTorrent Sync's CPU/Memory usage high?"

...Memory & CPU optimizations are scheduled for the next update

[kos13]

Sync at the moment has linear memory grow that depends on amount of files. This will be changed in next builds.

[Syl]

glad to hear that

[rdebath]

Highest I've seen is about 5.3GBytes. On a share with about 300 files.

[GreatMarko]

Highest I've seen is about 5.3GBytes. On a share with about 300 files.

Hang on... you've seen BitTorrent Sync use 5.3GB of memory!???

[Xanza]

Idle CPU usage is pretty stable -- but once you begin to upload and download I've used as much as 2.4 GB of RAM. For me, with a total of 16GB DDR RAM that's not even 1/8th of my RAM, so no big deal there.

[rdebath]

Oh yes, Of course if there's a Windows client connected to the share it dies.

It takes a few minutes to create a million zero length files in a deep directory (maybe 5-10min), leave them for, say, 15 minutes, then delete them.

If you left them long enough for BTSync to notice a 32bit version will die; a 64bit version will kill any 32bit version that subsequently connects to the share. (Or maybe kill the machine that BTsync is running on.)

Like we've all said BTsync uses huge amounts of memory.

[moriturimax]

Did I misunderstand this last, is there a 32 and 64-bit version of the SyncApp? I only saw one download option for the SyncApp but maybve I missed it? Or were you talking about the OS? Regardless, as soon as I run it on one machine, it ramps up to about 1 gig of ram, then after a couple minutes grinds to a halt and doesn't do anything, hasn't killed the whole system yet.

[kos13]

Highest I've seen is about 5.3GBytes. On a share with about 300 files.

Can you please give us more details? Sync can't allocate that amount of memory for 300 files.

[rdebath]

Can you please give us more details? Sync can't allocate that amount of memory for 300 files.

Startup BT, run the script below on a share it's watching.

The share can be empty, that's not what matters.

I don't think this one will get you to 5Gb, BTsync gets too slow, but it's the right idea.

#!/bin/bash -

B=/home/btsync/zero/memuse
P=$B/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX

mkdir -p "$P"

for x in A B ; do
f=`date +%Y%m%d%H%M%S`
mkdir -p "$P/$f"
echo -ne "\r												 \rFile: $f :"
for k in \
		 00 01 02 03 04 05 06 07 08 09 \
		 10 11 12 13 14 15 16 17 18 19 \
		 20 21 22 23 24 25 26 27 28 29 \
		 30 31 32 33 34 35 36 37 38 39 \
		 40 41 42 43 44 45 46 47 48 49 \
		 50 51 52 53 54 55 56 57 58 59 \
		 60 61 62 63 64 65 66 67 68 69 \
		 70 71 72 73 74 75 76 77 78 79 \
		 80 81 82 83 84 85 86 87 88 89 \
		 90 91 92 93 94 95 96 97 98 99 \
; do
	 for j in \
			 00 01 02 03 04 05 06 07 08 09 \
			 10 11 12 13 14 15 16 17 18 19 \
			 20 21 22 23 24 25 26 27 28 29 \
			 30 31 32 33 34 35 36 37 38 39 \
			 40 41 42 43 44 45 46 47 48 49 \
			 50 51 52 53 54 55 56 57 58 59 \
			 60 61 62 63 64 65 66 67 68 69 \
			 70 71 72 73 74 75 76 77 78 79 \
			 80 81 82 83 84 85 86 87 88 89 \
			 90 91 92 93 94 95 96 97 98 99 \
	 ; do
		 for i in \
				 00 01 02 03 04 05 06 07 08 09 \
				 10 11 12 13 14 15 16 17 18 19 \
				 20 21 22 23 24 25 26 27 28 29 \
				 30 31 32 33 34 35 36 37 38 39 \
				 40 41 42 43 44 45 46 47 48 49 \
				 50 51 52 53 54 55 56 57 58 59 \
				 60 61 62 63 64 65 66 67 68 69 \
				 70 71 72 73 74 75 76 77 78 79 \
				 80 81 82 83 84 85 86 87 88 89 \
				 90 91 92 93 94 95 96 97 98 99 \
		 ; do :> "$P/$f/.$k$j$i"
		 done
echo -ne "\rFile: $f $k$j-- :"
	 done
done
done # x
echo -e "\r File: $f : Done"
echo -ne Waiting 15 minutes
sleep 900
echo -ne Removing
rm -rf "$B"

[rdebath]

Did I misunderstand this last, is there a 32 and 64-bit version of the SyncApp?

On Linux there are. The Windows one is currently 32bit only and really there shouldn't be any need for a 64bit version on any platform. (From the amount of memory that is.)

[kos13]

Startup BT, run the script below on a share it's watching.

The share can be empty, that's not what matters.

I don't think this one will get you to 5Gb, BTsync gets too slow, but it's the right idea.

#!/bin/bash -

B=/home/btsync/zero/memuse
P=$B/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX

If I read the script correctly it creates 1M files. Sync can consume 2Gb for 1M files, but not for 300 files.

[rdebath]

If I read the script correctly it creates 1M files. Sync can consume 2Gb for 1M files, but not for 300 files.

It creates two million files THEN DELETES THEM, once the script completes there are no extra files in the share. But the extra memory usage will stay, even after a restart of BTSync.

But, if you don't like that one, how about this more sneaky version; it only creates a thousand files so you'll have to leave it running for a few hours (lets say a day).

#!/bin/bash -

B=/home/btsync/zero/memuse
P=$B/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX/XXXXXXXXXXXXXXXXXXXXX

mkdir -p "$P"
touch "$P"/0
rm -rf "$P"/*

f=`date +%Y%m%d%H%M%S`
mkdir -p "$P/$f"
for j in \
	 00 01 02 03 04 05 06 07 08 09 \
; do
for i in \
		 00 01 02 03 04 05 06 07 08 09 \
		 10 11 12 13 14 15 16 17 18 19 \
		 20 21 22 23 24 25 26 27 28 29 \
		 30 31 32 33 34 35 36 37 38 39 \
		 40 41 42 43 44 45 46 47 48 49 \
		 50 51 52 53 54 55 56 57 58 59 \
		 60 61 62 63 64 65 66 67 68 69 \
		 70 71 72 73 74 75 76 77 78 79 \
		 80 81 82 83 84 85 86 87 88 89 \
		 90 91 92 93 94 95 96 97 98 99 \
; do :> "$P/$f/$j$i"
done
done

while :
do f=`date +%Y%m%d%H%M%S`
mv "$P"/* "$P/$f"
sleep 120
done

[kos13]

Even the file is deleted, Sync keeps record about this event. This record is needed for the following scenario: new peer connected and has the deleted file, Sync will need to decide whether it should be deleted on peer or this is new file that needs to be downloaded.

Therefore memory doesn't go down after deletion of the file. I described how it works now, but we are going to change that.

[Syl]

wow... I guess the versioning system will fix that.

no need to keep everything in memory if you have some kind of timestamp on each update/commit.