質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
MongoDB

MongoDBはオープンソースのドキュメント指向データベースの1つです。高性能で、多くのリトルエンディアンシステムを利用することができます。

SSH

SSH(Secure Shell)は、セキュアチャネルを通してデータを交換するためのネットワークプロトコルです。リモートサーバーへのコマンド実行やファイル転送を行う時に一般的に使用されます。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

Q&A

解決済

3回答

7806閲覧

AWSのEC2からの反応が遅い時の対応

aws

総合スコア48

MongoDB

MongoDBはオープンソースのドキュメント指向データベースの1つです。高性能で、多くのリトルエンディアンシステムを利用することができます。

SSH

SSH(Secure Shell)は、セキュアチャネルを通してデータを交換するためのネットワークプロトコルです。リモートサーバーへのコマンド実行やファイル転送を行う時に一般的に使用されます。

Ruby on Rails

Ruby on Railsは、オープンソースのWebアプリケーションフレームワークです。「同じことを繰り返さない」というRailsの基本理念のもと、他のフレームワークより少ないコードで簡単に開発できるよう設計されています。

AWS(Amazon Web Services)

Amazon Web Services (AWS)は、仮想空間を機軸とした、クラスター状のコンピュータ・ネットワーク・データベース・ストーレッジ・サポートツールをAWSというインフラから提供する商用サービスです。

0グッド

1クリップ

投稿2017/10/06 13:33

EC2のサーバの反応が遅い時はどこらへんを確認するなどすれば良でしょうか?

###状況
ここ数日サーバからの反応が悪くなります。(今回3回目なので対策を出来ればなーと。)
正確には完全に死んでいるわけではないのですが反応までに時間が掛かります。

例えばsshで接続するも接続出来るまでに約4-6分程必要になります。通常時は即アクセス出来ます。
その後logを確認しようとするもデータが返ってくる気配がありません。数メガのlogですので通常時は即確認出来ます。

上記状態でもAWSの管理画面上で見る限りCPUなどに負荷は掛かっていません。
インスタンスの状態も runningです。

過去2回はAWSの管理画面上で再起動を行っております。再起動が完了すると問題なくssh等やlog及びそのた諸々即アクセス出来ます。

###環境
amazon liunxを利用
t2.micro の無料枠にて運用中
nginxを利用
ruby on rails(puma) とmongodbを利用しています。
cronで定期的に簡単な処理を実行。
サイト自体のアクセスは100-200程度です。


その状態であればここを確認するとよい又はこの設定を行っておくと良いなど御座いましたらご指摘頂けると幸いです。

宜しくお願いします。

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答3

0

ベストアンサー

質問に記載頂いた挙動は、割当メモリを使い果たし空きメモリがない状況下で発生する可能性があるように思います。

標準のCloud Watchメトリクスではメモリの使用状況がわからないかと思いますので、下記ページやscsiさんの回答されている監視設定方法などを参考にメモリの使用状況を把握できるようにされると切り分けができるのかと思います。

AWS EC2でメモリ利用率をCloud Watchで監視する

メモリ使用量が原因なのであれば、メモリリークの可能性や、稼働させているサービスに対してインスタンスのスペックが不足している可能性があります。
OS再起動後、ある程度の期間は正常に動作するということであれば、定期的なOS再起動を行うことで事象発生する可能性を運用上回避できるかもしれません。

投稿2017/10/07 07:05

退会済みユーザー

退会済みユーザー

総合スコア0

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

aws

2017/10/07 08:44

有難う御座います。次回この様な状況になりましたらメモリなどの状況を確認させて頂きます。(今回も原因が分からない=>再起動させてしまえ。で逃げてしまいましたので。。。) そうですねー定期的な再起動で良いような気もするのですが出来ることならちゃんと解決したいといった気持もあります。
guest

0

数値を見ないと何とも言えませんが、メモリをほとんど使い尽くしてスラッシング(Swap In/Out 多発)が起きているのではないでしょうか?
例えば、vmstat 5 で 5秒間隔の値の変化を見て、以下を確認すると何かわかるかもしれません。

  • (メモリの空き、Swap 使用量) free が減って swpd が増えていないか
  • (Swap In/Out) si, so の値が大きくなっていないか
  • (Block In/Out) bi, bo の値が大きくなっていないか
  • (Disk I/O 待ち) cpu の wa の値が大きくなっていないか

あと、EC2 のマネージメントコンソールのモニターで、ネットワークトラフィックが上限に張り付いていないでしょうか。


(2017/10/07 15:14) 追記

すみません。
回答で「スラッシング」を疑いましたが、t2.micro だとそもそも Swap パーティションがなく、スラッシングは起きようがないかもしれません。

Disk I/O 待ちや、ネットワーク帯域飽和の可能性は残ります。

投稿2017/10/06 16:57

編集2017/10/07 06:14
TaichiYanagiya

総合スコア12141

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

aws

2017/10/07 08:36

詳細有難う御座います。AWSのEC2のモニタリングを見る限りではネットワークの負荷もそれほど高くないんですよね。 一応Swapも2G(2048)ほど作成しています。 サーバからの反応が悪い時にそのSwap領域がどの様になっているのか確認出来ていませんので次回確認したいと思います。
guest

0

t2.microのcpuクレジットを使い切っただけではないでしょうか

投稿2017/10/06 13:52

scsi

総合スコア2840

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

aws

2017/10/06 15:38

CPUは常に1%前後(時々20-40%になりますが一瞬)でしてCPU クレジット残高 (カウント)ですが常に100-120辺を推移しているといった感じです。 私が勘違いしているのかもしれませんがCPUに負荷が掛かるとCPUクレジットを消費して0に近づく感じですよね?
scsi

2017/10/06 19:25

そうですねえ。 処理が遅くなる原因は、cpu以外にもあります。 マカレルやzabbix、sysstatなどでリソース使用状況を取得し平常時との違いを調査してみて下さい。 再起動で治るのであれば、異常時にtopコマンドで原因がわかる可能性が高いと思います。
aws

2017/10/07 08:29

なるほどですねー今回も再起動させて無理やり?解決させたので次回Topなどで状況を確認してみます。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問