運用自動化、不都合な真実 // Speaker Deckssmjp 201712 はたのさん祭での「運用自動化、不都合な真実」の発表資料です。 詳細: https://www.opslab.jp/publish/20171212-ssmjp-automation.html (運用設計ラボ合同会社 波田野裕一)
２ちゃんねる復活への奇跡の軌跡
2010年3月10日 18時00分 dubaiにあった板が yutoriで復活 2010年3月9日 18時20分 3月6日２ちゃんねる攻撃計画について、PIEのステートメント発表 2010年3月8日 23時21分 changi / namidame いろいろあって移転完了 → A-Tigerサーバー 2010年3月8日 18時06分 changi / namidame 新サーバーに移転中 2010年3月5日 20時15分 qb5 新新サーバーで復活 2010年3月5日 19時15分 qb5 新新サーバー移転中 またマァヴ（ｒｙ 2010年3月5日 16時00分 PIEデータセンターへのサイバー攻撃に関するステートメント 2010年3月5日 13時15分 PIEデータセンターのステートメントを本日16時00分に発表します。 2010年3月4日 23時00分 qb5 read.cgi動かず ま
スラッシュドット・ジャパン | サーバ監視、何使ってる？
SF.JP Magazineで「Webインタフェースでマシンを監視する4つの方法」という記事が掲載されています。Webインタフェースを持つ4つのサーバ監視ツール（collectd、Cacti、Monitorix、Munin）の特徴をそれぞれ解説した記事で、筆者は記事の末尾で以下のように述べています。 データをじっくりと分析する場合や、管理者以外のユーザからもシステムの統計情報を参照できるようにする場合は、最初にCactiをあたるのがよさそうだ。すでに十分な負荷がかかっているシステムで情報収集を行うなら、システムに与える影響の小さいcollectdを試せばよい。また、多数のノードで個別のアプリケーションパッケージを使って情報を集めるMuninは、同じようなマシンで構成される小規模なグループの監視に向いており、1台しかないサーバの状態を手っとり早く把握したければ、とりあえずCactiかMoni
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか:Web屋のネタ帳 on CNET - CNET Japan
チープなDNSラウンドロビンは高価なロードバランサの座を奪い返せるか 公開日時： 2006/08/10 20:23 著者： watanabe 結論。DNSラウンドロビンという古くからある技術を取り巻く状況の変化を見過ごしている結果、負荷分散と可用性確保のために高価なロードバランサー機器を導入しているWebサイトは、実は大幅に金を無駄にしているのかもしれない。 一部の人には「今頃気がついたか」と笑われる可能性が高い話だ。 筆者が気づいたきっかけはとあるブログに書かれたこんな一節である。 あまり知られていないことかもしれませんが、DNS があるホスト名に対して複数の IP アドレスを返した場合、多くのウェブブラウザは、その全てのアドレスに対して接続を試みます (接続に成功するまで)。 Kazuho@Cybozu Labs: DNS ラウンドロビンと高可用性 (High Avail
MySQLを自動バックアップする「AutoMySQLBackup」
バックアップするのが面倒なMySQLデータベースを自動的にバックアップできるようになるスクリプトです。 いくつものデータベースを一括でバックアップできます。1つのファイルとしてまとめてバックアップすることもできるし、各データベースごとに分けてバックアップすることもできます。バックアップファイルはgzipかbzip2で圧縮されているのでディスク容量も食いません。リモートのMySQLを中央のMySQLにバックアップしたり、バックアップのログをメールで送ることも可能。バックアップしたファイル自体をメールで送ることもできます。バックアップはcronを使う以外に手動で行うことも可能なので、cronがなくてもバックアップはできます。 ダウンロードと詳細は以下の通り。 Automatic MySQL Backup SourceForge.net: AutoMySQLBackup 最小限の設定ですぐに使う
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
