※2014/07/02 T2インスタンスタイプとの比較 を追記しました。 ※2014/03/13 他インスタンスタイプとの比較／m3.mediumの検証 を追記しました。 こちらの記事の二番煎じです。 cgroupで、お手軽CPU使用率制限 なるほど。 リソースにLimitかけるとstealを防げるためパフォーマンスも上がるというわけですね。 どのくらい変わるのか実験してみました。 cgroup前準備 sudo yum install libcgroup sudo chkconfig cgconfig on sudo service cgconfig start cgroup設定 上記参考URLとほぼ同じ設定です。 実行時はcpu.cfs_quota_usを変動させて比較してみました。 sudo vi /etc/cgconfig.conf # 以下を追加 group limittest {
歴史のあるクラウドサービスは、どこもそうなってしまう傾向があるとは思いますが、ホストサーバでの実CPUのアーキテクチャ・世代の違いで、サーバインスタンスのCPUパフォーマンスに微妙な差がついてしまいます。 2006年よりサービス提供しているAmazon EC2でもその傾向があることは割と知られていて、同じ性能だと思って並べて使っていたサーバインスタンスが、同じ処理量にもかかわらず使っているCPUリソースに差がついている、なんてことが起こります。 con_mameさんも、以下のエントリで書かれていますね。 EC2で同じECUだけどCPUは違う - まめ畑 昔は、us-eastでm1.smallのインスタンスをよく使ったもので、その頃はいつもAMDのOpteronプロセッサでしたが、最近では、ほとんどIntel Xeonですし。 ということで、現時点(2013/10)で、EC2インスタンスで使
AmazonクラウドがRuby対応、Elastic Beanstalkで。Java、PHP、Python、.NET、Ruby環境が揃う
Elastic BeanstalkこれまでJava、PHP、.NETをサポートしてきており、今年の8月にはPythonのサポートが加わっていました。 2011年1月にElastic Beanstalkが初めて発表されたとき、最初にサポートされた言語はJavaでしたが、Ruby 対応を進めていることが当時のプレスリリースに明記されていました。それがようやく実現したことになります。 Elastic Beanstalkは無料で利用できるサービスで、必要な費用は使用したAmazon EC2などのインフラ利用料のみ。アプリケーションの実行環境を簡単に提供してくれるだけでなくオートスケーリング機能などの運用環境まで提供してくれます。 仮想プライベートクラウドでElastic Beanstalkを実現 今回の発表に合わせて、Elastic Beanstalkの環境をVirtual Private Clo
クラウドを使っていたら、こんなことがありました。(実話) Amazon EC2用の固定IPアドレス(Elastic IP Address)を取得する Amazon EC2でサーバ(インスタンス)を起動する 先ほど取得した固定IPアドレスを、EC2のサーバに割り当てる EC2のサーバでApacheを起動する Apacheのプロセス数がいきなり250個オーバーになる(MaxClientsの値にぶつかる) Apacheのログを見ると、常識を超えた連続HTTPアクセス(DoSアタック)を受けていることが判明 EC2で、別の固定IPアドレスを取得する 取得した別の固定IPアドレスを、(アタックを受けている)EC2のサーバに割り当てなおす 静けさを取り戻す ← imkk いやー、噂には聞いていましたが、何気に初めて遭遇しました。 クラウドサービス(IaaS等)では、別のユーザが以前に利用していたIPア
［速報］ついにきた！ Amazonクラウドの東京データセンターが稼働開始
Amazonクラウドは3月2日23時、日本でのデータセンター「東京リージョン」の開設を発表しました。東京リージョンはすでに稼働を開始しており、現時点で利用可能になっています。 東京リージョンの利用価格はLinux/UNIXのスモールインスタンスで1時間あたり0.10ドル。ラージインスタンスで1時間あたり0.40ドルなど。今後数カ月の間に、決済に日本円を選択できるよう準備中とのこと。 Publickeyはすでに利用を開始している一部のパートナーの発言を聞く機会があり、「東京リージョンを試したところレイテンシは数ミリセカンドと、国内のほかのデータセンターと全く変わらない」と、国内データセンターならではのレスポンスを確認する発言を聞けました。 日本円での課金は数カ月以内、日本語でのテクニカルサポート開始 東京リージョンでもAmazonクラウドの主な機能はほとんど利用可能。ただしHadoopの機能
AWS Week in Review – AWS Documentation Updates, Amazon EventBridge is Faster, and More – May 22, 2023 Here are your AWS updates from the previous 7 days. Last week I was in Turin, Italy for CloudConf, a conference I’ve had the pleasure to participate in for the last 10 years. AWS Hero Anahit Pogosova was also there sharing a few serverless tips in front of a full house. Here’s a picture I […] Amaz
大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。 ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。 また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。 ここを解明すべく、各種ベンチマークを実行し
Amazon EC2で起動した仮想サーバ(インスタンス)では、サーバの内部から、そのサーバ自身の各種メタデータ(MetaData)を取得することが出来ます。 自前でAMIをカスタマイズする際、インスタンスの起動時に割り振られる(確定する)データ(例えば、IPアドレスとかインスタンスIDとか。)については、事前に扱いを決めることは難しいかと思います。 例えば、インスタンスIDをサーバ自身が判別できることで、サーバ起動のタイミングや、サーバ稼働中に、Amazon EBSボリュームを(自動で)自分自身に割り当てられたり等もできたりします。 また、余談ですが、Amazon EC2では、ユーザがインスタンスの起動時に任意のデータ(UserData)をインスタンスに渡すことができ、そのデータをインスタンスの中で扱うことも可能です。 この場合も、以下で紹介するやり方で、メタデータだけではなく、ユーザデー
MySQLに自動フェイルオーバー機能を追加したAmazonクラウド。オンラインのままパッチ当てやバックアップも
MySQLに自動フェイルオーバー機能を追加したAmazonクラウド。オンラインのままパッチ当てやバックアップも クラウド上でMySQLの運用を行うサービス「Amazon Relational Database Service」（Amazon RDS）を提供していたAmazonクラウドは、Amazon RDSに自動フェイルオーバーによる可用性を実現したオプション「Multi-AZ Deployments」を追加したと、ブログ「Amazon RDS - Multi-AZ Deployments For Enhanced Availability & Reliability」で明らかにしました。 データベースの計画停止がなくなる これまでのAmazon RDSは、MySQLがあらかじめインストール済みですぐに利用できると同時に、MySQLにパッチを当て最新に保つとともに、バックアップもしてくれる
Amazonクラウド、5月に入って3回もトラブル発生。UPSの故障、分電盤のショート、ネットワーク接続エラー
Amazonクラウド、5月に入って3回もトラブル発生。UPSの故障、分電盤のショート、ネットワーク接続エラー Amazonクラウドの北アメリカサイトでトラブルが続いています。今月に入って3回もトラブルが発生しているのです。 今月最初のトラブルは5月4日午前2時（現地時間）。データセンターの電源関係の作業中にトラブルが発生。切り替わるはずのUPS電源がうまく働かず、データセンター内アベイラビリティゾーンの一部のラックに対して電源供給が停止しました。その後、技術者がUPSを迂回して直接電源を供給することで復旧が始まり、午前3時40分から6時35分のあいだに復旧しています。 2度目のトラブルは5月8日午前0時20分。ふたたびアベイラビリティゾーンの一部のラックに対して電源トラブルが発生。トラブルは長時間に及び、午前7時20分頃に復旧開始。原因は主分電盤の漏電とショートで、復旧前に分電盤の修理とテ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
