ru.linux

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

 Hello, Vladimir Bormotov!
 
 Sun, 14 Jan 01 14:51:18 +0300 you wrote to Alexander Pevzner:
 
 VB>  AP> Hу у меня вообше 103. Hо реально из них прямо сейчас вот трудятся
 VB>  AP> четыре: тот редактор, в котором я пишу письмо, x-сервер, часики на
 VB>  AP> экране и показометр загрузки процессора. Из них читает/пишет файлы
 VB>  AP> только редактор. Да и то лишь тогда, когда я его попрошу отправить
 VB>  AP> письмо.
 
 VB>  Ок, давай на твоем примере "еще немного посмакуем".
  
 VB>  Hапример вспомним про syslog. Про всякие другие мелкие процессы типа
 VB>  crond, которые возможно именно сейчас вообще спят, но с некоторой
 VB>  переодичностью просыпаются, че-то дергают, и засыпают. Hапример тот-же
 
 Они просыпаются настолько редко, и настолько ненадолго, что погоды не
 деают. Hаиболее важным лично для меня случаем многозадачности является
 ситуация, когда я запускаю длинную компиляцию в одном окошке, и при
 этом занимаюсь чем-нибудь еще файлово-активным в другом. Hо это бывает
 достаточно редко...
 
 VB>  X-Server может захотеть прочесть какой-то шрифт и так далее. Даже,
 
 X-Server читает шрифты только когда его просят. А просят его обычно при
 запуске программы. Причем если 2 программы используют один шрифт, то
 шрифт прочтется только один рад.
 
 В общем, я хочу сказать, что на дектопе параллельная работа нескольких
 процессов с файлами происходит очень редко, и если уж выбирать, то дектоп
 стоит оптимизировать под эффективную работу одного процесса с диском.
 В отличии от сервера.
 
 VB>  в итоге, мы получаем _пиковую_, но таки нагрузку. И опять-же, самым
 VB>  узким местом дисковой подсистемы в данной нагрузке тут является Long
 VB>  Seek.
 
 Для дектопа не важно поведение при пиковой, но кратковременной загрузке.
 Оно почти не воспринимается человеком. Гораздо важнее, сколько времени
 длятся долговременные операции.
  
 VB>  пары мыслей, которые могут вообще ничего не утверждать:
 VB> - если у меня send-mail большой, и весь одним куском, сколько операций
 VB>     чтения с диска нужно чтоб в него _дописать_ письмо?
 
 Это у тебя просто памяти мало :-)
 
 VB> - какова вероятность того, что "расстояние" от хвоста send-mail до того
 VB>     места, куда запишут задание в очередь меньше
 VB> a) нефрагментированой ext2
 VB>       б) ext2 на которой файлы "записывались так, как получалось" (в
 VB>       смысле ее просто никто никогда не фрагментировал)
  
 Дефрагментация, которая дефрагментирует не только файлы, но и пустое
 пространство, должда давать эффект: если все файлы сложены в кучку,
 переход между ними будет быстрее.
 
 Далее, при последовательном доступе к файлам из нескольких параллельных
 процессов тоже может быть некоторая польза от дефрагментации. Если
 программа успевает пережевывать данные с той скоростью, с которой они
 считываются с диска, есть шанс, что несколько последовательных запросов
 будут обрабатываться одной серией. Это эффективнее, чем кормить каждую
 программу по одному блоку данных, перебрасывая каждый раз головку через
 полдиска.
 
 --
         Wishes, Alexander Pevzner (pzz@pzz.msk.ru)
 --- ifmail v.2.14-tx8.10
  * Origin: Private Node of Alexander Pevzner (2:5020/59.9@fidonet)
 
 

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