GitHub - ca-archived/aeromock: Lightweight mock web application serverYou signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session. You switched accounts on another tab or window. Reload to refresh your session. Dismiss alert
うちの会社のサーバー監視方法がおかしいので改善を試みた
前回の書き込み http://anond.hatelabo.jp/20120407162253どんな監視方法なのかをを簡単にまとめてみるうちの会社のサーバー監視方法１５台くらいのwindowsサーバーに自PCからリモートデスクトップ接続する遠隔操作でイベントログやらHDD容量やらを目視チェックして全て台帳（紙媒体）に書き込む以上を全サーバーに行うと普通に毎朝１時間かかる。負荷がでかいので分散の為、若手を入れて１０人くらいで順番にまわしている今後もサーバーが増える予定あり前回の書き込みの反応は大体以下のような感じだった頭おかしいｗｗｗ受けるｗｗｗｗｗいろいろ予想以上 これらのコメントのおかげで、おかしいのは自分の気のせいではないという事にようやく自信を持てた。とりあえず前回すぐにでもできそうな方法を方法を教えてもらったので改善できるかサーバー管理してるチームの一人に相談してみた。自分「毎朝
MongoDBの信頼性に疑問
原文(投稿日：2011/11/07)へのリンク 最近、MongoDB に関して非常に好ましくない内容のかなり話題になった市場報告が２つあった。批判の大部分は、パフォーマンス問題とデータ損失の組合せに集中している。この話を続ける前に、これらは公式の事例研究でないことを肝に命じて欲しい。そうではなくて、最近 MongoDBを使った開発チームによる市場報告である。 まず Urban Airshipの Michael Schurter氏のレポートから始める。 Urban Airshipは既に、MongoDBの問題を経験しており、このレポートを書く前にデータのほとんどを PostgreSQLに移行を済ませていた。残ったデータはMongoDBにとって理想的のようだ。 短命－もしそれを失っても、短い間サービス低下を経験するが、 壊滅的ではない 小さい－容易にメモリーに収まる(~15 GB) 二次索引－キ
DBサーバーの負荷分散
MySQLアクセスを負荷分散する ユーザーからのアクセス数が非常に多いWebサイトにおいて、MySQLのSLAVEサーバーを複数台並べて負荷分散させるということがよく行われています。ただ、Webアクセスの負荷分散は一般的なテーマなのでいろいろなところで語られているのに対し、DBアクセスの負荷分散というテーマは一般的でないのかあまり語られていないように感じます。 DBアクセスを負荷分散するにあたって一番荒っぽい方法は、Webサーバー上のプログラムの中でどのSLAVEサーバーに接続するかをランダムで決める方法です。ランダムと言っても長時間アクセスしているとほぼ接続先が均等化されるので、一見この方法でも問題ないように見えます。しかしこの方法だと、接続しに行こうとしたSLAVEサーバーが高負荷もしくはサービス停止中であっても構わず接続しに行ってしまうという問題があります。 このような問題を解決する
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
