pythonの軽量framework, Bottle - QiitaDeleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article?
6.3.1 ワイルドカードと正規表現
名前に基づくバーチャルサーバにおいて、名前はワイルドカード(*) や 正規表現によって表現することが出来るので、その優先順位がやはり問題と なります。 まず、ワイルドカードと正規表現の例を見て見ましょう。
Linuxサーバにログインしたらいつもやっているオペレーション - ゆううきブログ
主にアプリケーション開発者向けに、Linuxサーバ上の問題を調査するために、ウェブオペレーションエンジニアとして日常的にやっていることを紹介します。 とりあえず調べたことを羅列しているのではなく、本当に自分が現場で使っているものだけに情報を絞っています。 普段使っているけれども、アプリケーション開発者向きではないものはあえて省いています。 MySQLやNginxなど、個別のミドルウェアに限定したノウハウについては書いていません。 ログインしたらまず確認すること 他にログインしている人がいるか確認（w） サーバの稼働時間の確認 (uptime) プロセスツリーをみる (ps) NICやIPアドレスの確認 (ip) ファイルシステムの確認（df） 負荷状況確認 top iostat netstat / ss ログ調査 /var/log/messages or /var/log/syslog /
dstat2graphs - dstatのログをグラフ化するツール - SH2の日記
dstatが便利ですね。 dstat が便利 | Carpe Diem dstatの万能感がハンパない - (ひ)メモ 私は特に--outputオプションでCSV形式のログファイルを出力できるところが気に入っています。本番環境ではきちんとした監視ツールを使うと思いますが、開発・検証環境で手早くOSリソース情報を可視化できるので重宝しています。 それでもExcelやCalcでグラフを描くというのは何度も繰り返すと面倒なもので、 探したのですが見つからなかったので、連休を利用して作ってみました。 dstat2graphs - dbstudy.info サンプル1 (前回の負荷テストにおけるクライアントのグラフ) サンプル2 (サーバ) サンプル3 (KVMホスト) いくつか注意点があります。 dstat -tvfn --output log.csv 1しか受け付けないという割り切った作りです。
はてなブログ | 無料ブログを作成しよう
令和五年六月 コンデジの写真など 梅雨がどこかに行ってくれたようで嬉しい。水不足にはなってほしくはないけれど、たまにはカラッとした年があっても良いよな。今月は忙しくてあっという間に終わってしまった。いつもより今月は何をしていたっけ、なんて感覚が強い状態。スマホの中の写真やラインのや…
unicornのタイムアウト時にもRailsのログをちゃんと出力させる - 昼メシ物語
unicornはconfで timeout 20 とかやっとくと、20秒以上かかったらそのworkerが殺される。それはいい。問題はその殺され方にあって、タイムアウトしたunicorn workerはmasterにKILLシグナルで強制的に殺される。KILLで殺されてしまうと、worker側でtrapして安全に終了処理をすることができない。 一番困るのは、Railsのloggerは（production環境のデフォルトだと）リクエストが終了するまでバッファリングしているので、リクエストの途中でKILLされてしまうとloggerがflushされない。つまり、unicornのタイムアウト時には、リクエストのログは一切production.logには出力されない。異常時のログが出ないとか、まじで困ると思うんだけど、みんなどうしてんだろ。 これに対処するためにはunicornのコードに手を入れるの
ITインフラで起きる「もしも」のための12個のコマンド
こんにちは。斎藤です。 ITインフラの障害は、多くの場合「予期せぬ」タイミングで発生します。特に、CPUリソースを多量に消費したり、Disk I/Oが輻輳している場合、その切り分けは困難な状況に陥りやすいものです。 そこで、本日はITインフラ、特にOS・ミドルウェアを支えるにあたって、問題解決を助けてくれるであろう12個のコマンドを取り上げてみます。「必ず押さえておきたい」5つのものと「更に覚えると便利なコマンド」7つの2節に分けてお話しします。 ※CentOS 6.4 (64bit)を前提に取り上げます 必ず押さえておきたいコマンド もしITインフラ管理者になりたてな方はぜひ サーバサイドのプログラマをやっていたのだけれど、ある日突然「君、サーバ管理担当ね！」と、バトンを渡される方っていらっしゃると思います。私も以前はそのクチでした...。そうなってしまったとき、まずは覚えておきたい5つ
アプリエンジニア向け：「サーバがなんか重い」時にすること - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? アプリケーションエンジニアの人には「なんか重い」という状況に遭遇したらインフラの人にタスクを投げる、という人もいるかも知れません。けど、その重さのどこに原因があるのか。CPUか、ネットワークか、IOかくらいの診断はできた方がアプリ開発においても有益です。 「せっかくつくったシステムがなんか重い」 そんな時にアプリケーションエンジニアとしてできることを書きます。 本職のインフラの人にはぬるい内容だと思います。何を隠そう僕自身がアプリ寄りの人間なので、突っ込んだ話はできないのです。あしからずご了承ください。 なんかサーバが重いなー まずはロ
徒然さめざめ rails と connection pool とついでに スレッド と
rails2.2以降に connection pool が組み込まれたわけだが、 いまいちどこにも関係性を示した情報がない。 というかスレッド使用時にpoolが枯渇してしまうという問題がでた。 なので、がっつり調べてみた。 実態は以下のファイルなので /usr/lib/ruby/gems/1.8/gems/activerecord-2.3.4/lib/active_record/connection_adapters/abstract/connection_pool.rb これに標準出力するものをいれて確認してみた。 @@ -64,6 +64,7 @@ # # The default ConnectionPool maximum size is 5. def initialize(spec) + pp caller @spec = spec # The cache of reserved
【Rails 4.1】APサーバー環境構築［Mac OS X 10.9.2 Marverick］ - 株式会社へんてこらぼ
こんにちは、代表の平野です。 Ruby on Rails 初心者向けに、Mac OS X 10.9.2 Marverick 環境での、AP（アプリケーション）サーバーの構築手順をまとめました。 ※本記事は、ベンチマークを取る目的で調べた内容です。もしも記述内容に誤りがありましたら、お気軽にご指摘ください。 INDEX 動作環境 STEP.1 雛形となるRailsアプリケーションを作成 STEP.2 各種APサーバーの環境構築 2-1. WEBrick 2-2. Thin 2-3. Puma 2-4. Unicorn 2-5. Rainbows! 2-6. Phusion Passenger STEP.3 各APサーバーの特徴の比較 動作環境 Mac OS X 10.9.2 Homebrew 0.9.5 ruby 2.1.1p76 Rails 4.1.0 gem 2.2.2 thin 1.6
[Rails] APサーバの比較検証（Puma, Unicorn, Passenger） - Tech Log - s21g
仕事でRailsを使うことになり、APサーバの選定にあたってPuma, Unicorn, Passenger の比較検討を行いました。方法としてはJMeterでAPサーバにデプロイしたRailsアプリケーションに対して負荷をかけられるだけかけるというやり方です。 試験環境 試験の環境としては下記の構成です。 Ruby2.0, Rails4 アプリケーションサーバ：1台（VM） JMeterサーバ：3台（VM） JMeterクライアント：1台（通常の作業PC） サーバ構成 hostanameCPU仮想コア数（Per CPU）MemoryDisk用途 loadtest01248192MB20GBAPサーバ loadtest02114096MB20GBJMeterサーバ loadtest03114096MB20GBJMeterサーバ loadtest04114096MB20GBJMeterサーバ
Heartbleed脆弱性と、その背後にあるWebアプリケーションアーキテクチャの一般的欠陥について
■Heartbleedのリスクと善後策 Heartbleedは、攻撃者が一定の条件を満たすOpenSSLが動作しているサーバの、任意位置のメモリを外部から読み出すことができてしまうという脆弱性です。具体的には、以下のようなリスクが想定されています。 秘密鍵の漏洩による、偽サイトの出現（あるいは中間者攻撃） 秘密鍵の漏洩により、（過去のものを含む）パケットキャプチャの解読 サーバの同一プロセスが行った処理に関連する（他のユーザーのパスワードやセッションキーを含む）データの漏洩 漏洩した秘密鍵を用いた攻撃には、ユーザーを偽サイトへ誘導できたり、パケットの経由点を管理しているなどの、経路上の要件が必要になります。他のユーザーのデータの漏洩については、経路上の要件は不要な一方、攻撃の実施に近いタイミングでサーバにアクセスしたユーザーのデータしか漏れない、という違いがあります。 どこまで対策を施すべ
Docker Meetup Tokyo #2 まとめ #dockerjp - /dev/null
Docker Meetup Tokyo #2 に行ってきました。 Docker Meetup Tokyo #2 - connpass #1は行ってないですしDocker自体、全然触れてないですが先着入れたので。 メインの発表は３本。 @mainyaaさんの「今からでも間に合うDocker基礎+Docker 0.9概要+Docker 0.10概要 」 Docker基礎+docker0.9 0.10概要 from Kazuyuki Mori Dockerの基礎から説明してくれていたので、Noobな自分でも大体の概要はわかった感じ。 VagrantでVM立てるのと違うんだなーってのがわかっただけでも大収穫。 AUFSでレイヤー構造になってるってのが理解しておくのが大事。省メモリだしディスクも取らない差分だけだから。 途中のデモで使ったこのサービスが最高な感じあった。 ターミナルの録画 ascii
エンジニアなら知っておきたい障害報告&再発防止策の考え方 - Qiita
Deleted articles cannot be recovered. Draft of this article would be also deleted. Are you sure you want to delete this article? システムには障害がつきものです。どんなにしっかりと作られたサービスであっても思わぬところで、バグやミスが発覚して、トラブルになるものです。大事なのはこういった障害を次への糧にしていくこと。失敗というのは大事な資産なので、管理できるようにしましょうという話。 あわせて読みたい あきらめるにはまだ早い！ソースコードの品質向上に効果的なアプローチ メンタリングの方法について基礎をまとめました。内心でなく行動を変えることが障害報告とも共通します。 新入社員が来てメンターになれって言われたけど、どうすればいいのかという対話テクニック 半年で40k
なぜ Forkwell は初日にサーバダウンを繰り返したのか解 目明し編 - 表参道フォークウヱル別館
こんにちは。Forkwell の中の人、大岡（おおか）です。前回の記事「なぜ Forkwell はリリース初日にサーバダウンを繰り返したのか」の反響が大きく、一時はホッテントリに入るほどで正直驚きました。 Twitter や ブックマークコメント でご意見も多くいただいたので、今回はそれに対するフォローの記事を書きたいと思います。 一番多かったご意見は、 本当に Unicorn が悪かったのか。worker_proccesses の設定値が小さすぎただけじゃないのか。 ちゃんと原因究明してないのに、Unicorn を悪者にするのは Unicorn がかわいそうです(´；ω；`) といったものでした。 500エラーが頻発し出した午前11時すぎから、Passenger への入れ替えを決断した午後5時くらいまでの約6時間、私たちが行っていたのは Webサーバ、アプリケーションサーバ、DBサーバの
2013年の新卒研修と社内ISUCONやりました - (2) ISUCON死闘編 - KAYAC Engineers' Blog
技術部新卒研修担当の fujiwara です。 前回の記事「2013年の新卒研修と社内ISUCONやりました - (1) 研修編」に引き続き、新卒研修の最後を飾るイベント、社内ISUCONについて詳しく振り返ります。 社内ISUCONとは レギュレーションはこちらです。 各チーム1台ずつ使用できる仮想マシン上で、お題のアプリケーションを動作させる 外部からベンチマークを行って処理できたリクエスト数をスコアとする アプリケーション、OS、ミドルウェアなど、どのようなチューニングを行ってもよい ベンチマークスクリプトはデータの整合性をチェックするロジックが組み込まれており、アプリケーションとして不整合を起こしていることを検出するとFAIL(スコアなし) 10:00〜17:00 までの作業中には適宜ベンチマークを実行できる 作業終了後の最終計測でのスコアが高いものが優勝 (FAILしたら失格。1
ウェブオペレーションエンジニアはリリース前のソースコードのココを見ているッ！ - blog.nomadscafe.jp
「ウェブオペレーションエンジニアはリリース前のソースコードのココを見る！」みたいな記事があればいいね — masahiro nagano (@kazeburo) November 20, 2012 ちょいと前にツイートしたこの件のまとめ。新規サービスのリリースや既存サービスに新しい機能が追加される際に、しばしばそのソースコードを確認しているのですが、僕がどんなところを見ているのかまとめてみました。 そのサービスへの導線とランディングページの確認 まず、そのサービスへの導線やランディングページを確認します。そしてその一番アクセスがあろうページ、一つか二つに確認対象を絞ります — masahiro nagano (@kazeburo) November 20, 2012 どんな素敵なサービスも、機能も適切な誘導がなければ使われる事はありません。また誘導次第では大量のアクセスが一度にサーバに対し
supervisord - holly's wiki
holly's wiki hollyさんのwiki トップページページ一覧メンバー掲示板編集 × supervisord 最終更新： kurt0027 2012年08月16日(木) 00:07:12履歴 Tweet daemontoolsとかmonitっぽいやつ http://supervisord.org/. centosでの導入手順。ここが詳しい。http://webos-goodies.jp/archives/deploying_tornado... 事前準備 なければ実行すること yum install python-setuptools install easy_instalでインストール。pythonだが、rootで動かすようなものなので、わざわざpythonbrewいれたりする必要はない。めんどいし easy_install supervisor 設定ファイル 雛形から作成す
原因調査用Linuxコマンド | 外道父の匠
サーバの動作に異常が発生した際に原因を探るためのLinuxコマンドで、自分用のメモです。 全てmanとかググったら出てくるので説明は適当です。思いついたら後で追記していくかもです。 対象はDebian Squeezeになります。 全てパッケージインストールできるもので、パッケージ名は [in packagename] としてあります。 各所よりコメントありがとうございます。 良さ気なコマンドは追記していきます。 ＜追加したコマンド＞ * telnet (+コメント wget, netcat) * arp (+コメント arpwatch) * pstree * fdisk コメントに gdisk * host, dig * watch * reboot
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
tcpdump コマンドの使いかたをまとめてみた : sonots:blog
