Názory k článku
Upgradujeme MySQL server

„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.

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!

Č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í.

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

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?

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

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

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.

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

nemate tuseni, proc intel deli prociky pro small businesess na servery a datacentra a desktopy, pricemz kdyz je porovnate

http://www.czechcomputer.cz/product.jsp?artno=79307
http://www.czechcomputer.cz/product.jsp?artno=58003

tak jsou vpodstate stejny ? Je tam naky rozdil v necem ?