Ubuntu Suomen keskustelualueet
Ubuntun käyttö => Ubuntu tietokoneissa => Aiheen aloitti: Ux64 - 19.07.09 - klo:20.40
-
Tulee mieleen tunne että ajassa on siirrytty ainakin 20 vuotta taaksepäin.
Tabista toiseen vaihtamisen firefoxissa kestää yli 20 sekuntia. Uuden tabin avaaminen ja siihen sivun lataaminen bookmarkin kautta kesti yli 3 minuuttia (tämä forum). Jne.
Kaikki johtuu siitä, että siirrän kasaa isompia tiedostoja levyltä toiselle.
Mutta miksi tämä operaatio jumittaa koko järjestelmän? Kuormitus on täysin marginaalista teknisesti. Koko operaatio voisi sujua taustalla niin, että käyttäjä ei käydännössä huomaa yhtään mitään.
Kiva kun tähänkin ehtii kirjoittamaan melkein kokonaisen lauseen ennen kuin teksti näkyy ruudulla.
Missä vika? Olen kyllä aikaisemminkin manannut tätä. Tietysti ennakkoon raskaaksi tiedetyt prosessit pitäisi aina käynnistää ionice ja nice parametreillä, mutta aina näin ei vaan tapahdu. Varsinkin kun ionice vaatii oikeuksia ilman mitään järkevää syytä.
Hyviä ratkaisuita tai ehdotuksia ongelman korjaamiseksi?
-
Tuolle kyllä pitäisi tehdä jotain. Kyseessä on oikeasti todella ärsyttävä piirre, joka kyllä on tuttu myös Windowsista. Ehkä tämä "feature" kuuluisi siihen "sata paperiviiltoa" projektiin. Tämä tuntuu vähän sellaiselta ominaisuudelta, joka vaan sulatetaan käyttäjien päässä ilman sen kummempia mukinoita.
-
Tuolle kyllä pitäisi tehdä jotain. Kyseessä on oikeasti todella ärsyttävä piirre, joka kyllä on tuttu myös Windowsista. Ehkä tämä "feature" kuuluisi siihen "sata paperiviiltoa" projektiin. Tämä tuntuu vähän sellaiselta ominaisuudelta, joka vaan sulatetaan käyttäjien päässä ilman sen kummempia mukinoita.
Minua tuo hidas tiedostojen toiminta/kopiointi/mikä lie ärsyttää lähinnä muistikorttien kanssa, kun se käyttää niin paljon suoritinta... Eikö DMA toimi vai mitä ihmettä...? ??? Vai liittyykö se edes siihen...?
-
Eikö DMA toimi vai mitä ihmettä...? ??? Vai liittyykö se edes siihen...?
tämä minullakin tuli ensimmäisenä mieleen. tiedostojen kopioinnin ei pitäisi viedä juuri lainkaan suoritinaikaa ja minulla firefox hidastelee vain kun prossua kuormitetaan.
-
Minua tuo hidas tiedostojen toiminta/kopiointi/mikä lie ärsyttää lähinnä muistikorttien kanssa, kun se käyttää niin paljon suoritinta... Eikö DMA toimi vai mitä ihmettä...? ??? Vai liittyykö se edes siihen...?
Mulla ongelman syy ei todellakaan ole CPU kuorma. Tehoa on vaikka lampaat söisi ja jos yksi core on jumissa mitä sitten, muitakin on tarjolla vielä 3 kpl.
Oman näkemykseni mukaan kyse on mahdollisten I/O operaatioiden jonosta ja koosta. Ihan kuten TCP/IP sockettienkin kanssa käy, liian isot paketit ja ikkuna, niin kaikki pienemmät operaatiot jumiutuu noihin täysin. Uskon että tässä tapauksessa on samanlaisesta ilmiöstä kyse. Koska itse levyjen suorituskyky on sama, kyse on vain siitä miten tehtävät laitetaan niiden suoritettavaksi. Jostain syystä sallitaan liian iso jono (tai yksittäiset tehtävät on liian suuria). Mitä ilmeisimmin kyse on liian isosta jonosta kuitenkin.
IMHO, NCQ:sta voisi juuri tällaisessa tapauksessa olla apua. Varsinkin jos saman aikaisesti pureattavia jonoja on useampia. Eli on esim 4-10 kpl raskaita levy I/O tehtäviä rinnakkain.
Kun tuota vaan voisi jostain säätää. TCP/IP:llä kun tuntui että yhteys on tukossa, niin auttoi aika kummasta pistää traffic shaperiin pakkosääntö päälle että paketit max 512 tavua ja max window 2048 tavua. Sen jälkeen ei enää paljon piuha mennyt tukkoon. Kymmenet telnet sessiot toimivat tahmatta parin ftp siirron rinnalla hyvin. Mutta jos pisti 1500 paketit ja 64 kilon windowin niin meni taas niin jumiin ettei mitään rajaa.
-
Hmm... Minullakin on tuplaydin, jolla tosin on ikää pari vuotta, mutta silti tuo paneeli appletti näyttää tummansinisellä täyttä palkkia eli IOWait vie kaiken tehon. Jos F-Spotilla siirtää kuvia kamerasta (tai siis muistikortilta) niin hiirigin lagittaa. :-\
Toinen paikka missä olen huomannut hidastumista on NFS-jaot, mutta jotenkin pidin sitä normaalina... ::) Silloin, kun ei oikein pääse tutkimaan niitä jakoja, mutta käytänkin WLANia (kannettava) ja 100MBit reititintä (palvelin on tässä kiinni). Ilmeisesti sitä ei kuitenkaan saisi tapahtua. :D ;)
-
Tulee mieleen tunne että ajassa on siirrytty ainakin 20 vuotta taaksepäin.
Eihän tämä varsinaista ongelmaa poista ja mopokin karkaa taas käsistä (kuten aina), mutta aihetta lukiessa tuli mieleen vanha kikka Firefoxin käytöstä. Kupletin juoni meni hämärien muistikuvien perusteella suurin piirtein seuraavasti:
- Osasta RAM muistia tehtiin 100Mt virtuaalinen RAM-kovalevy.
- Rec editillä siirrettiin kaikki Firefox'in "tempit" ko asemaan.
Vanhassa koneessa nettisurffailu nopeutui tuolloin oleellisesti kun temppejä ei kirjoitettu kovolle ollenkaan. Ikuinen pullonkaula! En tiedä onko tällainen Firefox lisäosa jo olemassa, mutta jos...
Joku minua fiksumpi nikkari kokeilisi saako perusajatuksen toimimaan Linuxissa: Vai onko se kuolleena syntynyt?
Linux jättää joka tapauksessa niin paljon vapaata muistia koneelle, että jotain "arkista hyötykäyttöäkin" sille voisi keksiä. Ei kaikki tiedot ole niin tärkeitä, että niitä tarvitsisi Oho!-varmuuskopioihin saakka kirjoittaa.
Toivottavasti joku tekee jo täyttä häkää uutta distroa (vai mikä tää nyt onkaan) noihin "huomispäivän" koneisiin, jossa muistia on pienen kiintolevyn verran. Strategian ja logiikan hahmottamisen kanssa kun vierähtänee tovi tai kaksi. Näin maallikon näkökulmasta ainakin.
Ja ei kun kaikki rohkeasti vaan ajatusten pulkkamäkeen.
Kyllä Pavlov'in koirat huiskivat häntäänsä kaikille alas asti selvinneille. Ja jatkavat makkaransa syöntiä niin kuin aina ennenkin. Heeeet'..kinen kuulenko ajatuksistani ylitse pursuavaa ironiaa? Tarkoitus saattaa olla kiittää niitä jotka jaksavat pitää kissaa pöydällä ja sylkeä sammakoita yleisen diskurssin noutopöytään.
VAPAAN MARKKINATALOUDEN PERUSTEET: (rautapuolellakin)
1. Voiton maksimointi.
2. Tutkimus ja tuotekehittely.
3. Loppukäyttäjien minimitarpeiden kartoitus (asiakaslähtöisyys).
4. Mitään "lopullista" standardia ei saa muodostua. (juoksutetaan)
-
Tulee mieleen tunne että ajassa on siirrytty ainakin 20 vuotta taaksepäin.
VAPAAN MARKKINATALOUDEN PERUSTEET: (rautapuolellakin)
1. Voiton maksimointi.
2. Tutkimus ja tuotekehittely.
3. Loppukäyttäjien minimitarpeiden kartoitus (asiakaslähtöisyys).
4. Mitään "lopullista" standardia ei saa muodostua. (juoksutetaan)
Markkinatalous
Noin se menee, on se nähty. 1. on tärkein. Kohta 2. tulee vain silloin esille kun kilpailijat tai kohta 3. pakottavat siihen. Nimimerkillä, niin monta kertaa turhautunut siitä, että joku asia on tehty todella välttävästi ja tiedän miten sitä voisi parantaa. Mutta kun korjausta ei ole "pakko" tehdä, niin sitä ei tietenkään haluta tehdä, koska korjaamisesta muodostuu kuluja jotka siten verottaisivat kohtaa 1.
Eli vaikka monesti sanotaan että vapaa markkinatalous ja ammattilaiset tekevät hyviä ohjelmia. Mä sanoisin lähinnä, että ne tekevät niin HUONOJA ohjelmia, kuin markkinat sallivat niiden tehdä. Mitään mielenkiintoa hyvien ohjelmien tekemiseen ei oikeasti ole. Näin se vaan tuntuu menevän, vaikka joskus nuorempana "idealistina" joskus haaveilinkin siitä että jotain tehtäisiin kunnolla. Microsoftin toiminnassahan tämän huomaa myös hyvin, strategia on juuri samanlainen.
Mutta mitä tulee tuohon levy I/O ongelmaan.
Testaisin vielä uudestaan ja varsinkin suuret yksittäiset tiedostot muodostavat isoimman ongelman. Eli syystä tai toisesta kaikki pienemmän levy I/O tehtävät jäävät "tolkuttoman pitkään jonoon" ja toteutuvat vasta kymmenien sekuntien perästä. Kun monet ohjelmat sitten tekvät peräkkäisiä I/O operaatioita, niin aika moninkertaistuu. Edelleen esimerkki tolkuttomasta latenssista ja liian isosta RWIN:istä pätee tähän hyvin.
Kysymys onkin, että voiko tuota levy I/O prioriteettia säätää jotenkin? Haluaisin itse laskea tuota lohkokokoa jolla operaatioita käsitellään. Silloin saisin pienempien tehtävien jonotusajan paljon pienemmäksi.
Outoa että näin radikaaliin ongelmaan ei ole kiinnitetty huomiota, vaikka nimen omaan kernelin CPU schedulerin fairness ja priority inversion ongelmiin on varmasti käytetty tolkuttomasti aikaa. Ehkä se ongelma juuri onkin siinä, että molemmat tehtävät, tuo suuri ja pieni tehtävä ovat samalla prioriteetilla. Mutta silti fairness ei missään nimessä mielestäni toteudu. Tehtävien jako tuntuu enemmänkin tapahtuvan operaatio kuin tavu tasolla.
Historian havinaa ja turhaa tarinaa
Ei millään pahalla, mutta tämä muistuttaa oikein lämpimästi minua DOS, Windos 3.11 ja DeskView ajoista. OS/2:ssa tätä ongelmaa ei muistaakseni ollut.
Paras karhunpalvelus tuolloin oli se, että kun oli yksi serveri joka käytti DV:tä, niin alkoi kopioimaan kahdelta CD:ltä jotka oli CD-swapperissa tavaraa kiintolevylle. Hölmömpikin arvaa miten siinä kävi. Koska levy I/O:t meni ilman optimointia tapahtuma kohtaisina ja synkronisina lopputulos oli tämä.
1. Vaihdetaan CD1 asemaan, luetaan sieltä N kiloa (buffers)
2. Vaihdetaan CD2 asemaan, luetaan sieltä N kiloa (buffers)
3. Kirjoitetaan data 1
4. Kirjoitetaan data 2
5. Suoritetaan muiden käyttäjien operaatioita
6. palataan kohtaan 1.
Ongelmahan ei sinänsä ole suuri. Paitsi tuo taikasana vaihdetaan cdX asemaan. Joka kulutti aikaa noin 5 sekuntia. Näin ollen pelkästään terminaalikäytössä se että käyttäjä sai echon siitä mitä kirjoitti, niin kesti helposti 10-15 sekuntia. ;) Kokä järjestelmä oli siis teknisesti täysin jumissa, vaikka se toimikin. Synkronisella I/O:lla tuo levyjen vaihto oli aika killeriä. Heh heh.
Tuo taitaisi siis toimia ubuntullakin kokemani valossa.
-
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/131094
-
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/131094
En siis ole yksin. Huhhuh millainen keskustelu tuolla oli ja vielä referenssitkin. No hyvä että ongelma on tiedossa ja tulee ehkä joskus kuntoon.
-
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/131094
En siis ole yksin. Huhhuh millainen keskustelu tuolla oli ja vielä referenssitkin. No hyvä että ongelma on tiedossa ja tulee ehkä joskus kuntoon.
juuh, itsekin tuosta kärsin kun siirtää tavarat turpaan varalevylle...
rsyncin kanssa ei jumita niin pahasti...
-
juuh, itsekin tuosta kärsin kun siirtää tavarat turpaan varalevylle...
rsyncin kanssa ei jumita niin pahasti...
Sekä rsyncin voi tietysti ajaa kätevästi ionicen kanssa. Mutta ongelma onkin silloin suurempi kun käyttää nautilusta.
-
Sekä rsyncin voi tietysti ajaa kätevästi ionicen kanssa. Mutta ongelma onkin silloin suurempi kun käyttää nautilusta.
eiköhän kaikki graafiset tiedostoselaimet tuosta kärsi (ainakin myös dolphin).
Oletko kokeillut jotain toista "scheduler"ia oletuksen "cfq" 2.6.18< sijasta?
Anticipatory oli oletuksena >2.6.18 kerneleissä
-
- Osasta RAM muistia tehtiin 100Mt virtuaalinen RAM-kovalevy.
- Rec editillä siirrettiin kaikki Firefox'in "tempit" ko asemaan.
Vanhassa koneessa nettisurffailu nopeutui tuolloin oleellisesti kun temppejä ei kirjoitettu kovolle ollenkaan. Ikuinen pullonkaula! En tiedä onko tällainen Firefox lisäosa jo olemassa, mutta jos... Joku minua fiksumpi nikkari kokeilisi saako perusajatuksen toimimaan Linuxissa: Vai onko se kuolleena syntynyt?
fstab:
tmpfs /var/log tmpfs defaults 0 0
tmpfs /tmp tmpfs defaults 0 0
tmpfs /var/tmp tmpfs defaults 0 0
Firefox about:config:
browser.cache.disk.parent_directory /tmp
Levykäytön vähentäminen (http://wiki.ubuntu-fi.org/Asus_EEE_901_konfigurointi_%28Intrepid_Ibex%29#head-e5ec22107473480cb5e17af4073deb2f418dbaf9)
-
Tulee mieleen tunne että ajassa on siirrytty ainakin 20 vuotta taaksepäin.
Tabista toiseen vaihtamisen firefoxissa kestää yli 20 sekuntia. Uuden tabin avaaminen ja siihen sivun lataaminen bookmarkin kautta kesti yli 3 minuuttia (tämä forum). Jne.
Kaikki johtuu siitä, että siirrän kasaa isompia tiedostoja levyltä toiselle.
Joopa, nyt alkaa mennä usko taas tähän Buntuun (9.04). Tiedostonsiirto (samba) kun on käynnissä niin eipä juuri mitää muuta voi tehdä... :( Muutenkin tuntuu että tämä on hidastunut
parin viikon sisällä muutenkin, mm mplayerin käynnistys kestää uskomattoman kauan. Onkohan tullut joku rikkinäinen päivitys? Tässä alkaa olemaan vaihtoehdot vähissä, joko
64 bittinen Fedora tai win7. Koneessa vääntöä ja muistia kyllä piisaa 4G/Phenom2 x4 mutta on melkein hitaampi kuin athlon 3000 windowsilla... :-[ No tuli näitä ubuntun distroja taas käytettyä melkein pari vuotta putkeen.
-
Joopa, nyt alkaa mennä usko taas tähän Buntuun (9.04). Tiedostonsiirto (samba) kun on käynnissä niin eipä juuri mitää muuta voi tehdä... :( Muutenkin tuntuu että tämä on hidastunut
parin viikon sisällä muutenkin, mm mplayerin käynnistys kestää uskomattoman kauan. Onkohan tullut joku rikkinäinen päivitys? Tässä alkaa olemaan vaihtoehdot vähissä, joko
64 bittinen Fedora tai win7. Koneessa vääntöä ja muistia kyllä piisaa 4G/Phenom2 x4 mutta on melkein hitaampi kuin athlon 3000 windowsilla... :-[ No tuli näitä ubuntun distroja taas käytettyä melkein pari vuotta putkeen.
Oliko tuosta "uhkailusta" jotain hyötyä? Ei tarvitse vastata.
-
Oliko tuosta "uhkailusta" jotain hyötyä? Ei tarvitse vastata.
[/quote]
No eipä ollut mutta tuli itselle purkautumisesta parempi mieli :) Muuten kun ubuntu alkaa olla kovanluokan käyttöjärjestelmä niin siihen laatuun pitäisi pikkasen panostaa. Itse olen väkerrellyt ja viritellyt että homman saa kulkemaan mutta jossain tulee raja vastaan. Toinen asia mikä on kiusannut niin alsan kaatuminen toisinaan kun toinen äänilähde yrittää sitä käyttää. (64 bittisessä versiossa).
Pieni päivitys. Puhdas asennus Ext4 tiedostojärjestelmällä auttoi asiaa todella paljon. Kone on nyt ihan käytettävä nyt vaikka yhtäaikaa siirtää tavaraa verkosta ja usb kovalevyltä. :)
Muoks. Nautilus ilmoitti avatessa ettei voi luoda kansiota (raskaan tiedonsiirron jälkeen). Uudelleenkäynnistys tyssää ja ehdottaa osioiden korjaamista käsin joka taasen ei mene alkua pidemmälle. Levyjärjestelmä sekaisin. Huoh....
-
Pieni positiivinen uutispläjäytys ja muistutus vapauden hyötykäytöstä.
Linux booted in one second:
http://dvice.com/archives/2009/07/linux-booted-in.php
Hatun noston arvoinen suoritus nyt jokatapauksessa.
-
Pieni positiivinen uutispläjäytys ja muistutus vapauden hyötykäytöstä.
Linux booted in one second:
http://dvice.com/archives/2009/07/linux-booted-in.php
Hatun noston arvoinen suoritus nyt jokatapauksessa.
Muistelen että tuon firman valmistama on tämä asuksen käyttämä
http://www.slashgear.com/asus-to-preload-express-gate-instant-on-linux-on-all-new-motherboards-1611670
-
Oikestaan etsiskelin omalle koneelleni ohjelmistosta riippumatonta ekvalisaattoria
kun törmäsin pariin sivuun, jotka saattaisivat tarjota jonninlaista ratkaisua asiaan?
Omat tiedot ei riitä, joten lukaiskaa te jotka olette asian kanssa enemmän sylipainia harrastaneet:
http://linux.softpedia.com/get/System/Operating-Systems/Kernels/Linux-Kernel-Stable-1960.shtml
http://linux.softpedia.com/get/System/Operating-Systems/Kernels/MOSIX-for-Linux-2-6-33977.shtml
Tuoksahti ainakin tutulta vaikken etsimääni löytänytkään.
-
Törmäsin tällaiseen tutkiessani nykytilannetta:
man ionice
Idle A program running with idle io priority will only get disk time when no other program has asked for disk io for a defined grace period. The impact of idle io processes on normal
system activity should be zero. This scheduling class does not take a priority argument. Presently, this scheduling class is permitted for an ordinary user (since kernel 2.6.25).
Normaalikäyttäjä voi käyttää ioniceä idle prioriteetilla. Loistavaa. Lisää vain komentojonoihin ionice -c 3 raskaiden operaatioiden eteen. Mitään tahmaa ei tunnu ja kaikki asiat hoituvat taustalla lähes yhtänopeasti kuin ilman tuota komentoa. Olettaen tietysti että kone on normaalissa desktop käytössä jossa se on kuitenkin 98% idlellä. Tärkeämmät tehtävät tulevat suoritetuksi välittömästi.