[mirror-admin] where are all the indices of the repository?

[Paulo Licio de Geus]

On 12 Jul 2009, at 11:58, J.H. wrote:

>> Having "idle" (-c3) time means, I believe, when you have utilization
>> below 100% (sar -d -p 3 should give a pretty good idea of the duty  
>> cycle
>> on the disks). So if the primary service is "serving clients", then
>> updating the mirror contents is not the main priority and could be  
>> run
>> "off-line". We have all discussed ways of making sure the contents is
>> never incoherent, despite the timing implied by each activity, so it
>> doesn't matter if the update takes one hour or one and a half hours.
>> Now, how good the I/O scheduling algorithm is implemented in the  
>> Linux
>> kernel is a differente story altogether, but I've played I little  
>> on my
>> personal machine and my impression is that it mostly works. Why not  
>> give
>> it a try on a server?
>
> Really, my argument here isn't that idle there is an issue, it's  
> that my disks are *CONSTANTLY* getting hammered, there really isn't  
> much of anything I can do about this that would be sane.  Your  
> suggesting that an update like that might take an hour or two (when  
> set to idle like that) would be fine, but my disk is never idle like  
> that, in fact it's *SLOW* right now with some of my machines with  
> loads of 5 - 10, all of which is stalled on disk i/o.  During a  
> Fedora release (for instance) loads have been seen to be well over  
> 100 (I think the most I've personally seen lately is in the 500-600  
> in the last year or two) all of which is disk i/o bound, not cpu or  
> memory.
>

Observing load is just an indirect way of infering that processes are  
on I/O wait. I think you could collect statistics on a few seconds  
basis and correlate them, just to learn what corresponds to what. Even  
if your disks are constantly hammering, there might be some I/O time  
left. Look at the disk utilization column and you will be sure,  
assuming that computing these statistics are correctly implemented, as  
much as possible. My completely non-systematic, manual monitoring  
tells me the implementation on linux is pretty good. When disks are  
flat out on use, the numbers I observe stay at the expected 100% mark,  
+- a few percent. Sar and/or the corresponding iostat column on later  
versions can also show if a given disk is more heavily demanded than  
others (raid, lvm not withstanding).

--
Paulo Licio de Geus		    Internet: paulo at las.ic.unicamp.br
Instituto de Computação - UNICAMP   Av. Albert Einstein, 1251
caixa postal: 6176		    fax: +55 19 3521-5847 (nada útil...)
13083-852  Campinas SP Brazil       http://www.las.ic.unicamp.br/paulo
cell: +1 (805) 901-1280 (Ventura CA USA)    skype: paulo.licio.de.geus
ICQ: 296462565 	GTalk: paulo.de.geus at gmail.com  MSN: paulo at ic.unicamp.br
fuso horário atual: GMT-7 (-4h SP)




--