Midnight Commander on 11.31 works slow

[Maxim Yakimenko]

Hi, collegues

Of course, I understand that mc is not standard HP tool to manage files. But may be someone met this issue already. On 11.31 (release March 2011) mc copies files very slowly. I've checked to see system calls in order to compare operation of standard "cp" and mc on previous installations. I've noticed that cp does just "read" and "write" using blocks 1 Mb in size. mc copies files using 8Kb blocks, also it does some extra-syscalls for every block:

(0.000016) read(5,.......
(0.000009) gettimeofday(.......
(0.000009) gettimeofday(.......
(0.000032) write(6,.......
(0.019510) select(5,.......


and after "write" goes "select" on file that is read

On previous installation this select lasts for
about 0.000009 sec, and on this release it takes about 0.02 sec - many orders bigger! And I consider it to be the core reason of slowdown.

So, may be someone can point me direction where I could dig to solve this issue?

[Maxim Yakimenko]

Now I noticed that this situation appeared after I patched system that was initially release Sep2010 with standard patch bundles Mar2011. May be I need some extra-patches?

[Steven Schweda]

> (0.000032) write(6,.......
> (0.019510) select(5,.......
>
>
> and after "write" goes "select" on file that is read
>
> On previous installation this select lasts for
> about 0.000009 sec, and on this release it
> takes about 0.02 sec - many orders bigger!
> And I consider it to be the core reason of
> slowdown.

I know nothing, but is there some difference
in the storage between these two situations?
For example: Fast with local disk, but slow
with NFS-remote disk? Or: Fast with local
(SCSI) disk, but slow with FC NAS storage?

[Maxim Yakimenko]

I've found the clog: In FEATURE Mar2011 comes patch PHKL_41700 - 11.31 fs_select cumulative patch


Defect Description:
PHKL_41700:
( QX:QXCR1001078659 )
When select(2) is used either as a timer or used for
actually selecting the file descriptors for I/O or error
condition, it is not making use of the high resolution timer
functionality already provided by the timer subsystem.
Because of this small timeouts will experience a larger wait
time.

Resolution:
select(2) code has been modified to use the high resolution
timer functionality. However, the new functionality depends
on the value of tunable "hires_timeout_enable". With the
enablement of the tunable "hires_timeout_enable", along with
this patch, applications that use select(2) and specify
small timeouts will timeout right after the specified
duration and this will reduce the long wait time when
compared prior to the installation of this patch.


but it is "most recent", and "recomended" is 38700.

This time I get back to 38700, now I should recon - is mc is wrong or some burden with patches, any way I managed to know some more about this problem

[Milan Novak · Accepted solution]

Set the kernel parameter hires_timeout_enable to 1 (default value is 0):
# kctune hires_timeout_enable=1

see the following link for more
http://www13.itrc.hp.com/service/james/dispDoc.do?docURL=%2Fservice%2Fcki%2FdocDisplay.do%3FdocLocale%3Den%26docId%3Demr_na-c02771807&aid=SEARCH_CKI&pil=5&serStr=hires_timeout_enable

[Maxim Yakimenko]

Milan, thanks

Yes, I've already found this parameter, but another application (the main application on this host) works fine. It contains both TCP-IP server and TCP-IP client parts. I aware of that case, when I change set parameter and this app will go wrong. Or, I can determine by testing?

[Milan Novak]

I understand your caution. Since this tunable is dynamic, you can easily test it. Just switch it for a while, watch the performance of your other application...

Milan

[Maxim Yakimenko]

Collegues, thanks a lot to you all

[Maxim Yakimenko]

Solved