Resolved Huge memory usage of proftpd

[tkalfaoglu]

Today the 64GB server became a crawler because proftpd process was using close
to 30GB of RAM by itself.
It is a default PLESK Onyx installation and proftpd configuration is either default or is very close to it..

psa-proftpd-1.3.6-11.el7.art.x86_64
..is the loaded code.

The system is running kernel 3.10.0-957.10.1.el7.x86_64 CentOS Linux release
7.6.1810

There was 1 FTP user at the time, using two connections to upload many small
files to the server.

Any ideas why proftpd would be so lavish with memory and how to prevent it being greedy in the future?

 

[Monty]

You seem to be running the Atomic Repo version of the psa-proftpd package.

On our system here (CentOS 7 6.1810, Plesk 17.8, fully patched) I see package version:
psa-proftpd-1.3.6-cos7.build1708180220.17.x86_64

No problems with that version here.

So maybe you can try to replace your atomic package with the plesk package?

 

[tkalfaoglu]

Many thanks.. here is what happened when I tried to uninstall proftpd and install the other package instead:
LOL


# yum remove psa-proftpd psa-proftpd-xinetd
Resolving Dependencies
--> Running transaction check
---> Package psa-proftpd.x86_64 0:1.3.6-11.el7.art will be erased
--> Processing Dependency: psa-proftpd >= 1.3.4d for package: plesk-web-hosting-17.8.11-cos7.build1708180301.19.x86_64
--> Processing Dependency: psa-proftpd >= 1.3.4d for package: plesk-web-hosting-17.8.11-cos7.build1708180301.19.x86_64
---> Package psa-proftpd-xinetd.x86_64 0:1.3.6-11.el7.art will be erased
--> Running transaction check
---> Package plesk-web-hosting.x86_64 0:17.8.11-cos7.build1708180301.19 will be erased
--> Processing Dependency: plesk-web-hosting >= 17.8.11 for package: psa-horde-5.2.17-cos7.build1708180425.15.noarch
--> Processing Dependency: plesk-web-hosting >= 17.8.11 for package: plesk-roundcube-1.3.6-cos7.build1708180427.13.noarch
--> Running transaction check
---> Package plesk-roundcube.noarch 0:1.3.6-cos7.build1708180427.13 will be erased
---> Package psa-horde.noarch 0:5.2.17-cos7.build1708180425.15 will be erased
--> Processing Dependency: psa-horde >= 5.1.6 for package: psa-ingo-3.2.16-cos7.build1708180425.15.noarch
--> Processing Dependency: psa-horde >= 5.1.6 for package: psa-turba-4.2.21-cos7.build1708180425.15.noarch
--> Processing Dependency: psa-horde >= 5.1.4 for package: psa-passwd-5.0.7-cos7.build1708180425.15.noarch
--> Processing Dependency: psa-horde >= 5.1.6 for package: psa-mnemo-4.2.14-cos7.build1708180425.15.noarch
--> Processing Dependency: psa-horde >= 5.1.6 for package: psa-kronolith-4.2.23-cos7.build1708180425.15.noarch
--> Processing Dependency: psa-horde >= 5.1.6 for package: psa-imp-6.2.21.1-cos7.build1708180425.15.noarch
--> Running transaction check
---> Package psa-imp.noarch 0:6.2.21.1-cos7.build1708180425.15 will be erased
---> Package psa-ingo.noarch 0:3.2.16-cos7.build1708180425.15 will be erased
---> Package psa-kronolith.noarch 0:4.2.23-cos7.build1708180425.15 will be erased
---> Package psa-mnemo.noarch 0:4.2.14-cos7.build1708180425.15 will be erased
---> Package psa-passwd.noarch 0:5.0.7-cos7.build1708180425.15 will be erased
---> Package psa-turba.noarch 0:4.2.21-cos7.build1708180425.15 will be erased
^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C^C

 

[Monty]

Yeah it's not easy to uninstall psa-proftpd from Atomic, as it has dependencies on all other Plesk packages.
I don't have a ready-to-use solution for you but you could do something like this:

(Please note: Do NOT do this on your production system! Test it on a lab system first. I take no responsabilities in case of a SNAFU)

rpm -e --nodeps psa-proftpd psa-proftpd-xinetd
rpm -Uhv http://autoinstall.plesk.com/PSA_17.8.11/dist-rpm-CentOS-7-x86_64/opt/hosting/proftpd/psa-proftpd-1.3.6-cos7.build1708180220.17.x86_64.rpm

This will remove the psa-proftpd and psa-proftpd-xinetd packages from your system without removing the dependencies. And then it will install the original Plesk psa-proftpd package.

Please be aware that I did not test this, so it's just a wild guess.

 

[tkalfaoglu]

Worked like a charm -- you only have autoinstall keyword listed twice in the hostname.. Many thanks.. I'm a bone fide plesk user now..

 

[Monty]

Worked like a charm -- you only have autoinstall keyword listed twice in the hostname.. Many thanks.. I'm a bone fide plesk user now..

Thanks, corrected the autoinstall typo.

Please report if the memory leak issue has been fixed by this, it can be helpful for other users with the same issue.

 

[trialotto]

@tkalfaoglu (and @Monty)

in response to original problem and/or the question

Any ideas why proftpd would be so lavish with memory and how to prevent it being greedy in the future?

one should also consider to place

RLimitMemory [scope] [limit]

in the server config, virtual host or global context(s).

Note that scope is "daemon", "session" and "none".

Nevertheless, you should investigate what is causing the issue in the scenario in which only one (1) user is uploading multiple small files : it can be proftpd inherent (read: in most cases, this is related to directory listing processes), but it can also be something more severe.

I would recommend to use PASSIVE PORTS - this would probably reduce the "proftpd overload" and "memory leak" to some extent.

Hope the above helps a bit.

Regards........

 

[tkalfaoglu]

I read somewhere that there was a proftpd bug regarding SSL/TLS.. Perhaps that's causing this.
I tried the Limit, but it doesn't help..

 

[trialotto]

I read somewhere that there was a proftpd bug regarding SSL/TLS.. Perhaps that's causing this.
I tried the Limit, but it doesn't help..

@tkalfaoglu

It is probably not about SSL/TLS - we can safely assume that the many requests to proftpd will cause a memory leakage : the first post is quite clear, in the sense that one ftp user only uses two connections for uploading many small files.

In essence, that is "wrong" from every perspective :

- uploads should be allowed to take more than two connections simultaneously, to allow for bursts in ftp related traffic,
- a huge number of small files should not be allowed, but should be zipped/archived and uploaded as a whole.

Your current "memory leak" is more or less the same as "globbing" : each of the two connections causes a huge list of (small) files and directores, which will reside in memory.

In short, just (in chronological order)

- stop all ftp processes related to the two connections, (and)
- limit the number of connections AND
- limit the maximum memory assigned to proftpd (note: this has to be assigned carefully, it can cause problems when using a too low value)

and note that you do not have to restart proftpd : it is all about changing config in a proper fashion (read: the config changes will be active immediately).

In addition, talk to your customer or ftp user : just ask him kindly to use a PROPER ftp client that allows multiple simultaneous connections (read: proftpd can handle a huge number of connections and/or transfers of many small or large files...... in most cases, the ftp client is the bottleneck, not the proftpd server - to be more clear, the ftp client is mostly causing an issue on the ftp server side, but that is not the equivalent of a problem caused by the ftp server, being proftpd in this case).

Regards.........

 

[tkalfaoglu]

Ok how do I do the same thing with the Obsidian? Same thing happened