はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
What's ttyrec? ttyrec is a tty recorder. Recorded data can be played back with the included ttyplay command. ttyrec is just a derivative of script command for recording timing information with microsecond accuracy as well. It can record emacs -nw, vi, lynx, or any programs running on tty. What's New 2006-06-11: ttyrec 1.0.8 Released Introduced a hack to reduce the playback time drift. Based on Mat
先週、AMD主催のセミナーで「はてなでの仮想化技術の使い方」という発表をしてきました。 はてなでは、1年半ほど前から仮想化技術に取り込んでおり、現在では300台以上のサーバが仮想化されています。仮想化技術には、様々なメリットがありますが、はてなではサーバリソース利用率の向上と、システムの安定化の二つの利点を重視しています。サーバを仮想化していく際に、どのようなポリシーで一つの物理的なサーバに仮想化ホストを積み重ねているか、とか、実際どれぐらい効率を上げられているか、とか、あとAMDさんのセミナーなので、消費電力的にはOpteronが実測結果からは10〜20%程度効率がいい(負荷時にOpteron 1.82A, Xeon 2.17A)、というあたりの話をしてきました。 How to use Virtualization Technology in HatenaView more presen
ここ数年の大規模サービスのシステム運用について調べてみたので参照したページやファイル、本へのリンクをまとめておく。PDF へのリンクも多数含まれているのでご注意を。 時代が時代なら企業のノウハウとして隠されていたような情報がこれだけ公開してもらえているというのが非常にありがたい。公開してくれている各企業や公開してくれている人に感謝。 あとで気付いたが、Google や Facebook の事例も探しておけばよかった。Thrift とかあったのに。「こんな情報もあったよ」などあればぜひ教えてください。追記していきます。 youtube http://d.hatena.ne.jp/stanaka/20070427/1177651323 digg http://d.hatena.ne.jp/stanaka/20070427/1177651323 livedoor http://labs.cybo
キューイングしてしまったSPAMメールの処理 qmailをインストールすると、配送キューの簡単な統計情報を表示する/var/qmail/bin/qmail-qstatと、たまっているメッセージキューのヘッダ情報を部分的に表示する/var/qmail/bin/qmail-qreadもインストールされます。 # /var/qmail/bin/qmail-qstat messages in queue: 11 messages in queue but not yet preprocessed: 0 # /var/qmail/bin/qmail-qread 28 Oct 2001 20:35:57 GMT #11224 2127 <> remote XXX@XXX.jp 28 Oct 2001 17:20:17 GMT #11225 2132 <> remote XXX@XXX.jp 28 Oc
不要サービス 停止スクリプト 上記の不要サービスを1つずつ停止して、更に自動起動もしないようにして・・・ という処理が面倒臭かったので、スクリプトを作成しました。 service_stop なんて名前で以下を作成しました。 #!/usr/bin/perl # CentOS 5 use strict; use warnings; # 自動起動を止めるサービス一覧 my @service = qw( apmd auditd autofs avahi-daemon bluetooth cups firstboot gpm hidd ip6tables kudzu mcstrans mdmonitor netfs nfslock pcscd portmap restorecond rpcgssd rpcidmapd sendmail xfs xinetd yum-updatesd ); #
ヤフーの画像はなぜyimg.jpドメインなのか？ サイト高速化の手法とヤフーの失敗例 でヤフーがなぜドメインを変えて画像サーバを運用しているかが書かれている.「静的なコンテンツに対してクッキーフリードメインを使うことによって速度向上を狙う」というのが理由とあって,これはこれでもちろん正しいのだけれど,これはどちらかというと副次的な理由で本当の理由は違う. クッキーフリードメインを使うことで悪意あるFlashコンテンツなどから自社ドメインのクッキーを守るためというのが本当の理由で,これはあちこちで使われているテクニックだ.Flashコンテンツは外部の業者さんに作ってもらったり,広告の入稿素材として入ってくるので,信頼できないデータとして取り扱う必要があり,万一まずいデータがアップされることがあっても大丈夫にしておく必要がある. 最近ユーザからの任意のコンテンツを受けつけて同一ドメインで配信し
GT Nitro: Car Game Drag Raceは、典型的なカーゲームではありません。これはスピード、パワー、スキル全開のカーレースゲームです。ブレーキは忘れて、これはドラッグレース、ベイビー！古典的なクラシックから未来的なビーストまで、最もクールで速い車とカーレースできます。スティックシフトをマスターし、ニトロを賢く使って競争を打ち破る必要があります。このカーレースゲームはそのリアルな物理学と素晴らしいグラフィックスであなたの心を爆発させます。これまでプレイしたことのないようなものです。 GT Nitroは、リフレックスとタイミングを試すカーレースゲームです。正しい瞬間にギアをシフトし、ガスを思い切り踏む必要があります。また、大物たちと競いつつ、車のチューニングとアップグレードも行わなければなりません。世界中で最高のドライバーと車とカーレースに挑むことになり、ドラッグレースの王冠
米Hewlett-Packard（HP）は12月29日、WindowsマシンとMacの両方に対応する家庭用サーバを発表した。 HP MediaSmart Serverシリーズの新製品「ex485」「ex487」は、MicrosoftのWindows Home ServerプラットフォームとAppleの自動バックアップツールTime Machineに対応。WindowsマシンとMac OS X Leopard搭載のMacの自動バックアップが可能だ。iTunesのライブラリサーバや、ネットワーク上の写真や動画などのコンテンツのストリーミングサーバとしても利用できる。 IntelのCeleron（動作クロック2.0GHz）と800MHzのDDR2 DRAM 2Gバイトを搭載し、ex485は750GバイトのHDD、ex487は1.5T（テラ）バイトのHDDを内蔵する。HDDは9Tバイトまで増設可能
システム管理者のみなさん、こんにちは。今日は Rails アプリの deploy ツールとして有名な（らしい）Capistrano についてです。紹介？ いえいえ。紹介はすでに有名な人たちによってなされています。ワタシがしたいのは検討。こいつはどこにどのように使えそうか。 Capistrano: Home システム管理の話なのになんで Puppet じゃないの？と思うかもしれません。それは、以前 Puppet の OSX 対応があまりよくなかったことと、また自分の環境が PPC Mac だったため、仮想マシンを使って他の OS を動かすのも現実的でなく、面倒になってしまっていたからです。 で、巡り巡って Capistrano って実は deploy 以外にも結構使えそうじゃない？と思えましたよというお話。想定しているバージョンは Capistrano 2.5.3 です。 なお、例によって嘘
2008年12月19日 お客様各位 さくらインターネット株式会社 平素よりさくらインターネットをご利用いただき、誠にありがとうございます。 本日、弊社西新宿データセンター（所在地：東京都新宿区西新宿）におきまして、 電源設備からの発煙によりデータセンター収容ラック内への一部電源供給が停止 しております。 詳しい影響範囲と原因は現在調査中です。 ＜記＞ 発生日時 : 2008年12月19日 12時35分頃 影響範囲 : 現在調査中 障害内容 : 電源設備からの発煙による一部電源供給停止 以上
運営元のロゴ Copyright © 2007-2025 All Rights Reserved by Gijutsu-Hyoron Co., Ltd. ページ内容の全部あるいは一部を無断で利用することを禁止します。個別にライセンスが設定されている記事等はそのライセンスに従います。
監視するデータ 集客力のあるサイトを運営しているWebサーバやメーリングリストを運営しているサーバ、ソフトウェアを配布するFTPサーバ、ファイル共有をするためのサーバなどは、クライアントからの非常に多くの要求を処理する必要があります。 サーバの応答が遅い場合は、ハードウェアの増強などで対応する必要があります。ボトルネックの特定のためには、原因がCPUのパワー不足なのか、メモリ容量が足りていないのか、回線容量が細過ぎるのかなどを判断しなければなりません。そのほかにもハードディスク容量、マザーボードの温度、UPSの電力、メールの配送効率、Webページのアクセス解析など、運用中に注意して見ておく必要のあるデータは多くあります。 ここでは、システムを運用するうえで、監視項目として挙げられる主要なデータおよびその確認方法を紹介します。 プロセス プロセス関連の監視項目には、以下のようなものが挙げられ
サーバ負荷分散の基本構成と動作 負荷分散装置（ロードバランサ）のニーズは現在も高まる一方です。従来はWebサーバのみを主な対象としていましたが、現在ではルータ#1／アプリケーションサーバ／メールサーバ／SIPサーバ／ファイアウォール／VPNゲートウェイ／ウイルスゲートウェイ／IDSなど、多種多様の機器やプロトコルが負荷分散の対象となっています。それに応じてロードバランサも現在では非常に多機能となっていますが、本連載では、全3回に渡ってアプリケーションベースではなく、ネットワークベースの技術、基本となるパケットフローやサーバヘルスチェック、接続維持などの動作について紹介します。また、パフォーマンス測定についてもお話ししましょう。 #1 ルータはレイヤ3でインターネット回線のマルチホーミングとして機能する（＝複数のWAN回線を接続して、同時に通信させることで負荷分散し、必要な帯域を確保するし、
Tracの構築ってなかなか面倒ですよね。自分も初めて作ったときはいろいろと手間取ったことを覚えています。 とくにソースからいれるとなると、いろいろとやらなければいけません。パッケージも用意されていますが、日本語化をする場合などいろいろと面倒があります。 今回も前回に引き続き、簡単にTracのインストールを行う手順を紹介したいと思います。 事前準備 まずは、以下の手順を行っていることが前提です。 10分で作る、Subversionレポジトリ - UNIX的なアレ そのため、動作環境は以前と同様です。試してみたところ、Ubuntuでも同様の手順でいけるようです。 OS Debian Linux etch Protocol http Web Server Apache2.2.3 さて、それでは構築していきましょう！ パッケージのインストール さて、Tracを使うにあたって必要なパッケージをインス
サーバのレスポンスが遅くなると経験のないサーバ管理者は無意味にメモリ増強を行ったりしますが、行き当たりばったりのシステム拡張は無駄な投資につながります。ボトルネック個所の調べ方は案外簡単なので、この際押さえるところをきちんと押さえて正しい方法論でシステム拡張をしていきましょう。 【一般論】 ボトルネックとなりうる要素は主に４つです。 ①CPU使用率 ②メモリ使用量 ③ディスクI/O ④TCPコネクション数 これらを押さえておけばボトルネック個所の把握とその解消は難しくありません。これを踏まえた一般論を述べてみたいと思います。 WEBサーバの場合は多くの場合、TCPコネクション数から先に限界が来ます。OSやApache等のWEBサーバのパフォーマンスチューニングを十分施すことが前提ですが、その場合TCPコネクション数1万くらいまではなんとか保てると思いますが、それ以上のTCPコネクショ
各種ログファイルは放置しておくと時間とともに肥大化します。この問題を解決するのがログローテーションです。 ログローテーションは、例えばlogというログファイルの名前をlog1 log2 log3…というように定期的に回してバックアップします。 ローテーション数を4にしたのであれば定期的にlog4のログはlog3に上書きされ、log3のログはlog2に上書きされ、log2のログはlog1に上書きされ log1のログはlogに上書きされます。そして新たな空のログファイルlogが生成されます。一週間間隔でローテーションするのであれば ログファイルは1週間ログデータが記録されるごとに空になり、4週間分のログファイルがバックアップされていることになります。 logrotateはcronによって定期的に実行されています。 #ls -l /etc/cron.daily/logrotate -rwx
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
