Linux CPU process spikes to MAX

Here you can submit your bug reports.
Post Reply
eordona
Posts: 55
Joined: Fri Aug 24, 2012 5:42 pm

Linux CPU process spikes to MAX

Post by eordona »

I think I may have found a bug, but I would like your assistance in diagnosing.

Frequently my server process "wftpserver" will spike to MAX -- 100% or at minimum high 90s (basically as much CPU as it can get).

Digging into why -- it appears this may be tied to some type of timeout error (handle_timeout close the session) with the SSH process. See below, I have dashed out the non-relevant private information:

[02] Mon, 07 Dec 2015 05:03:39 (0000095) Connected from ---------------- (local address ----------------, port 22)
[01] Mon, 07 Dec 2015 05:03:39 (0000095) SSH session receive user name:----------------
[01] Mon, 07 Dec 2015 05:03:39 (0000095) SSH session receive password of user ----------------
[01] Mon, 07 Dec 2015 05:03:39 (0000095) User/password authentication OK.
[01] Mon, 07 Dec 2015 05:03:40 (0000095) SSH authentication completed successfully. Client information:SSH-2.0-edtFTPnet/PRO-8.6.0.20
[01] Mon, 07 Dec 2015 05:03:40 (0000095) The user ---------------- logged in successfully via SSH.
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_INIT: client SSH version 3
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_VERSION: server SSH version 3
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_REALPATH: path .
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_NAME: path .
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_REALPATH: path /\
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_NAME: path /\
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_OPENDIR: directory /
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_HANDLE: path /
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_STAT: path: /.
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_ATTRS: Filesize: 12288, UserID: 0, GroupID: 0, Permissions: 16877, Last modify time:1449479702.
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_CLOSE: path /
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_STATUS: / has been closed.
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_STAT: path: /----------------_20151207050131974.csv.
[07] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_OPEN: path /----------------_20151207050131974.csv
[07] Mon, 07 Dec 2015 05:03:40 (0000095) Transfer starting for /----------------_20151207050131974.csv
[08] Mon, 07 Dec 2015 05:03:40 (0000095) SSH_FXP_HANDLE: /----------------_20151207050131974.csv has been opened.
[05] Mon, 07 Dec 2015 05:05:21 (0000088) Keep alive
[01] Mon, 07 Dec 2015 05:08:49 (0000095) handle_timeout close the session
[02] Mon, 07 Dec 2015 05:08:49 (0000095) Closed session,disconnected from 168.75.171.244
[05] Mon, 07 Dec 2015 05:10:21 (0000088) Keep alive
[05] Mon, 07 Dec 2015 05:15:21 (0000088) Keep alive

I am running CentOS 6.7, fully patched.

The example is from an hourly file which is placed on our server. The majority of the time this happens without issue. Then, occasionally one of the transfers goes wrong, and the CPU spikes PERMANENTLY until I log into the server command line and restart the server. (/etc/init.d/wftpserver stop, then /etc/init.d/wftpserver start).

When the CPU spikes, the wftpserver still works, it just something behind the scenes is making the CPU spike out of control, which trips other monitoring alerts that we have set up, etcetera.

Is there anything else I can provide to you on this??

Thanks...
FTP
Site Admin
Posts: 2072
Joined: Tue Sep 29, 2009 6:09 am

Re: Linux CPU process spikes to MAX

Post by FTP »

Please upgrade to the latest version, we have made some improvement about SFTP in the recent version.
eordona
Posts: 55
Joined: Fri Aug 24, 2012 5:42 pm

Re: Linux CPU process spikes to MAX

Post by eordona »

I have updated to the latest 4.6.2 but this is still happening. Any other suggestions or information I can give you?
eordona
Posts: 55
Joined: Fri Aug 24, 2012 5:42 pm

Re: Linux CPU process spikes to MAX

Post by eordona »

I think this perhaps has calmed down -- I don't recall this happening in the past week or so on our server. I'll continue to watch this and let you know if it occurs again.
Post Reply