Komentáře k článku

Upgradujeme MySQL server

Hardware je velmi rychle se rozvíjející oblastí IT a výkon počítačů neustále roste. Pojďme se podívat na to, jak správným způsobem upgradovat stávající databázový server, abychom maximalizovali výkon s co nejmenšími náklady.

Zpět na článek

12 komentářů k článku Upgradujeme MySQL server:

  1. Jiri J.

    Doplnění

    „nicméně vlivem nedostatku RAM je nadále nutné neustálé čtení a zápisy z/na disk“ – zde by možnábylo dobré zdůraznit, že autor má na mysli swap, v případě disk cache to nedává smysl, PAE kernel může (AFAIK) použít „up to 64G“ paměti i pro cache.
    U RAID0 (nebo jeho variant) pozor na stripe size, při malé velikosti roste sice teoretická rychlost čtení menších požadavků, ale pochopitelně roste i režie. Co víc, nastává daleko větší šance na rozdělení řádku mezi dvě odnože. Pokud se nějaká aplikace pokusí číst celý tento řádek, je potřeba seekovat na obou větvích. Daleko lepším řešením v případě 2 disků je (mimo heavy-write workloady) použít RAID1. Zvlášť na BSD, kde kernel umí i dynamicky „stripovat“ sekvenční čtení, je schopen zapisovat na jeden disk a číst z druhého (a uchovává jistou formu primitivních „transakcí“), oproti tomu mdadm hraje víc na striktní sync disků.
    Jak bylo v článku zmíněno, velkou většinu času tráví server čekáním na I/O disku, je tedy na místě uvažovat o 10000+ RPM discích, případně SSD. Pochopitelně RAM je taky důležitá, na CPU mnohdy ani moc nezáleží. Většinu „zatížení“ procesoru stejně tvoří iowait.

  2. okbob

    swap u dedikovaného SQL serveru

    Jestliže swapuje server na kterém běží dedikovaný SQL server, tak to neznamená nic jiného než špatnou konfiguraci databáze. tj. špatnou konfigurací db lze totálně zazdít výkon bez ohledu na hw a zatížení. Databáze musí být vždy nakonfigurována tak, že systém neswapuje!

  3. digri

    spousta nepřesností
    Článek jsem pouze proletěl, ale spousta autorových tvrzení už na začátku článku není pravdivá, dál jsem se rozhodl to nečíst.

    • např. tvrzení 1 o tom, že těch 8GB jsou na 32bitu vyhozené peníze… Ano, jeden proces MySQLky tu paměť skutečně využít nedokáže, nicméně to ještě neznamená, že se ta paměť nepoužije na diskovou cache.
    • Tvrzení 3 je velmi závislé na velikosti databáze a typu prováděných operací, takto obecně to neplatí. Na disk se pochopitelně bude zapisovat, i kdyby se celá DB vlezla do paměti. Databáze poskytující ACID transakce musí data dostat co nejrychleji do perzistentního úložiště, počet zápisů na disk je tedy závislý na počtu zápisových transakcí.
    • ad MySQL a počet jader) Dle našich testů má MySQL obrovské problémy (alespoň na InnoDB enginu) s využitím více jader, díky zamykání uvnitř InnoDB nedokáže využít více než jedno jádro, takže o počet jader bych se s MySQL vůbec nestaral. Je možné, že to s MyISAM či jinými storage enginy zvládá lépe, ovšem je otázka, jak moc se hodí pro produkční nasazení.
    1. okbob

      Re: spousta nepřesností

      Pro efektivní provozování MySQL je nutné MySQL opatchovat (nebo používat vývojové verze) viz MySQL percona|facebo­ok|google patch. Na druhou stranu, lidí, kteří by si na něco takového troufli a zároveň věděli, co dělají, tu moc nebude. Řešením je počkat si na novou verzi MySQL – snad brzy vyjde 5.5

      1. Blaxi

        Re: spousta nepřesností

        Konkrétně Percona server lze stáhnout přímo na stránkách firmy viz. http://www.percona.com/software/percona-server/. Výkonově je tento server opravdu na daleko lepší úrovni než MySQL a až vyvíjená verze 5.5 stírá rozdíly. GA verze MySQL 5.5 by měla vyjít co nevidět, plánováno bylo v polovoně roku 2010. No snad bude vývoj pod Oraclem pokračovat i nadále tímto trendem.

  4. v.g

    Desktop CPU vs. server CPU

    A mě by zase zajímalo, jak je to s tím „daleko vyšším výkonem“ serverových CPU oproti desktopovým. Argumenty pro serv. jsou myslím jasný, ale šlo by to alespoň řádově nějak specifikovat?
    Dejme tomu, že bych chtěl postavit MySQL server pro interní použití – nejde mi tedy o žádné „enterprise“ vlastnosti serverových komponent a 99.999% dostupnost, ale výhradně o poměr cena / výkon. Odpovídá cenový rozdíl alespoň přibližně rozdílu ve výkonu?

    1. Blaxi

      Re: Desktop CPU vs. server CPU

      Samozřejmě, že i desktopový procesor v poměru cena/výkon může být dostačující. Bohužel k tomu, aby bylo možné přímo něco doporučit, tak by bylo třeba vědět bližší údaje o očekávané žátěži takového interního serveru.
      V praxi jsou MySQL servery nasazovány pro vnitrofiremní účely běžně na desktopové stroje. Jak ale říkám, je potřeba znnát bližší údaje o předpokládané zátěži, požadované odezvě a mnoha dalších faktorech.
      Každopádně ve firmě s řádově desítkami zaměstnanců si s tímto opravdu nemusíte asi lámat hlavu a můžete server nainstalovat na PC, které máte zrovna po ruce. Pokud výkon nebude dostačovat, upgradovat můžete vždy.
      Celkem aktualizované benchmarky naleznete například na stránkách http://www.cpubenchmark.net/

  5. Vitek

    SWAP IN, SWAP OUT

    Me ten clanek neprisel tak zly, pro laika lepsi nez nic
    u vmstat je swap je popsan obracene:
    si – počet bloků za sekundu swapovaných na disk,
    so – počet bloků za sekundu swapovaných z disku;
    tusim, ze je to naopak viz vypis:
    0 4 537244 2319624 11260 266960 497 0 1390 55 510 768 5 3 0 92
    0 6 536052 2310708 11528 268112 473 0 778 1415 527 476 2 4 2 93
    0 6 534892 2297220 11868 271784 454 0 1215 70 542 574 4 2 0 94

    1. Vitek

      Re: SWAP IN, SWAP OUT

      jeste zkusim pridat nazvy sloupcu..
      r b swpd free buff cache si so bi bo in cs us sy id wa st
      0 4 537244 2319­624 11260 266960 497 0 1390 55 510 768 5 3 0 92
      0 6 536052 2310­708 11528 268112 473 0 778 1415 527 476 2 4 2 93
      0 6 534892 2297­220 11868 271784 454 0 1215 70 542 574 4 2 0 94

  6. Polish

    tabulka RAID

    Tabulka RAIDu je trosku zvlastni. Rekl bych, ze RAID10 je pro databazi nejlepsi volba, ale take nejdrazsi. RAID5 a RAID6 maji super cteni, ale zapis byva slabsi. Slabsi zapis muze byt castecne eliminovan zalohovanou zapisovou kesi (+procesorem na pocitani parity). Slabsi zapis je zpusoben tim, ze pri zmene bloku je potreba nacist bloky ze vsech disku v RAID, vypocitat paritu a zapsat.

    1. m.

      Re: tabulka RAID

      ono to bude ovlivnovat hodne faktoru – typ pole (raid), disky (scsi, sas, sp, dp, rpm – 7200, 10k, 15k), cache (bateryback write-back), pripojeni – interni nebo san (2Gb, 4Gb, 8Gb), dalsi vykonnost ovlivnuje napr. virtualizace pole (napr. HP EVA) atd atd atd

Napsat komentář

Tato diskuse je již příliš stará, pravděpodobně již vám nikdo neodpoví. Pokud se chcete na něco zeptat, použijte diskusní server Devel.cz

Zdroj: https://www.zdrojak.cz/?p=3266