« previous entry | next entry »
Maijs. 2., 2006 | 09:48 am
posted by: mikii in pajautaa

..jautājums datoriķiem - kas varētu būt par iemeslu, ka jebkura lielāka faila kopēšana no hdd rada nenormālu sistēmas bremzi. sākumā domāju, ka procesora noslodze, bet tā ir zem 20%-40%, ko nevarētu dēvēt par lielu. varbūt swap fails ir par lielu (1.5gb ierobežojum min un max) un šams visu mēģina caur to lādēt, lai gan task manager izskatās, ka ram'a pietiek. varbūt kāds zin paskaidrot, kāpēc tas tā un vai var ko darīt lietas labā? jau iepriekš pateicos par atbildēm.

# | jā, ir doma! | Add to Memories

Comments {26}

from: [info]mikii
date: Maijs. 2., 2006 - 01:06 pm
#

Dīvaini ir tas, ka pie vilkšans nekas nebremzē (nu vismaz ne kaitinoši), jo ātrums ir piegriezts līdz <1MBs. bremze ir veicot hash check, ti, kad client programma salīdzina novilkot failu ar hash.
par diska parametriem īsti nezinu (var jau noskaidrot), taču vajadzētu būt 7200rpm. būs jāpamēģina triks ar antivīrusu, jo tā iejaukšanās tik tiešām var palēnināt procesu (lai gan tad vajadzētu būt arī procesora noslodzei)..

Atbildēt | Iepriekšējais | Diskusija

from: [info]laumina
date: Maijs. 2., 2006 - 01:16 pm
#

Nu kaa..
Nedomaaju , ka algoritms peec kura tas softs reikjina kontrolsumu ir tik vaajpraatiigi sarezhgjiits ka speetu noslogot 2GHz CPU.
Taapeec tas ir diezgan loogjiski ka heshojot CPU nav paaraak noslogots.
Toties tas fails ir jaanolasa pa fragmentiem un tas noslogo disku.
Normaalaa gadijumaa heshoshana notiek ar kaadiem 30MB/sec
laikam... cik es atceros :>

Diska noslodzi var apskatiit ar XP iebuuveeto tuuli - Administrative Tools - Performance

Tur varam uzlikt lai paraada pieprasijumu rindu uz HDD..
Nju i tad veerojam.. un meigjinam izprast :)

Atbildēt | Iepriekšējais | Diskusija

from: [info]mikii
date: Maijs. 2., 2006 - 01:37 pm
#

paldies, par šito tooli nezināju. tik tiešām, kad notiek hachchecks, diska aktivitāte ir līdz galam. it kā jau failiem nevajadzētu būt smalki sadalītiem, jo pirms to ielādes defragments tika veikts un brīvās viets bija daudz. būs vēl jāpavēro, kas notiek pie atiecīgajām darbībām.

Atbildēt | Iepriekšējais | Diskusija

from: [info]laumina
date: Maijs. 2., 2006 - 01:40 pm
#

Man shkjiet.. tam pasham DC bija antidefragmentaacijas opcija.
NTFS failsisteemais fragmentaacija iipashi neietekmee aatrdarbiibu. FAT32 tas ir vairaak juutams.
Tev tak nav nejaushi uzkraameejies FAT32 ? :))

Atbildēt | Iepriekšējais | Diskusija

from: [info]mikii
date: Maijs. 2., 2006 - 01:41 pm
#

noup, native ntfs, citu nemaz nav redzējis ;)
bet klients ir utorrent. jāpapēta forumos, varbūt ir kaut kādas ziņas par to..

Atbildēt | Iepriekšējais | Diskusija

from: [info]laumina
date: Maijs. 2., 2006 - 01:48 pm
#

torrenti bremzee kasti.. tur neko dariit.
Viss ko var dariit tas i parbaudiit to kas te tika uzskaitiits..
Droshiibas peec apluuri klienta setingus.. mosh tru kaukaadus buferus vai ko taadu var noraadiit.

Drosh un vienkaarsh risinaajums ir papildus HDD :)
Nieka 35Ls un probleema ir atrisinaata :D

Atbildēt | Iepriekšējais | Diskusija

from: [info]mikii
date: Maijs. 2., 2006 - 01:51 pm
#

jap, par to papildus hdd bija ideja. varbūt ar laiku tiks īstenota. katrā ziņā - paldies par padomiem :>

Atbildēt | Iepriekšējais