abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×

včera 21:33 | Bezpečnostní upozornění

V Sambě byla nalezena a opravena bezpečnostní chyba CVE-2017-7494. Má-li útočník právo ukládat soubory na vzdálený server, může tam uložit připravenou sdílenou knihovnu a přinutit smbd server k jejímu načtení a tím pádem ke spuštění libovolných příkazů. Chyba je opravena v upstream verzích 4.6.4, 4.5.10 a 4.4.14. Chyba se týká všech verzí Samby od verze 3.5.0 vydané 1. března 2010.

Ladislav Hagara | Komentářů: 0
včera 20:44 | Nová verze

Byla vydána nová stabilní verze 4.3.0 integrovaného vývojového prostředí (IDE) Qt Creator. Z novinek lze zmínit například integraci editoru kódu do Qt Quick Designeru.

Ladislav Hagara | Komentářů: 1
včera 20:11 | Bezpečnostní upozornění

Společnost Check Point informuje na svém blogu o novém vektoru útoku. Pomocí titulků lze útočit na multimediální přehrávače VLC, Kodi, Popcorn Time, Stremio a pravděpodobně i další. Otevření útočníkem připraveného souboru s titulky v neaktualizovaném multimediálním přehrávači může vést ke spuštění libovolných příkazů pod právy uživatele. Ukázka na YouTube. Chyba je opravena v Kodi 17.2 nebo ve VLC 2.2.6.

Ladislav Hagara | Komentářů: 6
23.5. 15:18 | Zajímavý software

CrossOver, komerční produkt založený na Wine, je dnes (23. 5. 2017) dostupný ve slevě. Roční předplatné linuxové verze vyjde s kódem TWENTYONE na $21, resp. $1 v případě IP z chudších zemí. Firma CodeWeavers, která CrossOver vyvíjí, významně přispívá do Wine. Přidaná hodnota CrossOver spočívá v přívětivějším uživatelském rozhraní, integraci do desktopu a podpoře.

Fluttershy, yay! | Komentářů: 25
23.5. 15:11 | Zajímavý projekt

V únoru loňského roku bylo představeno několik útoků na celou řadu bezdrátových klávesnic a myší s názvem MouseJack. Po více než roce lze chybu opravit, tj. aktualizovat firmware, také z Linuxu. Richardu Hughesovi se podařilo navázat spolupráci se společností Logitech, získat od nich dokumentaci, přesvědčit je, aby firmware poskytovali přímo a ne jako součást .exe souboru, aby mohl být popis začleněn do služby Linux Vendor Firmware Service (LVFS) a aktualizace tak mohla proběhnou přímo z Linuxu pomocí projektu fwupd.

Ladislav Hagara | Komentářů: 2
23.5. 13:22 | Nová verze

Po roce a půl vydali vývojáři projektu SANE (Scanner Access Now Easy) (Wikipedie) novou verzi 1.0.27 balíku SANE-Backends. Nejnovější verze tohoto balíku pro přístup ke skenerům přináší například významná vylepšení v několika backendech nebo podporu pro více než 30 nových modelů skenerů. Verze 1.0.26 byla přeskočena.

Ladislav Hagara | Komentářů: 0
22.5. 20:55 | Komunita

Od 18. do 21. května proběhla v Saint-Étienne Linux Audio Conference 2017. Na programu byla řada zajímavých přednášek a seminářů. Videozáznamy přednášek lze zhlédnout na YouTube. K dispozici jsou také články a prezentace.

Ladislav Hagara | Komentářů: 0
22.5. 20:44 | IT novinky

Hodnota Bitcoinu, decentralizované kryptoměny, překonala hranici 2 200 dolarů. Za posledních 30 dnů tak vzrostla přibližně o 80 % [reddit].

Ladislav Hagara | Komentářů: 8
22.5. 17:33 | Nová verze

Po 5 měsících vývoje od vydání verze 0.12.0 byla vydána verze 0.13.0 správce balíčků GNU Guix a na něm postavené systémové distribuce GuixSD (Guix System Distribution). Na vývoji se podílelo 83 vývojářů. Přibylo 840 nových balíčků. Jejich aktuální počet je 5 454. Aktualizována byla také dokumentace.

Ladislav Hagara | Komentářů: 1
22.5. 17:22 | Nová verze

Po 5 měsících vývoje a 3 týdnech intenzivního testování byla vydána verze 12 open source systému Nextcloud, forku ownCloudu, umožňujícího provoz vlastního cloudového úložiště. Přehled novinek i s videoukázkami v poznámkách k vydání. Pro vyzkoušení je k dispozici demo.

Ladislav Hagara | Komentářů: 10
Chystáte se pořídit CPU AMD Ryzen?
 (6%)
 (32%)
 (1%)
 (8%)
 (44%)
 (9%)
Celkem 610 hlasů
 Komentářů: 62, poslední 19.5. 01:57
    Rozcestník

    Dotaz: MySQL - vysoké i/o zatížení s InnoDB?

    23.9.2009 08:58 Leinad
    MySQL - vysoké i/o zatížení s InnoDB?
    Přečteno: 812×

    Mám na netu jednu PHP webovou aplikaci, která má dlouhodobě problémy s rychlostí pravděpodobně kvůli ne ideálně udělané databázi a SQL dotazů na ni. Často jede rychle, často se ale taky stává, že se na půl minuty zasekne.

    Z logů slow_query. Velké množství dotazů, které překročil čas 5 vteřin vykonování (často i přes 30s) byl mezi jinými jednoduchý update. Konkrétně dotazy typu
    UPDATE statistika SET doba_online = doba_online + '7' WHERE jmeno = 'Leinad'
    Tabulka "statistika" má kromě pár dalších sloupců sloupce "jmeno", který je VARCHAR a index a "doba_online", který je TIME. Tato tabulka slouží pro logování, jaký čas daný uživatel strávil na webu, takže dotaz se provádí každým kliknutím uživatele. TAbulka je InnoDB a má cca 300 řádků.

    Zkusil jsem přehodit tabulku na engine MyISAM a už se tyto dotazy v logách slow_query neobjevují. Mám podezření, že InnoDB má vyšší režii na disk. Jedu na virtuálním serveru a když jsem se chvíli koukal na "top", tak jsem viděl často vyskočit hodnotu %wa až na 100%.

     

    Je možné, že InnoDB má až tak moc velkou režii proti MyISAM? Četl jsem, že má vyšší (kvůli transakcím), ale nedovedl jsem si nikdy představit, že by to takhle mohlo zlikvidovat výkon... Nemáte nějaký tip, co s tím?
    (Rada dát všechny tabulky na MyISAM znemožní použití transakcí u dotazů, kde se to hodí. Rada dát část tabulek do MyISAM a zbytek nechat na InnoDB by asi pomohla zvýšit rychlost, ovšem zbývající dotazy typu UPDATE a INSERT budou stále dělat problémy, jen jich bude méně...)

    MySQL verze "5.0.32-Debian_7etch3-log".

     

    Pozn.: Očekávám kritiku návrhu tabulky, kdy není ideální použití pro index tabulky typu VARCHAR. Vím to, ale nemyslím si, že má cenu se pouštět do opravy, když to můj problém stejně nevyřeší.

    Odpovědi

    23.9.2009 10:15 x22
    Rozbalit Rozbalit vše Re: MySQL - vysoké i/o zatížení s InnoDB?
    Vela % I/O-wait (WA v tope) je pri databazi a web aplikacii celkom normalne.

    Co by tam robilo I/O 5s v takomto dotaze na 300 riadkovej tabulke? Ten dotaz IO nerobi asi vobec, lebo cela tabulka bude v cache, ked sa tak casto pouziva. CPU tiez nema co robit 5s, takze to bude asi nejake zamykanie.

    Ked sa podobny dotaz robi casto, tak tych updatov v jednej tabulke moze byt dost naraz. Ak su pripadne v dlhsich transakciach, tak to moze vadit.

    23.9.2009 11:58 Leinad
    Rozbalit Rozbalit vše Re: MySQL - vysoké i/o zatížení s InnoDB?

    Nevyužívá se cache databáze při dotazech typu SELECT, nikoliv UPDATE?
     

    Zamykání by tam být u tohoto dotazu nemělo. Ta "statistika" je hlavně UPDATEována přihlášeným člověkem, málokdy jiným uživatelem. Tj. nemělo by tam být žádné čekání na zámek. V logu slow_query se psalo navíc u těch dotazů "Lock_time: 0", jen parametr  "Query_time:" je vysoký...

    23.9.2009 18:04 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: MySQL - vysoké i/o zatížení s InnoDB?
    Samotný dotaz je dost neškodný, spíš by to chtělo vědět, v jakém kontextu se vykonává. Podle popisu problému se čeká na disk. InnoDB narozdíl od MyISAM synchronizuje commity transakcí na disk, aby po pádu serveru byla DB konzistentní. Doporučuju se podívat na několik věcí:
    1. Pokud se vykonává několik SQL zápisů (insert, update, delete) najednou, obalit je do begin...commit, aby se to zapsalo jen jednou a ne po každém příkazu
    2. Pokud máte hodně paralelních zápisů najednou tak si holt musíte počkat, až se všechny vyřídí, nebo koupit diskový pole, lepší řadič, nebo použít jinou technologii (myisam nebo memory table pokud Vám nejde o integritu po pádu)
    3. Případně lze použít nežurnálovací filesystem pro oddíl s databází (nebo přímo prázdné místo na disku), jelikož integritu dat řeší InnoDB sama o sobě
    4. Pokud jste ve VM, platí výše zmíněná rada tuplem: pokuste se pro oddíl s databází virtuálního stroje přidělit oddíl na disku hostitele, a ne soubor přes loopback (nedejbože na žurnálovacím FS)
    5. Některé SQL aplikace jsou navyklé kvůli MyISAM použít LOCK TABLES, pokud se tam něco takového vyskytuje, tak by stálo za to to přepsat do transakcí
    Co se týče indexů, tak to je asi v tuto chvíli méně tíživý problém. VARCHAR by vadit nemusel, ale zrovna tak můžete indexovat např. jen podle prvních 20 znaků toho pole... pro nějakou lepší radu by to chtělo vidět schema a typické dotazy (SELECTy).

    In Ada the typical infinite loop would normally be terminated by detonation.
    23.9.2009 18:05 pht | skóre: 48 | blog: pht
    Rozbalit Rozbalit vše Re: MySQL - vysoké i/o zatížení s InnoDB?
    PS. ještě bych dodal k těm žurnálovacím FS, že ext3 je v tomto případě nejhorší možná volba (např. proti XFS), protože fsync() na soubor s databází sesynchronizuje zápisy do všech souborů v systému, ne pouze do jednoho :(
    In Ada the typical infinite loop would normally be terminated by detonation.
    23.9.2009 22:03 Leinad
    Rozbalit Rozbalit vše Re: MySQL - vysoké i/o zatížení s InnoDB?

    Tak problém zdá se vyřešen. Zvýšení innodb_buffer_pool_size. Byl nastaven standardně na 8MB. Databázi jsem měl (hlavně asi díky fórám a logováním) velkou 30MB, takže velké tabulky s fórem zdá se vyhazovaly tabulky jako "statistika", do které se každým klikem uživatele zapisovalo. A přepnutí na MyISAM fungovalo zdá se proto, že má možná vlastní jiný parametr cache (ehm, jen domněnka).

     

    Díky tedy za rady a omlouvám se, že jsem si dostatečně neprohledal web předem. Resp. googlil jsem před podáním dotazu tady na fóru a našel jsem, že cache ovlivňuje rychlost DB, ale našel jsem jen články o cache využívanou při dotazech typu SELECT, narazil jsem na rady ohledně indexů, atd., ale to že tam je ještě další cache pro celé tabulky jsem zjistil bohužel až teď. No, tak snad tato diskuse pomůže v budoucnu někomu dalšímu, kdo se s tímto problémem setká.

    Jinak, ten článek, co mi pomohl, byl na adrese <a href="http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/">http://www.mysqlperformanceblog.com/2007/11/03/choosing-innodb_buffer_pool_size/</a>

     

    Založit nové vláknoNahoru

    Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

    ISSN 1214-1267   www.czech-server.cz
    © 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.