seda 2x kiiruse suurendamist kodu impordile või ketaste osale? FS kindlasti ei mängi nii suurt rulli. BTRFS vs. ext4 BTRFS on küll aeglasem aga see ei ole nii suur vahe. Samas tundub, et BTRFS -l on suurem tulevik kui EXT -l ... aga kst.
Kuupäeval 28. detsember 2011 16:29 kirjutas Jaak Laineste (Nutiteq) <j...@nutiteq.com>: > Kuupäeval 25. detsember 2011 17:39 kirjutas Jaak Laineste (Nutiteq) > <j...@nutiteq.com>: >> Muide, keda huvitab masina performance ja kel on ideid kuidas >> serverit/baasi (eelkõige gis-nimelist) kiiremaks teha et uuendused >> järgi jõuaksid praegusele ajale (ja veel parem kui mööda läheks), siis >> http://kaart.maakaart.ee/munin/ on toimivad kõverad ka nüüd olemas. > > Ma Munin graafikutest lugesin ühe asja - välja. Ketas, mille peal on > baas on sda meil. See on hw-scsi kontroller, raid-5-s. Selle IO > graafik on > http://kaart.maakaart.ee/munin/maakaart.ee/AMS-live.maakaart.ee/diskstats_iops/sda.html. > Disk utilization on 100% pidevalt, seega võiks kiirus olla põhjas. > Samas peaks selle kirjutuse maht olema mahult võrreldav OSM peamise > serveri kirjutusega andmebaasi, sest see sõltub vaid uuendustest, ja > mitte renderdustest (mis suurendavad tile-ketta kirjutust ja > andmebaasi lugemist). OSM tileserveri baasiketta graafik on > http://munin.openstreetmap.org/openstreetmap/yevaud.openstreetmap/linux_diskstat_iops_sdd.html > > Suurim erinevus mis mul torkas silma oli et keskmine kirjutuse IO-de > kogus on meie serveril 391 write units/sec, keskmine unit size on 6.81 > KiB (4,5 ... 12). OSM serveril on samas 32 write IO/sec (10x vähem), > ja size on 16.21 KiB (7...156). Unitite arvu erinevus võib olla > sellest, et peamiselt on meil tegu andmete suures mahus laadimisega > (6-12 tundi korraga), OSM server tegeleb minuti kaupa uuendustega. > > Oskab keegi öelda, et miks võib olla nii erinev IO write unit size, > äkki on see oluline kirjutuskiiruse osas? On see määratud kuidagi > automaatselt, kerneli, failisüsteemi (seal on btrfs muide) või > postgres seadetega? > > Googledades leidsin täheldusi [1] [2] [3] [4], kust saan aru et BTRFS > võibki väga aeglane just andmebaasi kirjutamise operatsioonides, ja > selle jaoks võiks olla olemas fix [1] kohaselt: kerneli uuendamine 3.0 > peale (meil on 2.6.38). [2] viitab et ZFS võiks päris kiire olla, ja > kiireim on [4] kohaselt üldsegi ext3. Mis on live-OSM masinas, ei tea. > Igatahes benchmargid ütlevad et BTRFS on hea featuuride poolest, aga > kiiruselt veel toores. > > Võtsin praegu postgres-ilt fsync välja, mis peaks igal juhul kiirust > parandama (masina krässil baasi katkiminemise riski hinnaga), näis kas > on olulist vahet. Järgmisena proovin /storage andmebaasi kasutada, see > on ext4 vähemasti. Vaja oleks 2x kiiruse parandust vähemasti. > > [1] > https://events.linuxfoundation.org/slides/2011/linuxcon-japan/lcj2011_xie.pdf > [2] http://blog.dryft.net/2011/09/benchmarking-zfs-xfs-ext4-and-btrfs.html > [3] http://archives.postgresql.org/pgsql-general/2011-04/msg00709.php > [4] > http://www.ilsistemista.net/index.php/linux-a-unix/6-linux-filesystems-benchmarked-ext3-vs-ext4-vs-xfs-vs-btrfs.html?start=5 > -- > > Jaak > > _______________________________________________ > Talk-ee mailing list > Talk-ee@openstreetmap.org > http://lists.openstreetmap.org/listinfo/talk-ee -- A. Kaaber _______________________________________________ Talk-ee mailing list Talk-ee@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ee
