Dotaz: vycisteni Debianu

[manasekp]

zdravim,
potreboval bych poradit jak na vycistit a celkove zrychlit debian. pri beznem pouzivani me pripada ze je system hodne pomaly, hlavne se to tyka velkeho zatizeni disku pri spousteni jakychkoliv programu. Nevim cim to muze byt, protoze uplne nova instalace na stejnem zeleze byla radove rychlejsi nez tato cca rok stara a nejak vyrazne vic programu nemam nainstalovanych. Zkousel jsem prohledavat forum a skusil jsem deborphan a apt-get clean ale nejak moc to nepomohlo. Kdysi jsem se tu ptal jak je to s fragmentaci linuxovych filesystemu, protoze jsem na to byl zvykly kdys jsem pouzival win a bylo me receno ze fragmentace neexistuje a defragmentace se neprovadi.
Takze bych se chtel zeptat co udelat pro zrychleni prace se systemem, hlavne stim diskem...

konfigurace: Debian testing 2.6.15-1-k7, disk Seagate 200GB 7200rpm, SATA, 8MB. CPU Sempron 2200+, RAM 512MB.
Jeste takovy detail - / mam 14GB velky a je vyuzitych 4GB, jsou na jednom oddile vsechny adresare krome /home. Premyslel jsem jestli by nepomohlo sytstem preinstalovat a dat zvlast treba /usr a /var, ale nevim jestli by to k necemu bylo, jestli mate nekso skusenosti tak napiste.
Diky.

Odpovědi

[Heron]

Kdysi jsem se tu ptal jak je to s fragmentaci linuxovych filesystemu, protoze jsem na to byl zvykly kdys jsem pouzival win a bylo me receno ze fragmentace neexistuje a defragmentace se neprovadi.

Tohle je mýtus, fragmentace FS celkem logicky existovat musí. Linuxové FS si s tím sice umějí poradit lépe (např. lepším vyhledáváním volných bloků při vytváření souoborů), než např. FAT, ale není to tak slavné, jak si někteří myslí. Sám jsem se tímto problémem zabýval, jediný FS, který má online defrag je XFS (a nástroj xfs_fsr). A pro ext3 jsem našel jedinou radu: překopírovat soubory jinam a nakopírovat zase zpět. Takže pokud to nemáte na XFS, tak vám nic jiného nezbude.

[manasekp]

diky za reakci, rikal jsem si ze fragmentace asi nejaka bude. ale kvuli tomu prechazet na jiny FS se me moc nechce. O prekopirovani dat jinam a pak zpet jeste pouvazuju, jenomze to je takove hrube reseni ktere resi az dusledek. A taky si myslim ze to spomaleni nebude zpusobeno jenom timto, nekde to musi jit jeste vyladit. Tedka si hraju s aptitude a likviduju kazdy balik ktery nepotrebuju, mozna to trochu pomuze a nebo si taky znicim system...

[_]

todle muze byt problem pokud je disk prilis zaplneny.

byva to ruzne podle verze jadra a souboroveho systemu, ale pokud je min jak 1GB volneho mista na velkych discich, tak obecne zacinaji fungovat "hur". Ale pro nevim kterou verzi jadra delal nekdo benchmark ext3 a vypadlo z nej, ze kriticka hranice zacina od 200MB zbyvajiciho volneho mista. Samozrejme pokud nejde o linearni pristup...

[Heron]

Přiznám se, že jsem to příliš netestoval. Ale když jsem po cca 1 roce užívání ext3 FS (a po neustálném utvzování ostatních linuxáků v tom, že linux defrag nepotřebuje), zjistil (nástrojem filefrag), jak moc jsou některé soubory fragmentované (desítky až stovky fragmentů per file -- rekord byl tuším 5600), začal jsem hledat na webu.

A kromě opětovného ujistění, že linux defrag opravdu nepotřebuje jsem našel lidi s podobným problémem, včetně jednoho chudáka, který měl 90% souborů non-continue. Jediný FS, který umí defrag je XFS. A při pohledu na výsledky každodenní defragmentace (kde vidím desítky souborů s průměrně 5 fragmenty) je mi jasné, že ostatní FS na tom nemohou být lépe. Dodám, že volného místa mám min. 30%. Celkem mě zaráží, že vývojáři FS na tohle nemyslí, a že to neumí třeba nástroj fsck (když už umí vytvořit index pro adresáře), třeba offline, to už je jedno.

[Kyosuke]

Otázka je, jakého charakteru ta fragmentace je. Jestli se jako fragment počítají jen fyzicky nesousedící chunky, ještě to nemusí skoro nic znamenat. Pořád ještě můžou být blízko sebe na stopě nebo na blízkých stopách - pokud vím, přesně o tohle se ext3 při zápisu snaží. Charakter přístupu taky leccos ovlivňuje, náhodný přístup k bloku to nezpomaluje.

[Tomáš]

K tomu prekopirovani mam otazku. Bude system bootovat, kdyz mu takhle prekopiruju jadro tam a zpatky? Jak zavadec mam GRUB. U Lila jsem si jisty, ze to fungovat nebude.

[manasekp]

me system po prekopirovani bez problemu nabootoval. ale oddil jsem nerusil, jen jsem z neho vse smazal a pak nakopiroval zpet. a na grub by to nemelo mit zadny vliv, ten mas v MBR ne ?

[pepe1]

http://geekblog.oneandoneis2.org/index.php/2006/08/17/why_doesn_t_linux_need_defragmenting

[Heron]

Velice hezké "vysvětlení"

Přemýšlivý čtenář si do něj jistě doplní kroky, které povedou ke fragmentaci jakéhokoliv FS se sebelepším vyhledáváním volných bloků.

[robertK]

fragmentace existuje, ale je mala dokud neni disk skoro cely plny, což není váš případ, tak bych tu fragmentaci asi fakt neřešil.

[Heron]

Opravdu? Tak proč jsem jednou měl na disku zaplněném 30% soubory s cca 1500 fragmenty? Stačí např. zapisovat součastně do 5 různých souborů a ty potom rozhodně nejsou uloženy v jednom bloku.

[pepe1]

Zajímalo by mě jestli se fragmentuje disk s ext3 při použití třeba Gparted pokud oddíl zmenším. Pokud to udelám s ntfs tak je disk silně fragmenován.

[jgv]

Mas zapnute DMA? Kdyz jsem kompiloval nove jadro, tak mi nejak ta volba vypadla a system byl pomaly jak snek.

[manasekp]

je mozne ze v tomto bude problem, nejsu si sice jisty jesli DMA neni jen u IDE disku ale:

# hdparm /dev/sda

/dev/sda:
 IO_support   =  0 (default 16-bit)
 readonly     =  0 (off)
 readahead    = 256 (on)
 geometry     = 24321/255/63, sectors = 390721968, start = 0

nikde tam tam nevidim using_dma = 1 (on) takze DMA u toho disku zaple neni.
zkousel jsem hdparm -d /dev/sda a nic se nezmenilo, tak nevim.
btw. mam distribucni jadro, ne vlastni takze podpora v jare by mela byt.

[MaT]

Možná zkusit sdparm (utilitka podobná hdparm, ale pro SCSI zařízení).

[secido]

Co povie hdparm -tT /dev/sda?

[manasekp]

# hdparm -tT /dev/sda

/dev/sda:
 Timing cached reads:   1300 MB in  2.00 seconds = 649.45 MB/sec
 Timing buffered disk reads:  176 MB in  3.01 seconds =  58.40 MB/sec

[secido]

Myslim, ze s diskom problem nebude. Programy su pomale pri spustani alebo aj za behu? V grafike alebo aj na konzole? Mozno je to len subjektivny pocit , naroky na rychlost casom rastu.

[manasekp]

subjektivni pocit to je, v podstate to nemam jak zmerit. Je to videt hlavne pri spousteni aplikaci, pri behu ani ne, Jde me spis o to ze pri nove instalaci byl system VYRAZNE rychlejsi, a postupne se spomaluje, aniz bych mel nainstalovanych vic balicku. v postate jedina zmena je upgradovani systemu pomoci aptitude dist-upgrade. Takze nechapu cim se mohlo zpusobit ze system uz nema puvodni rychlost.

[fakenickname]

A co procesy? Neřádí v nich nějaký zlý démon? ps aux a ps aux |wc -l ?

[manasekp]

ps aux |wc -l napise 94. to si myslim ze neni moc. A bohuzel nejsu zas takovy exxpert abych v procesech nasel neco co muze skodit, muzu sem postnout ps aux jestli to knecemu bude.
jeste

# free -m 
             total       used       free     shared    buffers     cached
Mem:           504        370        133          0         19        212
-/+ buffers/cache:        139        364
Swap:          666          0        666

RAM taky neni nejak zaplnena a uptime je maly.

# uptime
 11:33:33 up  1:41,  2 users,  load average: 0.10, 0.23, 0.23

[fakenickname]

Swap 666? No vypadá to docela v pořádku. Když nahodíš ps aux tak tam třeba něco najdem.. Možná kdyby si zkoušel vypínat různé procesy a sledovat jak moc to bude ovlivňovat to zpomalení systému, tak by jsi něco najít mohl. Jak píšeš, prováděl jsi dist-upgrade, to může být kámen úrazu, zvlášť v případě Debian Testing. Je možné, že se porušily nějaké závislosti či si něrozumí nějaká nová verze důležité aplikace s jinou a vytrvale čekají na spolupráci, která nakonec 'time-out'uje.. Takže prohledat logy by nebylo na škodu.

[fakenickname]

Jo a taky - není v cronu něco zvláštního? Jak je vytížený systém? uptime ?

[manasekp]

rozhodl jsem ze se ze skusim to co me radil Heron vyse. prekopirovat cely / na jiny oddil disku a pak zas zpatky, treba se to zbavi fragmentace a pomuze to. Predstavuju si to tak ze nabootuju slax a treba do /mnt/system pripojim / a do /mnt/home dam domovsky adresar. pak zkopiruju cely obsah /mnt/system do /mnt/home, puvodni smazu a pak to skopiruju zase zpet.
Akorat bych potreboval poradit jak to skopirovat, asi pomoci cp, ale tak aby to zachovalo vsechna opravneni. Proste aby to nezmenilo vubec nic, byl bych nerad kdyby system nenabootoval. Taky me neni jasne co se stane s adresari /proc a /dev, nebude to necemu vadit ?

[fakenickname]

misto cp bych asi spis pouzil dd a udelat obraz..

[zabza]

Hm, a ta defragmentace se z imagem udělá jak?

[manasekp]

to prave nechcu, myslim ze pro tento pripad je lepsi kopirovani na urovni souboru. kdybych pouzil dd tak to bude asi k nicemu protoze zpatky prekopiruju uplne to same, s fragmentaci. prave jsem si myslel ze pri kopirovani po souborech se to lepe na disku usporada a to je to ceho chcu dosahnout.

[Libor Klepac]

ddckem muzu kopirovat jednotlive soubory, myslim, ze jsem si kdysi napsal skript prave pro ucely kopirovani souboru po jednom fyzickem disku (nebo mozna presunu, uz nevim ... slo o jeden disky, ale ruzne filesystemy)

[secido]

Obraz nic neriesi, potrebujes kopirovat subory. Ja by som pouzil cp -a resp. dobre skusenosti mam s rsync -a a nanovo vytvoril filesystem. Posli ps aux a skontroluj dmesg.

[manasekp]

takze bych to videl nejak tak: (ve slaxu)>

cp -a /mnt/system/* /mnt/home/backup potom rm -rf /mnt/system/* a nakonec cp -a /mnt/home/backup/* /mnt/system/ pak shutdown -r now a budu doufat ze to pojede
Myslite ze jsem na nic nezapomel, nebo spis bude to fungovat ?

[fakenickname]

no moc bych tomu neveřil, ale tak co.. data máš takže v nejhorším nová instalace.. :)

[manasekp]

do nove instalace se me moc nechce, proc bys tomu moc neveril ?

[Tomáš Honzák]

IMHO na debianu není nová instalace žádnej extra malér... zazálohuju /etc, /home apod nemusím protože je mám na zvláštních particích , uložím si výstup z dpkg --get-selections , nainstaluju base system, dpkg --get-set-selections mi obnoví požadované stavy balíčků a jsem jeden apt-get od cíle

[Heron]

Jo, tohle by mělo fungovat. Sám kopíruju systém pomocí cp -a běžně (dokonce to jde i v mc spouštěném pod rootem -- má tam položku zachovat práva). Jinak, místo vymazání obsahu původního / bych raději znovu vytvořil FS (pokud ext3, tak s parametry: journal_writeback, commit=60 (klidně i víc), noatime, dir_index).

Jak někdo psal, nejprve si změř pomocí time jak dlouho se staruje pomálá aplikace teď a zkus to samé po rekopírování. Ať vidíš, jestli to pomohlo.

[ZmaTkar]

Ještě můžeš zkusit "změřit" pomocí time příkaz dobu startu nějaké aplikace, a po výše uvedených úpravách to změřit znovu. Případně porovnat s časem z čerstvé instalace. Já mám debian testing starý přes rok, / má zabráno 8GB z 10GB a nepozoruji nějaké výrazné zpomalení. Updatuju to skoro denně, pokud mi tedy apt-get nechce odstranit něco co chci mít nainstalováno :)

[janskyj]

Já jsem měl Debian testing/unstable na Celeronu@400MHz, 192MB RAM. Updatoval jsem denně až týdně a po nějaké době používání mi přišlo, že se třeba start X serveru vyrazne zpomalil (a bylo to právě skokově, když jsem ho přeinstaloval na novější verzi a doplnil tam nějaké fonty). Myslel jsem si, že je to zapříčiněnou defragmentaci, ale když jsem ten disk skopíroval sem a tam, tak to nepomohlo Jěště ho doma mám, jenom dotoho nikdo nebootuju, ale když jsem to nedavno spustil, tak to bylo hóóóně pomalí (s porovnaní s novými počítači). Jako druhá věc která mě napadla, že by to mohla zapříčinit byla "nabalenost" konfiguračních souborů (a třeba i existence více konfiguračních souborů od více verzích-protože jsem třeba nenechal nový balíček přepsat můj upravený konf. soubor, i když se lišil)+ inicializace dalších a novějších modulů, fontů, nebo jiných částí...
Ale potom jsem začal používat nový rychlejší počítač, tak me tento problém přestal mrzet. Takže zůstal nevyřešen...

[Bohdan]

man prelink

[manasekp]

pomoci cp -a jsem prekopiroval pryc cely / a pak jsem ho dal zase zpatky, viz muj komentar vyse. system bez problemu nabootoval a je znat velky rozdil v rychlosti - spousteni aplikaci, celkova odezva systemu. mozna i boot se o neco malo zrychlil. zrejme fragmentace linuxovych FS nebude tak bezvyznamny problem jak vsichni tvrdi

[Thaweg]

Možná by to chtělo napsat o tom blog a tam shrnout zkušenosti. Ať to nezapadne, třeba se v diskuzi dozvíme i jiná řešení.

[Libor Klepac]

con kolivas na to ma skriptik, take vlastne jenom kopiruje soubory tam a zpet, no to snad delaji i ty defragmentery ve windows

http://ck.kolivas.org/apps/defrag/

[secido]

Aky mas suborovy system?

[manasekp]

mam Ext3

[secido]

Mohol by si este vyskusat, teraz ked sa uz s tym zabavas , ake su rozdiely v rychlosti medzi roznymi suborovymi systemami, ide mi hlavne o ext3, reiserfs, xfs a jfs. Osobne vsade vacsinou pouzivam reiserfs, ale jeden system (stare ubuntu 5.04) bezi / ako ext3 a /usr/ ako xfs. Nedavno som instaloval gentoo a napadlo ma, ze skusim jfs (vraj najlepsi fs). Fungoval v pohode a na to, ze ma uplne dorazilo, ked som skopiroval / na reiserfs. Z 2.5G bolo hned 1.7G. Teda na gentoo, ktore ma kvantum malych suborov jednoznacne reiser.

[manasekp]

jak bych to mel vyskouset ? napadlo me ze kdyz jsem cely / zkopiroval pryc tak bych mohl puvodni oddil zrusit a vytvorit novy s jinym FS a na neho to nakopirovat. to by bylo uplne nejlepsi pro porovnani rychlosti ale jestli by to fungovalo to nevim..

[secido]

Samozrejme, ze by to fungovalo, ved si to uz robil nie?

[manasekp]

ne, ja jsem jenom smazal obsah oddilu ale oddil sem znovu nevytvarel. Vytvorit novy oddil s EXT3 by urcite slo ale premyslel jsem co by se stalo kdybych zrusil stavajici EX3 oddil a misto neho dal treba ReiserFS, a nakopiroval bych na nej system. Jestli by to fungovalo. (?)

[secido]

Ano samozrejme, ze by to fungovalo. Napr. pre reiserfs mkfs.reiserfs /dev/... a skopirovat naspat.

[secido]

Este dodam samozrejme, ze musi byt podpora suboroveho systemu v jadre a treba trochu upravit /etc/fstab.

[Lenny_]

Myslim, ze priste by uplne stacilo tohle http://freshmeat.net/projects/defrag/
Tusim ze o&o software (vyrabi defrag pro win) nabizel i nejaou free verzi pro ext oddily, ale chtelo by to zapatrat

[matla]

Se obavam, ze je jenom na ext2, minix a xiafs.

[*]

e2fsdefrag - nikdy jsem to nepouzil a nevim v jakem je to ted stavu. jeden znamy to uspesne pouzival v dobach redhat 5.0 - 6.0.

xfs ma taky neco.