Re: troubleshooting I/O performance bottleneck

[manu%netbsd.org@localhost (Emmanuel Dreyfus)]

Manuel Bouyer <bouyer%antioche.eu.org@localhost> wrote:
> the same output while running dd in the dom0 could help.

Here it is:

Proc:r  d  s  w     Csw    Trp    Sys   Int   Sof  Flt  PAGING  SWAPPING
           7       2538    232    548  1401   364    9  in  out  in  out
                                                        ops
   2.0% Sy   0.0% Us   0.0% Ni  11.0% In  87.0% Id    pages
|    |    |    |    |    |    |    |    |    |    |
=%%%%%%                                                            forks
                                                                   fkppw
           memory totals (in kB)         1221 Interrupts           fksvm
          real  virtual     free          100 vcpu0 softclock      pwait
Active   32264    32264   142444           25 vcpu0 softnet        relck
All     104944   104944  8142436          111 vcpu0 xenevt         rlkok
                                              vcpu0 xencons        noram
Namei         Sys-cache     Proc-cache     26 ioapic1 pin 0        ndcpy
    Calls     hits    %     hits     %        ioapic0 pin 16       fltcp
        6        6  100                   809 ioapic0 pin 19       zfod
                                              vcpu0 ioapic0        cow
Disks:   md0   cd0   wd0   wd1 raid0      150 vcpu0 clock       64 fmin
 seeks                                        vcpu0 xenbus      85 ftarg
 xfers               417   429   423          vcpu0 xbd3.3         itarg
 bytes               13M   13M   13M          vcpu0 xvif3.0   3851 wired
 %busy              89.0  58.0  98.0          vcpu0 xbd13.3        pdfre
~

> Could it be a RAM size issue (the dd output fits in ram in dom0 but not
> in domU) or different mount options ?

Both dom0 and domU have softdep and FFS. dom0 has 256 MB, domU has 64MB.
I tried raising it to 192 MB, and while my dd test does not improve,
responsiveness of the system is better. Perhaps that was another
problem.

> It could also come from partition layouts; modern disks are known to be faster
> when writting at the beggining of the drive than at the end.

That would explain a 200% hit?

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu%netbsd.org@localhost