Re: Performance degradation with ISAM tables

["Senén de Diego" <senen-qHrp9QoZuCS1Z/+hSey0Gg@public.gmane.org>]

El 14/12/2012 3:39, Jeff Layton escribió:
> On Thu, 13 Dec 2012 23:53:00 +0100
> Senén de Diego <senen-qHrp9QoZuCS1Z/+hSey0Gg@public.gmane.org> wrote:
>> Hello,
>> I'm executing, in a linux server, a program that reads data from dbf
>> files in a windows share. I've tried to execute the same program in an
>> upgraded server and I've found that it runs much much much slower.
>> These are the versions of the first (older) server:
>> kernel: 2.6.37.6-24
>> cifs.ko: 1.68
>> and of the second (newer):
>> kernel: 3.4.11-2.16
>> cifs.ko: 1.78
>> The windows machine runs windows 2000 server and has EnableOplocks
>> disabled in the LanManServer service.
>> The windows share is mounted as a cifs file system with some differences
>> in the parameters assigned by default:
>> first server: rsize=16384,wsize=57344
>> second server: sec=ntlm,nounix,rsize=61440,wsize=65536
>> I've captured the network traffic in both servers, and these are the
>> service response time statistics:
>> First server:
>> =================================================================
>> SMB SRT Statistics:
>> Filter:
>> Commands Calls Min SRT Max SRT Avg SRT
>> Close 37 0.000140 0.001635 0.000404
>> Read AndX 11554 0.000196 0.017179 0.002099
>> Write AndX 12 0.000255 0.000657 0.000510
>> NT Create AndX 43 0.000190 0.000406 0.000237
>> Transaction2 Commands Calls Min SRT Max SRT Avg SRT
>> FIND_FIRST2 83 0.000747 0.001953 0.001735
>> FIND_NEXT2 880 0.000486 0.002885 0.001711
>> QUERY_PATH_INFO 25678 0.000170 0.005451 0.000250
>> QUERY_FILE_INFO 67 0.000169 0.000206 0.000182
>> NT Transaction Commands Calls Min SRT Max SRT Avg SRT
>> =================================================================
>> Second server:
>> =================================================================
>> SMB SRT Statistics:
>> Filter:
>> Commands Calls Min SRT Max SRT Avg SRT
>> Close 118 0.000128 0.006194 0.000517
>> Trans 1 0.000872 0.000872 0.000872
>> Read AndX 3490 0.000260 0.019713 0.009729
>> Write AndX 12 0.000508 0.000522 0.000515
>> NT Create AndX 118 0.000253 0.001496 0.000342
>> Transaction2 Commands Calls Min SRT Max SRT Avg SRT
>> FIND_FIRST2 171 0.000761 0.002862 0.002404
>> FIND_NEXT2 326 0.002342 0.003058 0.002429
>> QUERY_PATH_INFO 318093 0.000168 0.041616 0.000320
>> QUERY_FILE_INFO 137 0.000235 0.002855 0.000370
>> NT Transaction Commands Calls Min SRT Max SRT Avg SRT
>> =================================================================
>> where there is a great difference in the number of calls, specially in
>> the number of QUERY_PATH_INFO commands executed. And the average SRT are
>> also slower in the newer server.
>> I would like to know what is the cause and what can I do to correct this?
> The difference between those two kernel represents more than a year of
> development time. The best first step you can take is to try a more
> recent kernel (like something 3.7-ish) to see if that might help.
I've tried with a 3.6.10 kernel (the last available in my distro) and 
it's still slow:

=================================================================
SMB SRT Statistics:
Filter:
Commands                   Calls    Min SRT    Max SRT    Avg SRT
Close                        116   0.000137   1.101347   0.009745
Trans                          3   0.000517   0.000722   0.000642
Echo                           1   0.000203   0.000203   0.000203
Read AndX                 122893   0.000206   0.154745   0.000599
Write AndX                    12   0.000253   0.005756   0.000789
NT Create AndX               118   0.000266   0.000865   0.000458

Transaction2 Commands      Calls    Min SRT    Max SRT    Avg SRT
FIND_FIRST2                  170   0.000843   0.003413   0.002590
FIND_NEXT2                   325   0.002373   0.006695   0.002908
QUERY_PATH_INFO           320423   0.000181   2.066630   0.000485
QUERY_FILE_INFO              135   0.000252   0.000768   0.000395

NT Transaction Commands    Calls    Min SRT    Max SRT    Avg SRT
=================================================================



> The next problem is that it's difficult for us to infer anything about
> your workload. You'll probably need to do some investigative work to
> figure out what's actually slow. In particular, if you can phrase the
> problem in terms of particular syscalls being slower, then we might be
> able to help you more.
> Even better is to come up with a small reproducer program that
> demonstrates the slowdown.
The file access is done by a proprietary jdbc driver inside a jvm. I really don't know how to do what you suggest. The SMB service response time statitics are all I've got.