ru.linux

 
 - RU.LINUX ---------------------------------------------------------------------
 From : Vladimir Bormotov                    2:5020/400     14 Jan 2001  15:51:18
 To : Alexander Pevzner
 Subject : Re: Проги для дефрагментации   ?
 -------------------------------------------------------------------------------- 
 

 
    Hi, Alexander!
 
 >>>>> "AP" == Alexander Pevzner <pzz@pzz.msk.ru> writes:
 
 VB>> v>> Если пока ты читаешь свой файл, пятьдесят других процессов
 VB>> v>> обращаются к 50 другим файлам, то тебя дефрагментация не спасет.
 
 [skip]
 
 VB>>  что вообще можно выиграть? - Правильно, сократить количесво операций
 VB>>  long seek. Эх, сколько можно смаковать эту тему...
 
  AP> Hу у меня вообше 103. Hо реально из них прямо сейчас вот трудятся
  AP> четыре: тот редактор, в котором я пишу письмо, x-сервер, часики на
  AP> экране и показометр загрузки процессора. Из них читает/пишет файлы
  AP> только редактор. Да и то лишь тогда, когда я его попрошу отправить
  AP> письмо.
 
  Ок, давай на твоем примере "еще немного посмакуем".
  
  Hапример вспомним про syslog. Про всякие другие мелкие процессы типа crond,
  которые возможно именно сейчас вообще спят, но с некоторой переодичностью
  просыпаются, че-то дергают, и засыпают. Hапример тот-же X-Server может
  захотеть прочесть какой-то шрифт и так далее. Даже, когда ты именно
  отправляешь письмо, ведь читается совсем не один файл, так ведь?
  А многие из этих "не один файл" вполне вероятно лежат
  1. читаются паралельно, т.е. запускается несколько процессов, которые
     просто где-то ждут друг друга
  2. могут вообще лещать на разных разделах, например письмо там пишется мне 
     в /home/bor/mail/send-mail и в /var/spol/mail/queue
  
  в итоге, мы получаем _пиковую_, но таки нагрузку. И опять-же, самым узким
  местом дисковой подсистемы в данной нагрузке тут является Long Seek.
  
  пары мыслей, которые могут вообще ничего не утверждать:
   - если у меня send-mail большой, и весь одним куском, сколько операций
     чтения с диска нужно чтоб в него _дописать_ письмо?
   - какова вероятность того, что "расстояние" от хвоста send-mail до того
     места, куда запишут задание в очередь меньше 
       a) нефрагментированой ext2
       б) ext2 на которой файлы "записывались так, как получалось" (в смысле
       ее просто никто никогда не фрагментировал)
  
  И самое инетесное другое - HАСКОЛЬКО эфективнее таки "нефрагментированая
  fs" в твоем случае (редкая пиковая на диск нагрузка на десктопе), и как
  это подсчитать не погружаясь глубоко в знания устройства ext2 и теорию
  вероятности. А далее инетеесно посмотреть окупятся ли "затраты на
  принудительную дефрагментацию", или того оптимизатора записи на диск,
  который реализован вполне хватает.
  
  Да! Мы совсем абыли про дисковый кешь, который работает незвзирая на, и
  еще сильнее снижает нагрузку, причем в обоих случаях. :))))
  
 -- 
    Bor.
 --- ifmail v.2.15dev5
  * Origin: BorHomeLand (2:5020/400)
 
 

Вернуться к списку тем, сортированных по: возрастание даты  уменьшение даты  тема  автор