高速WebサーバMighttpdのアーキテクチャ | IIJの技術 | インターネットイニシアティブ（IIJ）
IIJ-II技術研究所では、2009年の秋からMighttpd（mightyと読む）というWebサーバの開発を始め、オープンソースとして公開しています。この実装を通じて、マルチコアの性能を引き出しつつ、コードの簡潔性を保てるアーキテクチャにたどり着きました。ここでは、各アーキテクチャについて順を追って説明します。 ネイティブ・スレッド 伝統的なサーバは、スレッド・プログラミングという手法を用いています。このアーキテクチャでは、1つのコネクションを1つのプロセスかネイティブ・スレッドが処理します。 このアーキテクチャは、プロセスやネイティブ・スレッドを生成する方法で細分化できます。「プール」方式では、あらかじめ複数を起動しておきます。例としては、Apacheのpreforkというモードが挙げられます。「都度」方式では、コネクションを受け取るたびに生成します。このアーキテクチャの利点は、制御を
Dockerとchrootを組み合わせたシンプルなコンテナデプロイツール - ゆううきブログ
この記事ははてなエンジニアアドベントカレンダー2015の1日目です。今回は、既存の運用フローに乗せやすいDockerイメージへのchrootによるデプロイの考え方と自作のコンセプトツール droot を紹介します。 github.com 背景 Docker 本番導入の課題 Docker 導入の目的 Docker + chroot のアイデア droot: Dockerイメージにchrootするコンテナツール droot の使い方 droot push: Dockerイメージをtar ball化しS3にpushする droot pull: S3にpushしたイメージをダウンロードし展開する droot run: 展開先のディレクトリにchrootする droot の実装 droot push/pull の実装 droot run の実装 あわせて読みたい あとがき 背景 Dockerがリリー
カジュアルに鯖を監視するNewRelic をAmazon Linux に導入 - aws memo
今っぽい感じのSaaS型監視サービス NewRelicを Amazon Linuxに入れてみる。( Newvem とか Server DensityとかPingdomとかもある） New Relic は、エージェントを監視対象ノードに入れておく点は Zabbix等と変わらないが、監視サーバを構築しないですぐに(無料で)始められる、という点がメリット。 監視対象サーバが少ないシステムだと、監視サーバのコスト・運用負荷がデメリットになるので、CloudWatchを補助する目的で、CloudWatchで取れない Load Average, free memory, Disk UsageといったOS内部の情報をカジュアルに一元管理するのに向いている。 特徴を説明したページはこちら。 Server Monitoring Application Monitoring Real User Monitor
今後の負荷を RRDTool を使って予測してみよう
斎藤です。 今日は、RRDToolを使って、今後かかる負荷を手軽に予測する方法をご紹介します。あわせて、プログラムと連携して性能限界を越えそうなサーバがあるかを判定してみます。人手ではまかないきれない数のサーバに対して、一台ずつ問題の予兆を調べるときなどにお試しください。 ※CentOS 6.3 (64bit) + RRDTool の2013/2/20頃の最新ソースを用いて試しています 「限界」を早く知りたい！ ITインフラを運用している方の多くは、Cacti, Munin等で負荷を日々モニタリングされているかと思います。モニタリングしたデータを用いて今後を予測する際、どのようにされていらっしゃいますでしょうか？描かれたチャートの動きをもとに、経験と勘を駆使して「ヨイショ！」っとされている方も、いらっしゃるのではないでしょうか。 特に、ディスク容量やネットワークトラフィック等、根本的な対策
今もっとも学習コスパの高い技術はChefだと、Chef勉強会に行って確信した : akiyan.com
今もっとも学習コスパの高い技術はChefだと、Chef勉強会に行って確信した 2013-02-25 目次 Chefが熱い！ 株式会社Engine Yardさん主催の、Chef(opschef)勉強会第一回「初めてのChefの教室 #eytokyo」に行って来ました。勉強会の全編動画は、「初めてのChefの教室」を開催しました。(動画&資料) - Engine Yard Blog JP | Engine Yard Blog JP で観ることができます。 勉強会では登壇者が「シェフの帽子」を被って発表していましたw 発表者の皆様方も豪華すぎ！ Chefとは Chef（シェフ）とは、ざっくりいうとサーバーインフラの構築・更新を自動化する技術で、類似としてはpuppetがあります。（参考：オープンソースなシステム自動管理ツール Puppet：連載｜gihyo.jp … 技術評論社 ） 属人性や、面
chef-soloで作業環境構築の自動化 - ひげろぐ
さくらのVPSを契約して放置しておいたままだったので、これを機に環境構築をしてみることにした。 なお現状はユーザーakahigeの追加とsshの設定だけ済ませた状態になっている。 すべての設定はChef経由で行うこと というルールでChefで同じ環境をいくらでも作れるものを目指してみよう。 Chefサーバーのセットアップはめんどくさいのでchef-soloでがんばる所存。 Rubyのインストール とはいえChefの動く環境はChef以外で作らないといけない。 このあたりを省略するならシェルスクリプトによる自動化か、Chefが動くところまでセットアップした仮想マシンのイメージを使うほかなさそうだ。 必要なパッケージのインストール $ wget http://download.fedora.redhat.com/pub/epel/5/i386/epel-release-5-4.noarch.r
apachectl -k restart は stop && start じゃないので気をつけましょう - blog.nomadscafe.jp
Apacheを起動するときに使う事もある apachectl の -k restart は stop && start ではないので注意しましょう。 ServerLimitやThreadLimitなどの一部の設定は、restart では適用されず、stop && start が必要になります。 apachectl は実はshellscriptで出来ています。中をのぞくと #!/bin/sh .. HTTPD='../httpd' .. start|stop|restart|graceful|graceful-stop) $HTTPD -k $ARGV ERROR=$? ;; と書かれています。restartはhttpdコマンドにそのまま渡されるようです。 そこでhttpdコマンドのドキュメントを読むと詳しくは Stopping Apache httpd http://httpd.apach
ローカルポートを食いつぶしていた話 - download_takeshi’s diary
ここのところ、お仕事で管理しているシステムで、夜中に負荷が急上昇する事象が発生しており、夜な夜な対応に追われていました。 （このブログ書いている今も、負荷がじわじわ上昇中なんですが・・・） で、いろいろと調査した結果、ようやく糸口がわかってきました。 結論から言うと、ローカルポートなどのネットワーク資源を食いつぶしていたようです。 以下、調べていってわかったことなどのメモです。 トラブルの事象 運用しているのは Apache2.2 + mod_perl2 なwebサーバで、リスティング広告システムの配信系です。 リスティング広告の配信のシステムって一般的にロジックが複雑でいやーな感じなんですが、このシステムもご他聞に漏れずかなりのひねくれ者で、しかもトラヒックは結構多めです。システム全体で、日に1000万〜2000万クエリくらいかな。幸か不幸か、このご時勢においてもトラヒック的には成長し続
DeNAが社内利用しているMySQLの自動フェイルオーバーツール、オープンソースで公開開始
MySQLがダウンしたときに自動的に別のMySQLへ処理を引き継ぐことで、高可用性を実現するフェイルオーバーツール「MySQL-MHA: MySQL Master High Availability manager and tools」がオープンソースとして公開されたことを、作者の松信嘉範（まつのぶよしのり）氏がブログで伝えています。 Yoshinori Matsunobu's blog: Announcing MySQL-MHA: "MySQL Master High Availability manager and tools" 松信氏はモバゲーなどで知られるDeNAに勤務しており、MySQL-MHAによる自動フェイルオーバー機能はDeNAのインフラ運用を支えているとのこと。同氏のブログから引用します。 Difficulties of master failover is one of
Apacheログに色を付けて快適tail生活 - y-kawazの日記
ツイッターで「Apacheログをtail中にステータスコード部分だけに色つけしたい」ってのを見たので作ってみた。 #!/bin/sed -f ## MEMO # [0m reset # [1m bold # [3m italic # [4m underline # [5m blink # [30m black # [31m red # [32m green # [33m yellow # [34m blue # [35m magenta # [36m cyan # [37m white s/\(HTTP\/1..\"\) \(2[0-9][0-9]\) /\1 \x1b[34m\2\x1b[0m / s/\(HTTP\/1..\"\) \(3[0-9][0-9]\) /\1 \x1b[32m\2\x1b[0m / s/\(HTTP\/1..\"\) \(4[0-9][0-9]\) /\1
MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか - 酒日記 はてな支店
MySQLのmasterとslave 1:1にして参照をslave向けるのってやりたがる人多いみたいだけど、性能たいして上がらない割に可用性落ちるだけだからやめようキャンペーン 2011-06-19 00:16:30 via YoruFukurou MySQL はレプリケーションが簡単に構成できるのですが、時折 master 1台 に対して slave 1台、更新処理は master に、参照は slave に、という構成を目にします。 個人的にはこの構成はお勧めでないと思っているので、その理由を考察してみます。 1. 可用性が落ちる 当然ですが、master, slave のどちらが落ちても影響を受けるために可用性が低下します。 2. 全体の性能がほとんど上がらない master 1台ですべてのクエリを処理する場合と比べて、可用性が落ちる引き換えとして見合った性能向上が得られるか、という
MySQLで参照の負荷分散を行うslaveは3台から構成するのがよいのでは - 酒日記 はてな支店
前回の記事 MySQLをmaster:slave=1:1構成にして参照をslaveに向けるのがなぜ良くないか の続きです。 master : slave = 1 : 1 で参照を slave に分散してもまったく美味しくないわけですが、では参照の負荷分散を行いたい場合の slave は何台で構成するとよいのか考察してみます。具体的には slave 2台の場合と 3台の場合でどちらがお得か。 台数を増やすということは、どこかに障害が発生する確率が高まる、ということです。1台の slave に障害が発生してダウンした場合のことを考えてみます。 slave * 2 → 残り 1台で処理継続 生き残った1台あたりの処理が 2倍になる slave * 3 → 残り 2台で処理継続 生き残った1台あたりの処理が 1.5倍になる たとえば 1台あたり最大 1000qps の処理能力があるとします。sla
私がクックパッドの画像配信野郎です - 昼メシ物語
一年ほど前にヤフーを退職した私ですが、その後なにをやっているかというと、クックパッドに入社して画像配信をしています。私が入社する前から動いていた画像配信の仕組みは設計が古くてなにかと困っていたので、より良いシステムを開発してリプレースというのをやっています。前職ではなかなかこういう基盤システムを一人でイチから作って運用までするという体験はできなかったので、でかい仕事をできるチャンスに恵まれて大変充実した毎日です。 入社当初はサービス開発の担当だったんですが、開発に必要な基盤システムを作り始めたらどんどんエンジニアリングのレイヤーが下がってきて、気づけばインフラチームに所属していました。 まあそんな話はさておき、この画像配信関連の成果をいくつかの勉強会で発表したので、その資料を紹介します。 サイバーエージェントxクックパッド合同勉強会（amepad） 弊社オフィスで開催された、サイバーエージ
GIGAZINEで使っているWebサーバ「PowerEdge T310」障害の一部始終
GIGAZINEの中核になるWebサーバ PowerEdge T310がここ最近頻繁にKernel Panicを起こし、サーバダウンする事態が発生、複数台構成なので閲覧しているGIGAZINE読者には何も影響がないのですが、内部的にこのまま放置することもできず、DELLのメーカーサポートに問い合わせなどを行うもののなかなか原因が特定できず、謎の現象となっていたものの、ようやくその原因が特定され、やっとこさなんとか回復しました。 同様のことで悩んでいる場合には問題特定のために役立つかもしれない、意外に悪戦苦闘した一部始終の記録は以下から。 ・2011年5月16日 GIGAZINEの3台存在するWebサーバのうち1台がが停止しているのを発見。画面上では「Kernel Panic」の文字が出て、動作不能状態に陥っていたため、強制的に再起動を行うことに。 コンソールに表示された「Kernel Pa
サーバ節電について
ヤフー株式会社は、2023年10月1日にLINEヤフー株式会社になりました。LINEヤフー株式会社の新しいブログはこちらです。LINEヤフー Tech Blog こんにちは、R&D 統括本部 プラットフォーム開発本部の吉原 哲です。 東日本で発生した未曾有の震災の影響で、多くの発電施設が影響を受けており、政府及び電力会社から節電の協力が要請されています。一日本国民として、一技術者として、できることがないか検討してみました。あわせて現在までに把握している ヤフーにおける節電に対する取り組みをまとめましたので、節電を検討する際に役立てていただければと思います。 節電方法 一般的にサーバは稼働している際に一定の電力を消費し、CPU 使用率に比例して消費電力が上昇します。またサーバは動作しているときは常に発熱してます。データセンタの空調設備ではこれを取り除くため、サーバの熱量に比例して使用電力が増
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
Takuya Sato
TechCrunch | Startup and Technology News
15分で始めるmonitによるサーバ監視
pixivのインフラを支える技術
UNIXサーバはリブートすべきでない説 | スラド