Large File SFTP Transfers Use All Memory (RAM, etc.) -- System Hangs

[tracymission_it]

I've tried several times to transfer several large VMDK (VMware Disk) files via SFTP and noted that server hung several minutes into the transfer. I had walked away and could not determine why.

I started another transfer and watched the available RAM be reduced to 10% before I stopped Filezilla's transfer and closed the program. Upon closing the program, the RAM was not released. In fact, Process Viewer did not show the utilized RAM as associated with any program.

Confused further, I found a forum suggesting I run RAMMAN from Systernals to determine what was using all that memory. I found the VMDK file Filezilla was downloading was being transferred directly into RAM and the changes were not committing to disk as the download progressed. Smaller files (1-2MB, etc.) were committing to disk after the download was complete. The VMDK file I was downloading is ~56GB which is why the system's memory filled up and hung. There is not enough RAM to hold the entire VMDK.

I'm running the most recent stable release:

---

FileZilla Client

Version: 3.9.0.5

Build information:

Compiled for: i686-w64-mingw32
Compiled on: x86_64-unknown-linux-gnu
Build date: 2014-09-06
Compiled with: i686-w64-mingw32-gcc (GCC) 4.9.1
Compiler flags: -g -O2 -Wall -g -fexceptions -std=gnu++11

Linked against:

wxWidgets: 3.0.2
GnuTLS: 3.2.17
SQLite: 3.8.6

Operating system:

Name: Windows Server 2012 R2 (build 9600), 64-bit edition
Version: 6.3
Platform: 64 bit system

I've had to turn to WinSCP to do my transfers which is 50% slower than Filezilla. Please let me know if there is any other info you require.

[Tim Kosse]

Are you by chance using a virus scanner that scans each file as it is being written to, only passing the write to disk until after the file has been closed?

For a test, try completely uninstalling [*] all virus scanners and firewalls.

[*] Uninstalling is the only way to fully disable the various virtual device drivers installed by them.

[Alexander Schuch]

No reply for more than 28 days.