第17回 FreeBSD勉強会（2013年4月22日） #FreeBSDStudy - Yukarin'Notehttp://atnd.org/events/37993 日時 : 2013/04/22 19:00 to 21:00 定員 : 120 人 会場 : KDDIウェブコミュニケーションズ会議室 （東京都千代田区麹町三丁目6番地 住友不動産麹町ビル3号館） ハッシュタグ : #FreeBSDStudy
いますぐ実践! Linuxシステム管理
「いますぐ実践! Linux システム管理」はこちらです。 メルマガの解除、バックナンバーなども、以下からどうぞ。 https://www.usupi.org/sysad/ (まぐまぐ ID:149633) その他、作者に関するページは、概ね以下にございます。 https://www.usupi.org/kuri/ (まぐまぐ ID:126454) http://usupi.seesaa.net/ (栗日記ブログ) https://twitter.com/kuriking/ (twitter) https://facebook.com/kuriking3 (facebook) https://jp.pinterest.com/kuriking/pinterest) https://www.instagram.com/kuri_king_/ (instagram) [バックナンバーのトップへ
何故、fluentdなのか？ - プログラマでありたい
最近、fluentdという言葉を聞くことが多いと思います。fluentdは、それぞれのサーバからログを収集し集約する為のアプリケーションです。fluentdは「Log everything in JSON」を合言葉に、全てのログをJSON形式で扱います。また一緒に聞くキーワードとしては、大規模とかリアルタイムとかがあると思います。この時点で関係ないやと思って、興味を失った人も多いと思います。しかし、今後のログ管理は、fluentdが主流になるか解りませんが、同様の集約するフレームワークが中心になると思います。 何故、fluentdが必要か？ まずはオンプレミスの世界から見て行きましょう。ログはサーバーにたまり、管理者はサーバにログインしてログを参照します。特に問題はありません。 次にAutoScalingを使わないAWSの世界です。これも同様に、ログはサーバーにたまり、管理者はサーバにログ
「入門Chef Solo」を読んでChefに入門した話 - $shibayu36->blog;
これまでChefとか全くやったことなかったのだけれど、PrePANとかで必要になったのとなんとなく興味もあったので、naoyaさんが最近出した入門Chef Soloを読んでみました。 入門Chef Solo - Infrastructure as Code 作者:伊藤直也伊藤直也Amazon 読んでみた感想としては非常によくまとまっていて分かりやすいけど、全くChefをやったことない人にとってはChefの実行を試すフェーズが少しやりづらい印象を受けました。理由としてはAWS環境を持っていない場合、2,3章のChefを試す章ができず、さらにそのあとにvagrantでローカルに仮想環境を作るのを学んだとしても、その仮想環境を使って試す部分が少ないためです。 そこで僕は全くchefをやったことない人はまずvagrantでの実行環境を作れるようになってから、本を読み始めるとより知識が深まるのではな
運用視点でChef ServerかChef Solo + Knife Soloのどちらが良いか考えてみた - プログラマでありたい
ChefとFabric、どちらが良いか悩んでいるうちに、Chefが一気にブレイクしてしまった今日この頃です。と言うことで、Chefを中心に今後のサーバ構築・運用について考え中です。そこでまず出てくる問題が、Chef Server+ClientとChef Solo + Knife Solo、どちらの構成が運用しやすいかという点です。 状況を整理する為に、まずは簡単にChef Server, Chef Solo, Knife Soloの関係や役割をまとめて見ます。 Chef Server サーバーの状態を管理し、それに関する情報を保持しておくのがChef Serverです。Client側は個々のサーバにインストールされて、Chef Serverに司令を問い合わせて実行します。Chef ServerはDBやキューなどを持ち、少し複雑な構造です。同じカテゴリーの製品として、PuppetやFabri
[NAS]ReadyNAS、X-RAID2の注意事項とまとめ｜シラサヤ備忘館
NETGEAR ReadyNAS RNDP6000-200AJS そのNETGEAR ReadyNASシリーズの最大の特徴ともいえるX-RAID2。 ネットの多くの記事ではReadyNASとX-RAID2の良いところばかりが取り上げられており、運用する上での厄介な注意点についてほとんど触れていない。 しかし大事な、しかも大量のデータを格納するわけだから不安要素はできるだけ早く把握しておきたい。 そこで公式サイトやマニュアル、海外サイトなどを参考に散乱している情報をまとめてみた。 結構な落とし穴があるのでReadyNASの運用開始前に知っておいて欲しい。 ※ここではRNDP6000-200AJS を基準にしているので他の型番の場合は仕様が違う可能性あり。 ■X-RAID2の特徴 まずX-RAID2とはなんぞやから。 X-RAID2とはNETGEARのReadyNAS開発チームによる最新の、自
第一回 カーネル／VM探検隊 - カーネル／VM探検隊
カーネル／VM探検隊このサイトを検索 ナビゲーションホーム今までのまとめ第一回 カーネル／VM探検隊第二回 カーネル／VM探検隊第三回 カーネル／VM探検隊第四回 カーネル／VM探検隊第五回 カーネル／VM探検隊第一回 カーネル／VM探検隊＠関西第六回 カーネル／VM探検隊第二回 カーネル／VM探検隊＠関西カーネル/VM勉強会@関西 其の参第七回 カーネル／VM探検隊カーネル/VM勉強会@関西 4第八回 カーネル／VM探検隊カーネル/VM+K*BUG勉強会@関西 ごかいめ第九回 カーネル／VM探検隊カーネル/VM探検隊@関西 6回目第十回 カーネル／VM探検隊カーネル／VM探検隊＠北陸 1回目カーネル／VM探検隊＠沖縄第2回カーネル／VM探検隊＠つくばカーネル/VM探検隊@関西 7回目カーネル／VM探検隊 出張版 at セキュリティキャンプフォーラムカーネル／VM Night!第十一回 カ
チューニンガソン5の復習 MySQL 5.6 新機能編 - SH2の日記
というわけで、MyNA(日本MySQLユーザ会)会 2013年3月に参加して発表をしてきました。とてもリラックスして話をすることができました。司会進行の坂井さんをはじめ日本MySQLユーザ会のみなさま、日本オラクルのみなさま、当日お越しいただいたみなさま、どうもありがとうございました。 私のセッションでは前回のエントリの続きということで、MySQL 5.6の新機能Optimizer Traceを活用しながら正攻法でのチューニングを行っていきました。とはいえ途中から正攻法ではなくなっていた気もします。MySQL 5.6でRDBMSとしての土台はしっかりしてきたと思いますので、今後は高度な統計情報を使用したSQL実行計画の最適化といったところにも機能強化が施されていくのではないかと期待しています。 プレゼンテーション資料 (PDF) EXPLAINとOptimizer Traceの出力結果 プ
Fluentd w/ Ruby 2.0.0-p0 のメモリ使用量 (追記: w/ msgpack v0.5.4) - tagomorisのメモ置き場
いくつかFluentdのベンチマークをとらないとなー、そういえばRuby 2.0.0-p0も出ましたね、ということでベンチマーク取ろうと思ってあれこれ作業してたらなんか変なのを見付けたのでとりあえず記録。 なおベンチマークの結果については、いろいろ取りかたを考え直す必要があるのでまたこんど。 概要 Fluentd の動作環境が Ruby 2.0.0-p0 with jemalloc なケースで Ruby 1.9.3-p392 に較べて大幅に大幅にメモリを食う上、負荷を停止した時にも何かよくわからない挙動を示す。 jemalloc を使わないケースだと 1.9.3 とほとんど変わらないと思われる挙動で jemalloc の必要性が無くなったとかいうわけではない。 詳細 ベンチマークは あるサーバ(4core HT, 16GB RAM)に立てた Fluentd に対し、別のサーバ(同一サブネッ
Sakura サーバでRails
はてなグループの終了日を2020年1月31日(金)に決定しました 以下のエントリの通り、今年末を目処にはてなグループを終了予定である旨をお知らせしておりました。 2019年末を目処に、はてなグループの提供を終了する予定です - はてなグループ日記 このたび、正式に終了日を決定いたしましたので、以下の通りご確認ください。 終了日: 2020年1月31日(金) エクスポート希望申請期限:2020年1月31日(金) 終了日以降は、はてなグループの閲覧および投稿は行えません。日記のエクスポートが必要な方は以下の記事にしたがって手続きをしてください。 はてなグループに投稿された日記データのエクスポートについて - はてなグループ日記 ご利用のみなさまにはご迷惑をおかけいたしますが、どうぞよろしくお願いいたします。 2020-06-25 追記 はてなグループ日記のエクスポートデータは2020年2月28
TSOが原因でさくらVPSへのウェブアクセスが異常に遅くなるトラブルに遭遇 - 橙工房 Atelier Laranjeiras
自宅のネット環境から都道府県別統計とランキングで見る県民性 [とどラン]を運営している、さくらVPSへのアクセスが異常に遅くなるトラブルに遭遇した。 現象としては ブラウザ経由のアクセス、ftpクライアント経由のアクセス速度が異常に遅くなる。（数バイト／秒程度） 小さいパケットだと問題ないので、pingやtracerouteでは異常が発見されない。 自宅ネット環境はDHCPでIPがふられているが、特定のIP,ゲートウェイのセットでのみ発生する。 職場の別回線ではそのようなトラブルは一切発生しない。 複数のWindowsXPで発生したが、Linuxデスクトップ（Debian）では発生しない。 この件について自宅のプロバイダともやりとりをしたが、原因が見つからなかった。そこでさくらインターネットに問い合わせたところ、すぐに対策法が送られてきて問題は解決した。 サーバー側でTSO（TCP Seg
第6回 クラウドサービスの比較：AWS、Windows Azure、さくらのクラウド | gihyo.jp
今回でこの連載も最終回です。これまでAmazon Web Services、さくらのクラウド、Windows Azure、Google App Engineについて触れてきました。最終回ということでこれらのベンチマークを比較してみたいと思います。 unixbenchで比較 Amazon Web Services（AWS）、さくらのクラウド（以降さくら）、Windows Azure（以降Azure）は、IaaS（仮想サーバ）がありますが、Google App EngineはPaaSなので単純な比較はできません。まずは前者の3つについて、比較をしてみましょう。 今回はパフォーマンス計測の定番、unixbenchで比較をしてみました。 https://code.google.com/p/byte-unixbench/ 計測対象は下記の通りです。 ディスクについては、AWSではProvis
abコマンドでの秒間リクエスト - OKWAVE
自分のサイトをabコマンドを使用して負荷テストしています。リクエスト数が31と、結構ひどいなと思っています。 現在、自分のサイトをabコマンドで負荷テストしています。 ab -c 10 -n 100 http://～/ 10同時接続で、100回リクエストしています。 この結果、 Requests per second: 31.03 [#/sec] (mean) 秒間のリクエスト数が31と、結構ひどいなと思って、他のサイトで試したところ、 ■教えてgooトップ ab -c 10 -n 100 http://oshiete.goo.ne.jp/ Requests per second: 25.08 [#/sec] (mean) 秒間25ということは、100同時アクセスで・・・と考えると非常に遅い気がします。 ■twitter (goo_blog) ab -c 10 -n 100 http://
大事なサービスがOOM Killerに殺されないようにする - Qiita
start() { echo -n $"Starting $prog: " daemon $prog RETVAL=$? echo [ $RETVAL -eq 0 ] && touch /var/lock/subsys/$prog + PID=`cat /var/run/monit.pid` + echo -17 > /proc/$PID/oom_adj return $RETVAL } $ sudo systemctl --system daemon-reload $ sudo /etc/init.d/monit restart Restarting monit (via systemctl): [ OK ] $ cat /proc/`cat /var/run/monit.pid`/oom_adj -17 Register as a new user and use Qiita more
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
[CentOS] Journal Aborts in VMware ESX (Filesystem Corruption) - Grokbase
Technical Note TN2123: CrashReporter
http://support.fusionio.com/kb/red-hat--building-the-iodrive-driver-from-source-red-hat-oracle-centos/
Twitter / fusionioJP: @iwag_org なお、弊社製品にはDRAMによるキャッシ ...
メンテナンス中
カーネルリソースの管理