wa (Čekání na I/O) z horního příkazu je velký

Řešení 1:

Zde je několik nástrojů pro zjištění aktivity disku:

• iotop
• vmstat 1
• iostat 1
• lsof
• strace -e trace=open <application>
• strace -e trace=open -p <pid>

V ps auxf také uvidíte, které procesy jsou v neinterpretovatelném režimu spánku disku (D ), protože čekají na I/O.

Některé dny se zatížení zvýší na 40 bez zvýšení počtu návštěvníků.

Můžete také chtít vytvořit zálohu a zjistit, zda pevný disk pomalu selhává. Pevný disk se obecně začne zpomalovat dříve, než zanikne. To by také mohlo vysvětlit vysokou zátěž.

Řešení 2:

Výstup shora naznačuje, že DBMS zažívá většinu I/O čekání, takže problémy s laděním databáze jsou zřejmým kandidátem na prošetření.

I/O čekání na databázovém serveru – zejména při špičkách zatížení – je vodítkem, že váš DBMS může být buď vázán na disk (tj. potřebujete rychlejší diskový subsystém), nebo může mít problém s laděním. Pravděpodobně byste se také měli podívat na profilování databázového serveru – tj. získat přehled o tom, co dělá a jaké dotazy zabírají čas.

Některé počáteční body pro diagnostiku problémů s laděním databáze:-

• Najděte dotazy, které zabírají nejvíce času, a podívejte se na plány dotazů. Zjistěte, zda některá z nich nemá zvláštní plány dotazů, jako je skenování tabulky tam, kde by neměla být. Možná databáze potřebuje přidat index.

• Dlouhé čekací doby zdrojů mohou znamenat, že je třeba rozšířit některé klíčové zdroje zdrojů.

• Dlouhé I/O čekací doby mohou znamenat, že potřebujete rychlejší diskový subsystém.

• Jsou vaše svazky protokolů a dat na samostatných discích? Databázové protokoly mají mnoho malých sekvenčních zápisů (v podstatě se chovají jako kruhová vyrovnávací paměť). Pokud máte zaneprázdněnou pracovní zátěž s náhodným přístupem a sdílíte stejné disky jako vaše protokoly, neúměrně to ovlivní propustnost protokolování. Aby byla databázová transakce potvrzena, musí být záznamy protokolu zapsány na disk, takže to bude překážkou pro celý systém.
  
  Všimněte si, že některá úložiště MySQL nepoužívají protokoly, takže ve vašem případě to nemusí být problém.

Poznámka:Systémy řazení

Systémy řazení do fronty (statistický model pro propustnost) se hyperbolicky zpomalují, když se systém blíží saturaci. Pro aproximaci vysoké úrovně má systém, který je z 50 % nasycen, průměrnou délku fronty 2. Systém, který je nasycený z 90 % má délku fronty 10, systém, který je nasycený z 99 %, má délku fronty 100.

V systému, který se blíží saturaci, mohou tedy malé změny v zátěži vést k velkým změnám čekacích dob, v tomto případě se projevující jako čas strávený čekáním na I/O. Pokud je I/O kapacita vašeho diskového subsystému téměř nasycená, pak malé změny v zátěži mohou vést k významným změnám v dobách odezvy.

Řešení 3:

Spusťte iotop nebo atop -dD , abyste viděli, jaké procesy dělají io. Použijte strace pokud se potřebujete podívat blíže.