Автор Тема: Защо по дяволите моя диск се бави а диска на съседа чете като светкавица  (Прочетена 3070 пъти)

0 Потребители и 1 Гост преглежда(т) тази тема.    

Неактивен Diabolik

  • зарибен/а
  • зарибен/а
  • ****
  • Публикации: 116
  • Пол: Мъж
  • Black Panther
    • Профил
    • Даволският Блог
Хард диска като устройство е най-бавната част в един компютър, Движещите се части го правят най-бавната част, и независимо колко бързо ще работят движещите са части в хард диска, хард диска ВИНАГИ ще е по-бавен от шината процесора и паметта, заради движещите си части. Хард диска представлява алуминиема кутия с електромотор, който върти твърди алуминиеви дискове, с висока скорост, вече в наши дни (към дата та на писане на статията) дискове въртящи се на 7200 оборота са стандартни, дискове въртящи се на 10 000 са бързи, и електромагнитна намотка, която движи четящите глави. Едно от нещата които винаги ще бавят хард диска е латентността им – тоест времето когато главата е на нужната пътека и чака въртящият се диск, да “донесе” желаният сектор под главата за да бъде прочетен. Днес това време се измерва в милисекунди, и средното време на латентност на един хард диск на 7200 оборота е 4,2 милесекунди. Обикновено когато нещата се отнасят до скоростта на системата отнесена към скоростта на хард диска, обикновено системата си е свършила работата отдавна, и изчаква хард диска да запише подадените данни или да прочете поисканите, и целия компютър бездейства докато хард диска не си свърши работата. Най-лесният за хард диска случай е да има един голям дефрагментиран файл.  Тогава той си хваща едно равномерно темпо и си го поддържа, докато задачата свърши. Четенето на множество малки файлчета, е най-натоварващото нещо за един диск, защото постоянно трабва да търси, парчета от файлове, постоянно трябва да започва и спира четене, да чете малки порциики, от данни, да чака латентното му време между наместване на главата и четенето (главата първа се намества на правилната пътека преди сектора да е там, и главата чака сектора да “дойде”) и латентността на хард диска причинява огромни забавяния. Това също е огромен проблем за хард диска. Разбира се съвременните дискове, до накъде компенсират подобни неща, уиндоус ХР например също полага известни усилия в тази област, жалко че типично по микрософтски тези усилия са половинчати и водят до половинчата работа и половинчат резултат.

Фрагментирането е напълно естествен процес при работата на хард диска. За съжаление този процес е толкова вреден, колкото и естествен. Нека си представим че имаме програма,  състояща се от 10 файла – основният *.ехе файл, и още 9 длл файла които са и нужни на програмата. Всеки от тези файлове е разкъсан средно на 11 фрагмента, и всичките са пръснати произволно из целия хард диск.  Значи следва че хард диска трябва да направи 110 отделни процеса на достъп и четене (по един процес на достъп и четене за всеки фрагмент докато прочете всички фрагменти на всички файлове), за да прочете всичко което му е нужно. Това за хард диска е огромен проблем. Дайте да смятаме това във време, за типични показатели на един съвременен хард диск – колко време ще е необходимо на хард диска да изпълни дадената задача.

За всеки от 110-те фрагмента имаме следните времена:
време за достъп 8,9 милисекунди
латентност 4,2 милисекунди
време за намиране на пътеката 21 милисекунди
време за трансфер на вече прочетените данни до процесора или паметта 100 милисекунди.

Като съберем всичките стойности, това прави по 134,1 милисекунди на фрагмент
134,1 милисекунди на фрагмент, умножени по 110 фрагмента – 14 751 милисекунди – 14 секунди, 751 хилядни, нека го закръглим на 15 секунди за да прочете всичката информация и да я парти в паметта или на процесора.

Нека видим ако 10-те файла са дефрагментирани, и всеки файл е цял и не е разпокъсан, но 10-те файла са пръснати на произволни места из хард диска. Тогава имаме следните времена:

време за достъп 8,9 милисекунди
латентност 4,2 милисекунди
време за намиране на пътеката 21 милисекунди
време за трансфер на вече прочетените данни до процесора или паметта 100 милисекунди.
Като съберем всичките стойности, това прави по 134,1 милисекунди на файл
134,1 милисекунди на файл умножено по 10 файла, имаме резултат 1341 милисекунди (1,341 секунди) за прочитане на всичките 10 файла и пращането на информацията до процесора или паметта.

До тук с фрагментирането. Нека видим друг важен за производителността на хард диска показател – месоположение на файловете. В предният пример имахме10 дефрагментирани файлове, пръснати на произволни места из хард диска. Нека сега да приложим процес който се нарича File placement optimization – оптимизация на работата чрез пордеждане на файловете близо един до друг. Нека сега да видим какво се получава, когато тези 10 файла са едновременно дефрагментирани и подредени близо един до друг в съседни клъстери.

време за достъп 8,9 милисекунди
латентност 4,2 милисекунди
време за намиране на пътеката 21 милисекунди
време за трансфер на вече прочетените данни до процесора или паметта 100 милисекунди.

Като съберем всичките стойности, това прави 34,1 милисекунди за първия файл файл, и по 13,1 милисекунди за всеки от останалите 9 файла, това значи 117,9 милисекунди за да прочет всичките оставащи 9 файла, и всичките 10 файла ще бъдат прочетени за общо 152 милисекунди, и още 100 милисекунди за трансфер на данните до паметта или процесора – общо на хард диска ще му трябват 252 милисекунди за прочитане на всичките 10 файла, и пращането им до процесора или паметта. Вижте само големите разллики във времената:

14,751 секунди за случая с тоталната фрагментация

1,341 секунди за дефрагментираните файлове без да са подредени близо един до друг
0,252 секунди когато всичките файлове са дефрагментирани и подредени възможно най-плътно един до друг.

Тази разлика във времената е възможна защото в първият случай, четящата глава, прави 110 отделни операции по локализиране на парчетата и тяхното прочитане – главата работи интензивно а на хард диска му се извива свят от работа и му пушат ушите от натоварване.

Във вторият случай имаме само 10 операции по локализиране и четене. Диска е значително по-малко натоварен и резултатите са готови значително по-бързо.

В последният случай главите се наместват върху вярната пътека само веднъж, имаме само една процедура по търсене и локализиране, и след това само една процедура по четене, по времена която се прочитат 10 файла. След локализирането и наместването,  главите си стоят на едно място, без да мърдат и само четат това което минава под тях без да правят нищо друго – няма допълнителни дейсвния които да предизвикват допълнително забавяне или натоварване на диска.

Друга форма на File Placement Optimization може да се счита разпределянето на файловете по частите на хард диска. Хард диска, има бърза и бавна част, между тях логично е средно-бързата част. Първите 20% от дължината на радиуса, от към периферията се водят бързата част на диска, последните 25% от радиуса – тези откъм центъра се водят бавната часта на хард диска. Това е така защото при еднаква ъглова скорост (скорост на въртене), линейната скорост (пътят който диска изминава) се променя. Най-ниска е линейната скорост в цертърана диска и за единица време от там минават по-малко сектори.  Най-висока е линейната скорост по периферията, и от там минават най-много сектори за същата единица време съответно повече данни ще бъдат прочетени за същото време. Според модела на хард диска, и неговите показатели бързата част на хард диска е с между 180% и 240% по-бърза от бавната, което си е сериозна разлика. Разлика от около 180% може да се очаква когато моделът диск е ориентиран за скорост на достъп за сметка на обема – събира по-малко но да чете и пише по-бързо. Разлика от около 240% може да се очаква дискове които са оптимизирани да поберат максимален обем, при определени показатели на работа.

Говорейки за тези 180% до 240% разлика между бавната и бързата част, тук е времето да спомена че тези проценти всъщност значат, колко информация, ще бъде прочетена за единица време от бързата част е от 180% до 240% повече, от тази която ще се прочете от бавната част за същата единиаца време.

Добрите дефрагментатори като UltimateDefrag и Perfect Disk правят така че бързата част на диска да се изпразни, след това в бързата част на диска, да запишат често използваните файлове, дефрагментирани и събрани плътно един до друг, за за да може както са дефрагментирани и пълтно наредени един до друг, хард диска да губи минимално време, и да прочете максимално количество информация за единица време, следвайки логиката че щом постоянно ползватетези файлове, те трябва да са подредени така че четенето им да взема минимално време, и да са винаги готови да се отворят веднага при поискване. По същата логика файловете които се ползват рядко се концентрират в бавната част на диска. Да ще се отварят по-бавно от често използваните, но по тази логика, няма особено значение, че ще чакате половин секунда повече, нали и без това ползвате файл рядко, и защо да заема място в бързата част, и друг файл който ползвате често да не може да се възползва от бързата част на диска, и да трябва често да чакате повече докато често използван файл се зареди?

Автор: Кристиян Алекснадров