English
目的 OS コマンドによるボトルネック調査方法をまとめる。 CPU メモリ I/O ネットワーク 環境 OS: CentOS 5.5 Kernel: 2.6.18-194.el5 x86_64 CPU サーバ全体の CPU 使用率 CPU 使用率を確認する。使用率が 100% に近くなっている(= idle が 0% に近くなっている)とボトルネック。 top top では複数の論理 CPU がある場合もサーバ全体として 1 つに集約されて出力される。 $ top top - 07:23:36 up 45 days, 17:41, 2 users, load average: 7.22, 9.43, 8.03 Tasks: 223 total, 1 running, 222 sleeping, 0 stopped, 0 zombie Cpu(s): 7.1%us, 8.0%sy, 0.0%
Jupyter Notebookとは Jupyter NotebookはPythonによるデータ分析処理を対話式で行えるノートブックです。Jupyterのもっともな特徴は、このデータ処理をすべてWebブラウザー上で行える点です。つまり、Webブラウザー上でプログラムを作成し、実行し、結果を同じ画面に記録しながら分析作業を進めることができます。ターミナルやコマンドプロンプトよりも遥かにユーザーインターフェースがよく、いちいち画面の切り替えをする手間も省けます。なお、読み方は「ジュパイターノートブック」もしくは「ジュピターノートブック」のどちらでもよいそうです。 インストール DockerとTensorflowのインストールについては過去に記事を書いているので、ここでは省きます。以下に参考URLを貼り付けておきます。 http://qiita.com/Yuichi801/items/de6d3
超詳解!Service Worker Deep Dive ── HTML5 Conference 2016セッションレポート 保呂毅 はじめまして。GoogleでChromeの開発をしている保呂毅です。 Chromeの中では特にService Worker周りを担当してまして、最近はNavigation Preloadという新機能をがんばって実装しています。 先日開催されたHTML5 Conference 2016でService Worker周辺の最近(ここ1年くらい)の動向に関する発表をさせていただいきました。 今回は、この発表の内容を振り返りたいと思います。 Service Workerとは まず本題に入る前に簡単にService Workerの説明します。 Service Workerとはどういうものかと言いますと、 下のコードのようにnavigator.serviceWorker
こんにちは、Engineeringチームの石村(kamatama41)です。Engineeringチームの主な役割はインフラ構築や監視、パフォーマンス改善などのいわゆるDevOpsやSREと言われる領域になります。 Quipperでは現在グローバル向けであるQuipper (School, Video)と日本向けのスタディサプリという二つのプロダクトを運用しており、それらのプロダクトはAWS上に構築され、Terraformを使って構成管理をしています。そこで、私達がTerraformを運用するために工夫している点を紹介したいと思います。 Terraformとは? Vagrantなどを提供するHashiCorp社製のインフラ構成管理ツールで、AWSやGCPなどが提供している各種クラウドサービスをリソースという単位で構築、コード化出来るツールになります。 (AWSのEC2インスタンスを5台立ち
執筆上の都合でAmazonのほしい物リストをRSS化するAPIを作ってみました。構成的には、次のような形です。 下記のようなURLで取得できます。wishlist_idの部分に公開のほしい物リストのIDを指定したら使えると思います。 https://wishlist-api.takuros.net/prod?wishlist_id=3G4653SB32HMZ ※効果計測の意味を兼ねて、アフィリエイトタグを付けています。 構成上のポイント ほしい物リストからNode.jsのLambdaでスクレイプして、リスト内のタイトルとURL・登録日を取得しています。また次のページがある場合は、再帰的に取得できるようにしています。出力は、RSS 2.0形式のXMLで出力しています。それをAPI Gatewayを利用してHTTPSからキックできるようにしています。CloudFrontとAWS Certifi
GO言語は最近触りだしたばかりでちんぷんかんぷんですが、パッケージ管理機能のglide(グライド)を使った時に、全然ビルド出来なくて困った話をします。 解決策は、実際にGOを使っているエンジニアに聞いたので間違いない(はず)です! はじめに 世の中には既にglideについて書かれた素晴らしい記事はたくさんあります。そもそもglideって何?という方はこちらの記事を読んでください。 glide – パッケージ管理のお困りの方へ – – Qiita MacにGo言語の開発環境を構築する【準備編】 (direnv+go1.5Vendoring+glide) こちらの記事で、glideを使ったvenderingがうまくいった方は、この先を読まなくて大丈夫です。 僕は無理でしたけどね! というわけで、Go大して知らない。でも、せっかくやるならパッケージ管理は使いたいというわがままな人に向けて解決策で
10月21日(金)に、JX通信社内での勉強会でDockerfileを生産性高く書く方法のLTをした。 この3ヶ月で、公開しているものだけでも8個ぐらいDockerイメージを作ったらしいw ↑のスライドの要旨を言うと、 Dockerfileを書くときはTmuxとSlimeを活用しましょう!ということ。 Dockerfileを書くとき、「全部書く」→「docker build」→「修正」→「docker build」→「修正」→「docker build」みたいなことをやってると、かなり生産性が悪い。処理の途中でエラーが起きたりするし、apt-getしないといけないものが後から出てきたりする。その度に docker build していると、時間がかかってしまう。 そこで、tmuxとslimeを活用して、Dockerfileを一行ごとに検証していくと良いですよという話。 Tmuxは、Screen
はじめに 開発を進める上で、「作っては壊すことのできる環境」というのは色々なことを試したい時などに重宝します。Dockerを使うことでそのような環境を簡単に構築できます。 今回はMongoDBを例にDockerを利用した開発環境の構築方法の説明をします。 手順についてはMacやWindowsなどの非Linux環境でDocker Machineを利用しているという前提で説明をしていきます。(Docker Machineのインストール方法については省略しております。) UbuntuなどのLinux環境を利用しており、ローカル環境にDockerがインストールされている場合は適宜必要な部分だけ読んでいただければと思います。 なお、今回作成したテストレコードを利用したMongoDBのクエリ操作のまとめについてはこちらのこんな時どうする? MongoDBクエリ操作逆引きリファレンスにまとめておきました
引用:Docker run リファレンス ここでは--memory-reservationと--oom-kill-disable=false、--memory-swappinessについて調べました。 環境 OSX 10.12 Docker for MAC(docker 1.12.1) --memory-reservation メモリのソフトリミットということで、ホストのメモリに余裕がある時はは制限はかからず、他に使用している時は制限がかかるということらしい。 試してみました。 コンテナ2つ起動し、1つは--memory-reservationを512MB、もうひとつは制限なしで設定します。Linuxの負荷ツールstressで以下のシナリオでメモリに負荷をかけます。 前提:ホストのメモリは2GB 1. 両方のコンテナに1.25GBの負荷をかける 2. メモリ制限のないコンテナへの負荷を停止
2020/05/26 追記 Docker for Mac の Mutagen-based caching で Volume のパフォーマンスが劇的に改善した Mutagen単独で試してみたことがあって、すごく速くてよかったんですが、 Docker for macに統合されそうな感じになってるんですね。 これは期待。 2017/3/15 追記 先日この問題のissueに対して、 というコメントがつけられ、それに関する というプルリクが 本体にマージされたようです。 まだ詳しく見ていませんが、マウント時に同期方法オプションが指定できるようになり、そのオプションによってキャッシュするレベルを制御して同期を軽くしよう、というような感じになるようでした。 実際にリリース版で使えるのはいつなのかわかりませんが、やはり本体が早くなるのが一番いいのでちょっと期待ですね。 ========== 追記ここまで
みなさん、Elastic Beanstalkって使ってますか? なんか設定する項目が多くて「もう普通にEC2立てた方が楽だわ」ってなる方が多いかと思いますが(多いですよね...?私はそうだったのですが...)、使ってみると後々の管理が超絶楽になるので、 ナウい構成のサンプルアプリを構築する手順を公開することで広めたいと思った次第です。 はじめに そもそもナウい構成って何よ? あくまで主観ですが、イメージ的にはこんな感じ ロードバランサーの下にEC2をぶら下げて、アプリ自体はDockerコンテナで稼働させ、nginxにリバースプロキシさせるという実にナウい構成です。 ロードバランサーはせっかくなのでApplication Load Balancerを使いたいですね。web socketにも対応してるし、パスでルーティングできるというナウいロードバランサーです。 DB無いとかどういうことやねん
You are reading the 2024 edition of the Flask Mega-Tutorial. The complete course is also available to order in e-book and paperback formats from Amazon. Thank you for your support! If you are looking for the 2018 edition of this course, you can find it here. For your reference, here is the complete list of articles in this series: Chapter 1: Hello, World! (this article) Chapter 2: Templates Chapte
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く