Too big memory usage

[FFAMax]

Hi!

I just found that BTSync eat too much memory and can destroy system.

Before start:

root@cp10 [/backup]# free -m

total used free shared buffers cached

Mem: 3948 841 3107 0 15 529

-/+ buffers/cache: 297 3651

Swap: 0 0 0

After start (~1 min):

root@cp10 [/backup]# free -m

total used free shared buffers cached

Mem: 3948 3762 186 0 15 528

-/+ buffers/cache: 3218 730

Swap: 0 0 0

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND

7864 root 25 0 2912m 2.7g 1708 R 98.7 70.9 0:22.03 SyncApp_x64_1.0

7921 spaze 17 0 114m 17m 9444 R 3.0 0.4 0:00.09 php

3484 mysql 15 0 285m 38m 3732 S 2.7 1.0 0:07.99 mysqld

May be possible to limit memory usage?

[GreatMarko]

BitTorrent Sync is currently in "alpha", and right now it does indeed have higher than you'd like/expect CPU and Memory usage across all platforms. These values also appear to be closely linked to the total number of files you're syncing (i.e. more files = higher CPU/Memory usage).

The developers are certainly aware of the general high CPU/Memory issues that users are experiencing, and I'm sure some optimizations are in the pipeline!

[rdebath]

Actually, it seems more related to the total number of files you have ever sync'ed.

Once a file's name gets into the sync.dat file (and so into memory) it never leaves, so as an ultimate endpoint the share may have no files but sync can still run out of memory.

[FFAMax]

So, as i understand, i can do two steps:

1. decrease number of files in shared folders

2. periodically restart daemon to release memory if number of files was decreased

It's correct?

Actually, it seems more related to the total number of files you have ever sync'ed.

Once a file's name gets into the sync.dat file (and so into memory) it never leaves, so as an ultimate endpoint the share may have no files but sync can still run out of memory.

[rdebath]

2. periodically restart daemon to release memory if number of files was decreased

It's correct?

Unfortunately no, currently the zombies breed.

Items are stored in the sync.dat file that record every file that has been deleted. Currently, these records are not cleaned out of the sync.dat file. The only way to remove them is to remove the share and start from clean. Furthermore, this must be done on ALL the peers at the same time because the deletion records in the sync.dat file are synchronised between peers. So if you reset one peer all the deletion records it had will be recreated from the other peers.