2011/9/6 Alexander Lamaison <swish_at_lammy.co.uk>
> It works in as much as libssh2_sftp_read with a 6MB buffer no longer
> blocks on the first attempt. The first read is very quickly
> successful. However, subsequent reads are very slow. They cause 100%
> CPU usage and the teeny script, based on the standard example code
> with a 6MB buffer, uses 50-75 MB of memory.
>
100% CPU usage because of processing LIBSSH2_FX_EOF packet.
The buffer you offered is 6MB, sftp_read() will require a 24MB instead.
So, there is 24 * 1024 * 1024 / 2000=12583 request packets.
The actual data is 6MB, so the answer packets of data is 6 * 1024 * 1024 /
2000 = 3146
The left packets all LIBSSH2_FX_EOF, about 12583 - 3146 = 9437, actually it
is more than 9437,
in my test, it is 12558 upon the last call to sftp_read().
That occurs when libssh2_sftp_close(sftp_handle) is called.
Set libssh2_trace(session, 0xFFFF) before calling libssh2_sftp_close() you
will see that.
If the buffer is smaller, that also occurs,just not so serious.
I think sftp_read() maybe should not make 4 times of the buffer size.
That can be avoid by this:
1,sftp_read() does not make 4 times of the offered buffer.
2,caller know the file size, and the incoming buffer size is not bigger than
the real file size.
If you don't know the file size, the only way is to reduce the buffer size.
From watching the network meter, it seems that the 6MBs of data is
> transferred in a fraction of a second but that libssh2 spends the rest
> of the time reassembling it before returning from libssh2_sftp_read.
>
In my test, return from libssh2_sftp_read() is normal, calling
to libssh2_sftp_close() is blocked.
Alex
>
> _______________________________________________
> libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
>
_______________________________________________
libssh2-devel http://cool.haxx.se/cgi-bin/mailman/listinfo/libssh2-devel
Received on 2011-09-07