EBSボリュームがマウントされたマイクロインスタンスがあります。 EBSボリュームへの100万回の読み取り/書き込みごとに支払う必要があります。
しかし、EBSの性質上、I/Oは非常に遅く、その結果、MySqlのようなサービスは遅くなります。
誰かが私のインスタンスを高速化する方法を提案できますか(マイクロインスタンスはそのような用途ではないという明白なコメントを除いて)?
私の経験では、その人気に基づいて、EBSボリュームはほとんどのアプリケーション(MySQLを含む)で遅くはありません。特に、IO帯域幅が高いEC2インスタンスを使用している場合はそうです。
T1.microインスタンスの帯域幅は「低」IOですが、実際にパフォーマンスの問題が発生しているのではないかと思います。これが問題であることを示すiowaitの指標はありますか?
T1.microインスタンスタイプは、アプリケーションで必要となる可能性のあるような重いCPUアクティビティを維持できない可能性が高いと思われます。
MySQL/Apache/etcでt1.microを使用しています。ユーザーがほとんどいない動的なWebサイトの場合、正常に機能しますが、何らかの持続的な負荷をかけるとすぐに、設計どおりにカットされます。
T1.microのメモリサイズが小さいため、MySQLはデータベーステーブルの多くをメモリにキャッシュできないため、結果を得るためにディスクに移動し続ける必要があることに気付く可能性があります。これは、EBS IOがどれほど高速であっても問題になります。これは、ダイレクトメモリアクセスほど高速になることはないためです。
それでもEBSの問題だと思われる場合は、MySQLデータベースへのヒットを減らすために、キャッシュレイヤーを追加してみてください。ただし、t1.microのメモリ制限にすぐに遭遇します。おそらく、AWSの新しいElastiCacheサービスを見てください: http://aws.Amazon.com/elasticache/
T1.micro IOが制限要因である場合、RAID内のすべてのEBSボリュームが同じIOチャネルを一緒に使用するため、RAIDで修正することはありません。
通常、人々は4〜10個のEBSボリュームをマウントし、それらを一緒にRAIDすることによって、EBSの速度と信頼性の問題を回避します。より一貫したパフォーマンスとパフォーマンスの向上を実現します。
Pinterestの人からのスライドを見てください(2015): https://www.percona.com/live/mysql-conference-2015/sites/default/files/slides/all_your_iops_are_belong_to_usPLMCE2015.pdf
カーネル3.13 + EXT4
4K RAIDブロック、EXT4、カーネル3.13書き込みスループット87MB /秒99パーセンタイルレイテンシ:124ms
64K RAIDブロック、EXT4、カーネル3.13書き込みスループット88MB /秒99パーセンタイルレイテンシ:122ms
カーネル3.18 + XFS
4K RAIDブロック、XFS、カーネル3.18書き込みスループット550MB /秒99パーセンタイルレイテンシ:3.7ms
64K RAIDブロック、XFS、カーネル3.18書き込みスループット650MB /秒99パーセンタイルレイテンシ:6.2ms