Brandon Holland
After updating to the latest version of Smartftp, I have been hit with a memory leak which slows down my computer to a crawl. I'm running windows 7 64bit.
Memory Leak
mb
Please provide steps on how to reproduce.
Brandon Holland
Have absolutely no idea. After changing the multi-part transfer rate from 4 parts to 6, the leak sprung up. Now after changing it back to 4, the leak persists.
mb
If you don't use multi part transfers, do you still have the memory leak?
Purgatory
Hey mb.
I can concur with the poster's memory issue, I'm having the exact same issue. When files are multi-parts of 4 or more, and the file is larger than 6GB, you have a huge memory spike, in my case all the way to 1GB+ and then the software crashed due to being out of memory. High CPU is what I have as well as the memory issue. If the file is 1 or 2GB or smaller, there does not same to be an issue as far as I could diagnose.
First saw this with build 1227 and now 1228. I upgraded to 1228 expecting 1227 issue to just be a fluke.
This high memory/CPU issue is happening on both Windows XP and Windows 7-x64.
Hope the info can help you with tracing the culprit.
Later,
I can concur with the poster's memory issue, I'm having the exact same issue. When files are multi-parts of 4 or more, and the file is larger than 6GB, you have a huge memory spike, in my case all the way to 1GB+ and then the software crashed due to being out of memory. High CPU is what I have as well as the memory issue. If the file is 1 or 2GB or smaller, there does not same to be an issue as far as I could diagnose.
First saw this with build 1227 and now 1228. I upgraded to 1228 expecting 1227 issue to just be a fluke.
This high memory/CPU issue is happening on both Windows XP and Windows 7-x64.
Hope the info can help you with tracing the culprit.
Later,
mb
Please provide sufficient information on how to reproduce the problem:
- What protocol are you using? If FTP, is the data connection protected?
- Does it happen with 2.5GB files?
- Build 1228? Do you mean build 1278?
- What protocol are you using? If FTP, is the data connection protected?
- Does it happen with 2.5GB files?
- Build 1228? Do you mean build 1278?
Purgatory
Please provide sufficient information on how to reproduce the problem:
- What protocol are you using? If FTP, is the data connection protected?
Yes, downloading via SFTP over SSH. 10mins and 600+MB into the download, 1.03GB of RAM used and CPU spike to 42/45%. Either 4 Multi Parts or 6, same results.
- Does it happen with 2.5GB files?
Haven't tested with a file size of that size. Will create one and test shortly and reply with results.
- Build 1228? Do you mean build 1278?
Oh! Sorry about that, I meant to type build 1278 and 1277. Getting old.
*
I've just finished downloading that 16GB file via regular FTP port 21, no issues, memory use normal (6 to 10MB), CPU 2 to 3% use. MD5 hash shows the file is 100%.
Purgatory
Ok, tested with a 2.65GB file, zero issues when downloading via SFTP over SSH with 6 Multi Parts for the file. Speed, memory and CPU all normal and as expected.- Does it happen with 2.5GB files?
/End of report.
mb
I tried to reproduce it with a 92GB file, 4 multi part workers, SFTP over SSH. Unfortunately so far without success.
Purgatory
Is there a trace option or debug I can turn on to test and send you the results?
mb
That won't help. We need to know how to trigger the problem.
Brandon Holland
I tried to reproduce it with a 92GB file, 4 multi part workers, SFTP over SSH. Unfortunately so far without success.
Have you tried it with 6 parts? After changing my multi-part settings to 6, the problem had begun.
Purgatory
Where can I download build 1274? Would like to test on same system to eliminate that as the cause. I know I would need to uninstall the newer build first.
mb
Did you try to monitor the process with Process Explorer?
http://technet.microsoft.com/en-us/sysi ... 96653.aspx
It tells you more about resource allocation (e.g. handles, private memory, etc). Maybe you will see something suspicious.
What you should also be aware of when downloading big files using multi part transfers is that the data is first filled with zeros (NTFS). Depending on the IO performance of your hard drive this may take several minutes. E.g. 100GB file / 30MB/s = 55 minutes.
http://technet.microsoft.com/en-us/sysi ... 96653.aspx
It tells you more about resource allocation (e.g. handles, private memory, etc). Maybe you will see something suspicious.
What you should also be aware of when downloading big files using multi part transfers is that the data is first filled with zeros (NTFS). Depending on the IO performance of your hard drive this may take several minutes. E.g. 100GB file / 30MB/s = 55 minutes.
Purgatory
Hey again.
No issues with memory or handles etc that I could see (I use Process Hacker). Nothing else is new or has been installed except for SmartFTP over the last 2 months. Unless it was Windows Updates. Could an update from MS be the possible cause?
I'm going to test on my Win7 system later tonight, from the same download server, same file. That computer still has an older version of SmartFTP installed, version 4.1 build 1265 (64-bit).
The memory issue and high CPU use only came about with build 1277/78 on my my XP system. Only happens when multi parts of 4 or more are active (in my case). No issues when the file is under 6GB. Has anything changed with the SSH part or any other file(s) related to SSH?
I see no other reports of this issue, so besides the other guy above, no one else seems to be affected, or not reporting it here.
I uninstalled (completely) all traces of SmartFTP 4.1 build 1278, registry entries, application folder etc. Installed version 4.1 build 1274, same issues as first stated. Can't say if it is my XP system, perhaps I had build 126X before jumping to the 127X builds and therefore no issue with those builds. ?
I'm going to look for a build 126X, 32-bit and test my XP system again, later tonight. If I get the same high memory/CPU issues with a 126X build, that will convince me that there is something odd with my system.
I'll report back on the outcome/results for both my Win7 system with build 1265 (first test for this problem) and my XP system with build 126X (once I find one to install, 2nd test for this problem) by Saturday.
No issues with memory or handles etc that I could see (I use Process Hacker). Nothing else is new or has been installed except for SmartFTP over the last 2 months. Unless it was Windows Updates. Could an update from MS be the possible cause?
I'm going to test on my Win7 system later tonight, from the same download server, same file. That computer still has an older version of SmartFTP installed, version 4.1 build 1265 (64-bit).
The memory issue and high CPU use only came about with build 1277/78 on my my XP system. Only happens when multi parts of 4 or more are active (in my case). No issues when the file is under 6GB. Has anything changed with the SSH part or any other file(s) related to SSH?
I see no other reports of this issue, so besides the other guy above, no one else seems to be affected, or not reporting it here.
I uninstalled (completely) all traces of SmartFTP 4.1 build 1278, registry entries, application folder etc. Installed version 4.1 build 1274, same issues as first stated. Can't say if it is my XP system, perhaps I had build 126X before jumping to the 127X builds and therefore no issue with those builds. ?
I'm going to look for a build 126X, 32-bit and test my XP system again, later tonight. If I get the same high memory/CPU issues with a 126X build, that will convince me that there is something odd with my system.
I'll report back on the outcome/results for both my Win7 system with build 1265 (first test for this problem) and my XP system with build 126X (once I find one to install, 2nd test for this problem) by Saturday.
mb
You should definitively see the memory usage in Process Explorer. If not how do do you monitor the memory usage? Task Managers shows the same information as Process Explorer.
Between 1274 and the latest build there were no significant changes in the SSH implementation.
Thank you for your feedback.
Between 1274 and the latest build there were no significant changes in the SSH implementation.
Thank you for your feedback.
Brandon Holland
This is just with 2 parts on a 16gb file.
mb
If you stop the transfer queue and wait for a minute, is the memory released?
Brandon Holland
If you stop the transfer queue and wait for a minute, is the memory released?
The memory leak persists after aborting the transfer.
Brandon Holland
Even with multi-parts disabled, I'm experiencing high memory usage. Slowly the memory increases by about 200 - 400 bytes every 10 seconds or so. After a few hours it reaches levels which I have to restart my computer to fix.
mb
Did you try it with different SFTP servers?
Brandon Holland
Did you try it with different SFTP servers?
Yes with a 30 gb file. Still same memory leak.
mb
We need exact instructions on how to reproduce the problem. Without them there is no chance we can possibly fix the problem.
Purgatory
mb,
I'll be testing later on my (rarely used) Win7 system with the original 4.1.1265.0 install, so any updated components (?) of SmartFTP would not have been added and it would have been a pure install.
If the same issue arises on the Win7 system with an original install of build 1265, then I would say that the hosting provider has updated the SFTP server and that would be the cause. ? I'll check with them to see if any updates/changes have been implemented recently in that area.
Again, smaller files no issues, all's normal with SmartFTP. Since I installed build 1265 on my XP system, the stability of SmartFTP is better, no crashing after X amount of SFTP multi-part/segmented downloading, but still high CPU and RAM use.
I'll give you my final report in the next 24hrs or so on the performance of the Win7 system with build 1265 (64-bit) and also if there have been any changes to the FTP/SSH/SFTP software at my host provider.
Thanks for your time on this.
I'll be testing later on my (rarely used) Win7 system with the original 4.1.1265.0 install, so any updated components (?) of SmartFTP would not have been added and it would have been a pure install.
- I uninstalled and deleted every reference to SmartFTP that was left behind on my XP system, unless there were other parts not referenced with SmartFTP, I should have been able to remove all traces. ?
- Installed version 4.1.1265.0 (32-bit) on the XP system, same issues after about 14GB now, not 6GB as before. The client does not crash any more but still runs high CPU to 40% or so and memory is scaled to 1.4GB. The client constantly drops connection and attempts to continue to download until the file is complete. The file finally completes with no errors, a hash check verifies that it is 100% identical.
If the same issue arises on the Win7 system with an original install of build 1265, then I would say that the hosting provider has updated the SFTP server and that would be the cause. ? I'll check with them to see if any updates/changes have been implemented recently in that area.
Again, smaller files no issues, all's normal with SmartFTP. Since I installed build 1265 on my XP system, the stability of SmartFTP is better, no crashing after X amount of SFTP multi-part/segmented downloading, but still high CPU and RAM use.
I'll give you my final report in the next 24hrs or so on the performance of the Win7 system with build 1265 (64-bit) and also if there have been any changes to the FTP/SSH/SFTP software at my host provider.
Thanks for your time on this.
mb
Did you do the same tests with the latest build as well?
Purgatory
Yes, tested with the latest build (1279) as well. See below tests results/input with different builds.
As a process of elimination, and for a super clean trial, using my HTPC computer (ASRock Vision 3D Sandy Bridge model):
First time install of 4.1 Build 1279 - Download a 14.1GB File:
Steady Working Set 56MB / Private Bytes 96MB / Peak Private Bytes 1.8GB (at the start, then back down to normal).
Win7 64-bit system. - No prior SmartFTP installs. All Win Updates.
========================
Maingear Potenza H77:
4.1 Build 1265 - Win7 64-bit - 16Gb File. No issues. - 6 Multi-Parts.
Steady as she goes for both systems with different builds. One fresh, first time install of SmartFTP client software. The other updated...
* Updated from Build 1265 to 1279 on the Potenza, after about 10mins, RAM had climbed to 265MB peak and steady at approx. 243MB. At 3hrs in and 10GB downloaded out of 25.1GB, single download (Not using Multi-Part/segmented), RAM was now at 856MB peak and steady at 809MB. No crashes or stalls with the connection up to that time.
(This is a more powerful system then my old XP based one (e.g. 8GB DDR3 1600 RAM, i7 3770, 2TB 7200RPM WD Caviar Black HDD). So I was not surprised that SmartFTP was holding steady after 3+hrs with no stalls or crashes as the RAM increased.)
After the final 5hrs of remaining download the results are: RAM peaked at: 1.894GB. No crashes. No dropped connections as with the XP system. Remember this was done with a single download over SSH, no Multi-Part. A hash check shows the 25.1GB file is 100% identical to the original source.
Final thoughts:
I was hoping this issue was isolated to my XP machine after having success with a first time install of 4.1 Build 1279 on the ASRock. To test this, I updated the Potenza to Build 1279 and started the biggest download I could find, over SFTP, single part as I was able to get MAX download without needing the Multi-Part function. Unfortunately, I'm convinced after doing my own tests, on my own systems, that there is an issue with files larger than 6Gb (the bigger the file and download time, the more the RAM is increased).
With the upgrade to Build 1279 from 1265 (where SmartFTP was perfect and issue free before), the best I can describe it mb, is there's bad code or other file interference somewhere. ?
Here's another test I did on the XP system several days ago(using 4.1 Build 1278):
Downloaded 52.47GB of data, 24 files of approx. 2.19Gb each. Zero issues on the XP system. No high RAM use nor high CPU usage. Each 2.19GB file was split into a Multi-Part of 6.
Other troubleshooting:
Host provider has done no major changes/updates to the FTP Server or FTP over SSH (SSHv2.0/Debian.)
See connection log below:
Firewall:
Thought it might be a Firewall issue after some research. I use COMODO Firewall, latest version as of Nov. 11th, previous version from March 2012. Disabled the FW. Restarted the XP system. Same issue with SmartFTP. So ruled out the Firewall.
*Only using Windows Firewall on both of the Win7 Systems tested above. The Potenza is not using any Anti Virus. The ASRock is using MSE for A/V.
I hope all the above makes sense and can be of some help with this issue.
Later,
As a process of elimination, and for a super clean trial, using my HTPC computer (ASRock Vision 3D Sandy Bridge model):
First time install of 4.1 Build 1279 - Download a 14.1GB File:
Steady Working Set 56MB / Private Bytes 96MB / Peak Private Bytes 1.8GB (at the start, then back down to normal).
Win7 64-bit system. - No prior SmartFTP installs. All Win Updates.
========================
Maingear Potenza H77:
4.1 Build 1265 - Win7 64-bit - 16Gb File. No issues. - 6 Multi-Parts.
Steady as she goes for both systems with different builds. One fresh, first time install of SmartFTP client software. The other updated...
* Updated from Build 1265 to 1279 on the Potenza, after about 10mins, RAM had climbed to 265MB peak and steady at approx. 243MB. At 3hrs in and 10GB downloaded out of 25.1GB, single download (Not using Multi-Part/segmented), RAM was now at 856MB peak and steady at 809MB. No crashes or stalls with the connection up to that time.
(This is a more powerful system then my old XP based one (e.g. 8GB DDR3 1600 RAM, i7 3770, 2TB 7200RPM WD Caviar Black HDD). So I was not surprised that SmartFTP was holding steady after 3+hrs with no stalls or crashes as the RAM increased.)
After the final 5hrs of remaining download the results are: RAM peaked at: 1.894GB. No crashes. No dropped connections as with the XP system. Remember this was done with a single download over SSH, no Multi-Part. A hash check shows the 25.1GB file is 100% identical to the original source.
Final thoughts:
I was hoping this issue was isolated to my XP machine after having success with a first time install of 4.1 Build 1279 on the ASRock. To test this, I updated the Potenza to Build 1279 and started the biggest download I could find, over SFTP, single part as I was able to get MAX download without needing the Multi-Part function. Unfortunately, I'm convinced after doing my own tests, on my own systems, that there is an issue with files larger than 6Gb (the bigger the file and download time, the more the RAM is increased).
With the upgrade to Build 1279 from 1265 (where SmartFTP was perfect and issue free before), the best I can describe it mb, is there's bad code or other file interference somewhere. ?
Here's another test I did on the XP system several days ago(using 4.1 Build 1278):
Downloaded 52.47GB of data, 24 files of approx. 2.19Gb each. Zero issues on the XP system. No high RAM use nor high CPU usage. Each 2.19GB file was split into a Multi-Part of 6.
Other troubleshooting:
Host provider has done no major changes/updates to the FTP Server or FTP over SSH (SSHv2.0/Debian.)
See connection log below:
Firewall:
Thought it might be a Firewall issue after some research. I use COMODO Firewall, latest version as of Nov. 11th, previous version from March 2012. Disabled the FW. Restarted the XP system. Same issue with SmartFTP. So ruled out the Firewall.
*Only using Windows Firewall on both of the Win7 Systems tested above. The Potenza is not using any Anti Virus. The ASRock is using MSE for A/V.
I hope all the above makes sense and can be of some help with this issue.
Later,
Purgatory
Forgot to add these screen shots from the XP system:
msvcr100-dll-High-CPU-spike-every-2mins:
High-CPU-Every-2mins:
msvcr100-dll-Closing-Re_opening-every-2mins:
msvcr100-dll-Versions_I-Have-Installed. - v10.00.40219.325 - Used by SmaftFTP:
msvcr100-dll-High-CPU-spike-every-2mins:
High-CPU-Every-2mins:
msvcr100-dll-Closing-Re_opening-every-2mins:
msvcr100-dll-Versions_I-Have-Installed. - v10.00.40219.325 - Used by SmaftFTP:
mb
Thank you. Can you send me the login/file information by email (support@) for the SFTP server? I will try to reproduce it here and if I can we will provide a fix within 24 hours.
Purgatory
Hey again mb.
Details emailed to you. The provider was kind enough to loan us a server for testing proposes, they're fans of SmartFTP with a great support team.
Anything else I can do to help, let me know.
Talk with you again soon.
Details emailed to you. The provider was kind enough to loan us a server for testing proposes, they're fans of SmartFTP with a great support team.
Anything else I can do to help, let me know.
Talk with you again soon.
mb
Good news: https://www.smartftp.com/download
Purgatory
\o/ Thank you mb. I'll give it a whirl later tonight.
Brandon Holland
Seems to be working perfectly! Thanks Purgatory and mb for all your help!
Purgatory
Good stuff YouBring.
The final tests for my Win7 and XP systems shows perfect performance from SmartFTP 4.1 Build 1282, zero issues.
mb, thank you very much for pinpointing the issue and for persevering with this report, even though you only had 2 people reporting the problem.
YouBringOnTheLulz, I thank you for spotting & reporting the issue first hand, and for insisting there was a problem.
The hosting provider is to be thanked as well for loaning a server for testing, I say thank you again.
Ok, I'll say unless someone other person has a similar issue, this report can be marked as resolved.
Thanks mb and YouBring, talk with you at another time.
The final tests for my Win7 and XP systems shows perfect performance from SmartFTP 4.1 Build 1282, zero issues.
mb, thank you very much for pinpointing the issue and for persevering with this report, even though you only had 2 people reporting the problem.
YouBringOnTheLulz, I thank you for spotting & reporting the issue first hand, and for insisting there was a problem.
The hosting provider is to be thanked as well for loaning a server for testing, I say thank you again.
Ok, I'll say unless someone other person has a similar issue, this report can be marked as resolved.
Thanks mb and YouBring, talk with you at another time.