はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28

muninはサーバのさまざまな情報をグラフ化して表示するソフトです。 つい”ムーニン”と言ってしまいますが、”ムニン”がいいようです。 サーバ監視ツールということですが、例えて言うなら、自動車のメーター類のような働きをします。Ganglia、CactiやCloudForecastが同分類のソフトになります。 具体的にどのような場面で重宝するかと言いますと、サーバを増やす際のスペックを検討するときも、失敗する可能性が減らせます。 メモリをいくら搭載するものを用意すればいいのか、CPUはもう少し安いものでも問題無いのかなど、見積もることが簡単になります。 例）メモリを48GB搭載したサーバの利用状況 また以前は、何か障害が起きたときに、人間が手動でデータをかき集めてくるということをよくやっていましたが、Muninを入れてからはその手間は減り、より詳しい情報を参照して原因の特定・対策を講じること

こんなの頑張る意味あんの? って気もしなくもないけど、必要なことの小さいサンプルになったのでグラフまで書いてみた。 rsync --delete よりも rm -rf のほうが、 getdents (readdir) の累計時間が 30 秒多いから real も 30 秒多い、というのが前提のように書いてますが、実際に正しいのかは未確認。重要なのは methodology ってことで。 調査用 dtrace スクリプト aggregation の key に wall からの経過時刻 (秒単位) を入れることで秒ごとに出した。 quantize したいけど @ を数えんのめんどいし、あんまり printf しまくると drop されちゃうし。 avg いるの? というのは excel の pivot table の都合。 #!/usr/sbin/dtrace -s int start_wa

「特定CPUコアでのボトルネック」と「リソースの奪い合い」が2大ボトルネック 第2回、第3回ではディスクI/Oボトルネックについて説明しました。レスポンスとスループットの関係を正しく理解し、I/Oスループットを最大化するようチューニングすれば、ほとんどの大規模処理は速くなります。ユーザもハッピー、皆さんもハッピー、さて家に帰りましょう。 ……しかし、次はだれかからこう聞かれることでしょう。 「CPUの使用率が異様に低いままなんだけど……？」 「CPUの使用率がずっと100％で張り付いているんだけど……？」 どっちやねん！と思うでしょうが、どちらも大規模データを処理するときに特に起こりえる問題です。 ボトルネックは、1つが解消すると、新たなポイントが明らかになるものです。そして多くのケースにおいて、ディスクI/Oボトルネックが解消した場合、次に詰まるのはCPUなのです。 CPUボトルネックは

サーバーのリソースを見るにはグラフ化は重要ですが、推移ではなくリアルタイムな状況、例えば秒単位のスパイキーな負荷を見るには、サーバー上でvmstatやiostatなどの*statファミリーを叩く必要があります。 さて、vmstatはメモリの状況やブロック数単位のI/O状況は見られますが、バイト単位のI/O状況やネットワークの送信、受信バイト数を見ることはできません。 # vmstat 1 procs -----------memory---------- ---swap--- -----io----- --system-- -----cpu------ r b swpd free buff cache si so bi bo in cs us sy id wa st 3 1 0 4724956 355452 726532 0 0 54 484 3 3 1 0 99 0 0 2 0 0 47

7/9(土)にチューニンガソン というイベントに参加して優勝してきたので、その報告と、何を考えてどんなチューニングをしたのかを 記憶の範囲で公開したいと思います。 今回のチューニンガソンのお題は、WordPress(ja) + php + Apache + MySQL で、 ab を使って wp-comment.php 経由でコメントのポストをすることで計測が行われました。 MySQLとApacheを立ち上げたらWordPressが動く環境が渡され、そのWordPress自体は設定ファイルを含めて 改造が一切禁止、WordPressの実行をショートカットするチートも禁止です。 0. 試合前日 環境がAWSとAMI Linuxということは事前に公開されていたため、前日にAWSに登録して少しだけAMI Linuxを 触ってみました。yumベースだけどCentOSと違って結構新しいバージョンが用

大手クラウドサービスであるAmazon EC2では、9種類ものインスタンスタイプ(サーバの種類)から、利用したいスペックのサーバを選択できます。また、EC2のサーバは、4ヶ所ものリージョン(アメリカ東海岸、同西海岸、ヨーロッパ西部、シンガポール)から稼動させる場所を選択することができます。 ここで、気になるのが、Amazon Web Servicesの説明ページで、各インスタンスタイプの公表スペック差異として、EC2独自のCPU単位である"ECU"の数値や、IO性能のModerate(中)やHigh(高)で、どのくらいパフォーマンスが違うのかが見え辛いといった点。 また、一部の場所ではパフォーマンスが出ていない等の話が以前に出ていましたが、4ヶ所のロケーション(Region)によって、各場所でのインスタンス性能が全く同じなのか等も気になるところ。 ここを解明すべく、各種ベンチマークを実行し

前回のエントリーデータベースを用いたセッションデータ管理についてで、MySQL とメモリの関係について良く分からない部分があると書きました。 実はここに関する理解はかなり曖昧な部分があって、調査して追記します。とくにメモリ利用量について。mysqld のプロセスが利用できるメモリの上限が、32bit OS の場合は3G 程度ということは、innodb_buffer_pool_size もこの制限を受け、これについての警告が、先に紹介したリファレンスマニュアルのものという理解だけどいいのだろうかというのが1つ。 2 つ目は、この理解があっているとすると、4G 以上のクラスのメモリをつんだサーバをDB サーバとして利用する場合、64 bit OS でないとリソースの有効活用ができないか。それとも、先に書いたとおり、OS レベルのキャッシュとして利用できるから、結果としてデータファイルを読み込む

たまの機会にLinuxを再起動する場合、起動時間の長さが思いのほか気になるという読者の方もおられるだろう。本記事ではLinuxの再起動時間を短縮するための方法について解説している。 Linuxはそれほど頻繁に再起動する必要のないOSである。しかしいざ再起動となると、とても時間がかかるということもしばしばある。幸いなことに、起動を高速化する方法があるのだ。そして、その中のいくつかはそれほど難しくないものなのである（残念なことに中には難しいものもあるのだが）。そこで、以下にそういった方法を10個選んで紹介する。 ＃1：不必要なサービスを無効化する マシンの使用目的にもよるが、不必要なサービスがたくさんあるはずだ。デスクトップマシンとしてLinuxを使用している？では、sendmailやhttpdなど、必要ではないサービスがたくさんあることになる。サーバマシンであるがWebサーバとしてしか使用し

ファイルの入出力性能の改善は，システム全体の処理速度向上に大きく貢献する。高速なプロセッサを搭載する現在のコンピュータでは，ファイルのアクセス速度がシステム・パフォーマンスのボトルネックになっているためである。不要なディスク・アクセスの削減とアクセス速度そのものの向上が，チューニングの要となる。 アクセス時刻の記録を省略しファイル読み込みを高速化 ファイルにアクセスしたときには，最終アクセス時刻が属性情報として記録される。この情報を記録しないように設定することで，ファイルの読み込み速度を向上できる。最終アクセス時刻の記録を止めるには，ファイル・システムのマウント時に，noatimeオプションを指定する。ベンチマークでは，読み込み速度が2倍強に改善できた。 atimeは無駄 LinuxなどのUNIX系OSでは，statやfstat，lstatというシステム・コールを使って，ファイルの属性情報