なぜかJenkinsを起動させたらパケットロスが多発しまくったのを無理やり直した話 - 元RX-7乗りの適当な日々
※ まず、はじめに、僕があまりJenkins自体の挙動に詳しくないので、誰か正しい直し方をご存知の方がいらっしゃったら、教えてほしいです。 本題。これは明らかな環境依存下(特にネットワークまわり)での話なのですが、KVM上でのLinux(CentOS 5/6系)な環境で、Jenkinsを起動するとパケットロスが多発して全然使い物にならないケースがありました。 (Jenkinsを落とすと普通に復旧しちゃうんですよね。。。) で、こんな感じで若手が苦しんでいたので、ちょっとOS上で色々と調べていたのですが、どうもtcpdumpを眺めていると、 11:31:14.427406 IP xxx.xxx.40.102 > 239.77.124.213: igmp v2 report 239.77.124.213 11:31:17.905397 IP xxx.xxx.40.102 > 239.77.12
VPSに不具合が起きた→kvm-clockからHPETに変更 | BROKENDISH
VPSの不具合が起こったので、とりあえずメモしておこう。 数カ月間なんの文句もなく稼動していたサーバが何かの拍子で徐々に言うことを聞かない子になってしまった。 前触れだったのか不具合が起こる前はWordPressの動作が遅かった気がする。 でも、なんとか動いてた。 数日前からは、不定期的にカーネルログを吐き出して、動作が不安定になる。 Webサーバは停止してSSHでログイン出来ない時もあれば、出来る時もあるみたいな状態になった。 ログの一部（めちゃめちゃ出てくるので・・）こんな感じで吐き出してくる。 Aug 15 09:13:13 brokendish kernel: [34669.589331] kjournald D 0000000000000000 0 750 2 Aug 15 09:13:13 brokendish kernel: [34669.589331] ffff81001d
KVMのためのlinux kernel入門
Statistics Favorites 1 Downloads 0 Comments 0 Embed Views 0 Views on SlideShare 333 Total Views 333 仮想環境では、ゲスト OS が「物理的なメモリだ」と思っている仮想物理アドレスは、実際の物理アドレスではありません。そのため、ゲスト OS がメンテナンスしているページテーブルを直接 CPU が参照すると本来アクセスしたかったメモリとは違う箇所へアクセスすることになります。 そのため、仮想物理アドレスから物理アドレスへの変換表を管理しているハイパーバイザが「 shadow page table 」と呼ばれるページテーブルを用意します。ゲスト OS が管理するページテーブルを監視し、更新があれば影のようについていく、というところからこのような名前になっています。「 CR3 」レジスタの変更もハイ
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
処理を実行中です
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
