2ch特化型サーバ・ロケーション構築作戦のスレッドです。
・2ちゃんねるのサーバロケーション、PIEに関する関連作業・調整事項
・DNS登録・変更関連の各種作業や調整事項
・2ちゃんねるのサーバで採用しているOS、FreeBSDに関する情報・調整事項
・各種作戦・プロジェクトとの連携、プロジェクト間の連携
等を取り扱います。
前スレ:
2ch特化型サーバ・ロケーション構築作戦 Part23
http://qb5.2ch.net/test/read.cgi/operate/1153650861/
探検
2ch特化型サーバ・ロケーション構築作戦 Part24
■ このスレッドは過去ログ倉庫に格納されています
>>784 コピペしくりました。もう1回。
■ サーバリフレッシュ工事 連絡・作業スレッド3
http://qb5.2ch.net/test/read.cgi/operate/1169662973/502
以下のDNS登録をお願いします。
・memoriesへの収容
(現状)
+school6.2ch.net:206.223.149.235
+book4.2ch.net:206.223.150.100
+travel3.2ch.net:206.223.150.100
(変更後)
+school6.2ch.net:206.223.151.230
+book4.2ch.net:206.223.151.230
+travel3.2ch.net:206.223.151.230
■ サーバリフレッシュ工事 連絡・作業スレッド3
http://qb5.2ch.net/test/read.cgi/operate/1169662973/502
以下のDNS登録をお願いします。
・memoriesへの収容
(現状)
+school6.2ch.net:206.223.149.235
+book4.2ch.net:206.223.150.100
+travel3.2ch.net:206.223.150.100
(変更後)
+school6.2ch.net:206.223.151.230
+book4.2ch.net:206.223.151.230
+travel3.2ch.net:206.223.151.230
>785
done(^_^;)
done(^_^;)
>>786
確認しました。
確認しました。
788 ◆w0gEWSRfYU
2007/04/25(水) 17:52:13ID:5D9AmS+o0 root様
いつもお世話になっております。
株式会社jig.jpの菊池です。
2007年4月25日にサーバの追加を行いました。
お手数ですが、IPの追加宜しくお願い致します。
【追加IP】
219.94.147.35
219.94.147.36
219.94.147.37
219.94.147.38
219.94.147.39
【CIDR表記】
219.94.147.35/32
219.94.147.36/30
IP一覧も更新致しました。
http://br.jig.jp/pc/ip_br.html
大変お手数ですが、対応宜しくお願い致します。
いつもお世話になっております。
株式会社jig.jpの菊池です。
2007年4月25日にサーバの追加を行いました。
お手数ですが、IPの追加宜しくお願い致します。
【追加IP】
219.94.147.35
219.94.147.36
219.94.147.37
219.94.147.38
219.94.147.39
【CIDR表記】
219.94.147.35/32
219.94.147.36/30
IP一覧も更新致しました。
http://br.jig.jp/pc/ip_br.html
大変お手数ですが、対応宜しくお願い致します。
789外野ァァン
2007/04/25(水) 17:55:34ID:uqLqv+vn0 ヽ(`Д´)ノ ボッキアゲ
>>788
作業はいります。
作業はいります。
BBS.CGI - 2007/04/25
にて対応済です。
にて対応済です。
792 ◆w0gEWSRfYU
2007/04/26(木) 12:32:11ID:wmokXFwu0793ょぅι゙ょの見物人 ◆YoJo69//rM
2007/04/27(金) 12:17:17ID:wna9sqsj0 ・・・そんなやりとりをここでしていいんだろうか。
サーバーダウン(鯖落ち)情報 part145
http://qb5.2ch.net/test/read.cgi/operate/1175626823/909
以下のメールを送ってみたです。
お世話になります。
さきほど、すべての障害が復旧したことを確認しました。
ご対応ありがとうございました。
今回の障害対応については完了ということで問題ございませんが、
以下の二点につきましては、状況の報告(簡単で結構です)と
今後の再発防止対策をよろしくお願いいたします。
1. なぜ、当方が依頼していないネットワークの設定変更が
現地にて無断で行われたのか
(単なるハードウェア交換のみとしなかったのか)
2. なぜ、1. の状態でサーバをオンライン状態にしたのか
また特に「顧客のサーバの設定ファイルの内容(root権限サーバでは、
/etc 下のシステムファイル等も含む)を、顧客に無断で強制的に変更する」
ということは、本来決してあってはならないことであると考えておりますので、
これにつきましては、再発防止対策をくれぐれもよろしくお願いいたします。
http://qb5.2ch.net/test/read.cgi/operate/1175626823/909
以下のメールを送ってみたです。
お世話になります。
さきほど、すべての障害が復旧したことを確認しました。
ご対応ありがとうございました。
今回の障害対応については完了ということで問題ございませんが、
以下の二点につきましては、状況の報告(簡単で結構です)と
今後の再発防止対策をよろしくお願いいたします。
1. なぜ、当方が依頼していないネットワークの設定変更が
現地にて無断で行われたのか
(単なるハードウェア交換のみとしなかったのか)
2. なぜ、1. の状態でサーバをオンライン状態にしたのか
また特に「顧客のサーバの設定ファイルの内容(root権限サーバでは、
/etc 下のシステムファイル等も含む)を、顧客に無断で強制的に変更する」
ということは、本来決してあってはならないことであると考えておりますので、
これにつきましては、再発防止対策をくれぐれもよろしくお願いいたします。
とり急ぎ、管理人に状況をメールしました。
今後問題が再発しなければ、とえいあえず本件はこれで。
雪だるまシステムはバックアップ系も含めて冗長に組んであるつもりですが、
データセンター内で直接ごにょごにょされることまでは、
さすがに想定していなかったり。(´・ω・`)
今後問題が再発しなければ、とえいあえず本件はこれで。
雪だるまシステムはバックアップ系も含めて冗長に組んであるつもりですが、
データセンター内で直接ごにょごにょされることまでは、
さすがに想定していなかったり。(´・ω・`)
>>794 の返事をいただきました。
(丁寧なおわび&別途報告の旨)
ハードウェア障害はしかたないし、サービスダウンもなしにはできないですが、
「顧客のサーバに勝手にログインして、ファイルの内容を勝手に覗いたり、
ましてや無断で設定内容を変更する」
は、絶対にありえないことなので、それの再発防止が今回のポイントということで。
(丁寧なおわび&別途報告の旨)
ハードウェア障害はしかたないし、サービスダウンもなしにはできないですが、
「顧客のサーバに勝手にログインして、ファイルの内容を勝手に覗いたり、
ましてや無断で設定内容を変更する」
は、絶対にありえないことなので、それの再発防止が今回のポイントということで。
2007/04/27(金) 18:46:29ID:3Jd+uTfZ0
今のうちに弁護士雇っておくとか
事の顛末を読んでみました。
今回のヒューマンエラーの対象が、、、
雪だるまシステムの受付嬢で*良かったですね*、、と強調して書いてみる。
2ちゃんねる以外で、このような事をしたらデータセンターとして信用失墜になりますし。
他の観客のシステムで、こんな事をしたら、、、(ry
まぁ、終わった事みたいですし。これ以上は書くのやめておこう。。
今回のヒューマンエラーの対象が、、、
雪だるまシステムの受付嬢で*良かったですね*、、と強調して書いてみる。
2ちゃんねる以外で、このような事をしたらデータセンターとして信用失墜になりますし。
他の観客のシステムで、こんな事をしたら、、、(ry
まぁ、終わった事みたいですし。これ以上は書くのやめておこう。。
【実況】 live22+live23 Part22
http://qb5.2ch.net/test/read.cgi/operate/1155560057/906
というわけで前から懸案になっているmod_cacheなわけですが、
「書き込んですぐ読んだ時の反映タイムラグ(*1)」って、
発生したりしないのかな。
(*1)ちょうどNFS版雪だるまを動かした時みたいな感じの。
http://qb5.2ch.net/test/read.cgi/operate/1155560057/906
というわけで前から懸案になっているmod_cacheなわけですが、
「書き込んですぐ読んだ時の反映タイムラグ(*1)」って、
発生したりしないのかな。
(*1)ちょうどNFS版雪だるまを動かした時みたいな感じの。
803stream ◆PNstream2s
2007/04/30(月) 23:04:35ID:/bUJz0OB0 フロントが常に「更新チェック」を行うように設定にすれば、起こらないはずです。
しかしこの設定だと、書き込みが激しくないときはこれで十分キャッシュの効果はあるけど、
書き込みが1分間に1000(1秒間に16)を超えるような状態で効果があるのか?
でも
http://news22.2ch.net/test/read.cgi/liveplus/1177641490/256
個人でリロードしまくりで304が出てるのもあるくらいだから、効果あるか。
しかしこの設定だと、書き込みが激しくないときはこれで十分キャッシュの効果はあるけど、
書き込みが1分間に1000(1秒間に16)を超えるような状態で効果があるのか?
でも
http://news22.2ch.net/test/read.cgi/liveplus/1177641490/256
個人でリロードしまくりで304が出てるのもあるくらいだから、効果あるか。
前に書いたような覚えもありますが,基本的には >>803 ですね.
Cache-Control: s-maxage=0
なら常に更新チェックを行います.1秒程度のディレイを許容するなら
Cache-Control: s-maxage=1
にするとか.NFS の時は,そもそも基本的な動き自体が怪しかったですしね......
(まぁ,正常に動くなら HTTP より NFS の方が軽いんでしょうけど)
Cache-Control: s-maxage=0
なら常に更新チェックを行います.1秒程度のディレイを許容するなら
Cache-Control: s-maxage=1
にするとか.NFS の時は,そもそも基本的な動き自体が怪しかったですしね......
(まぁ,正常に動くなら HTTP より NFS の方が軽いんでしょうけど)
2007/05/01(火) 00:17:29ID:ISYbr3E/0
807stream ◆PNstream2s
2007/05/01(火) 00:36:29ID:NWOQj4PC0 あと雪だるま関連の実験要素といったらバックエンドで他のWebサーバーを試すことかな?
軽くレビュー。
・bbsd を -n 8 から -n 16 にするのは効果がある @ live24
・httpd の設定を変えたところカーネルパニックした。
何かの虫を踏んだか、設定がいまいちだったか。
・bbsd を -n 8 から -n 16 にするのは効果がある @ live24
・httpd の設定を変えたところカーネルパニックした。
何かの虫を踏んだか、設定がいまいちだったか。
panicの内容:
http://news22.2ch.net/test/read.cgi/liveplus/1177641490/725
> Apacheのスレッド数を 16 から 24 にしたところで反応がなくなり、
> リモートコンソールをチェックすると、
> panic: vm_thread_new: kstack allocation failed
> と言って落ちていて、
> Fatal trap 12: page fault while in kernel mode
> と言って、ダブルパニック(カーネルモードで再度しくる)して、
> 止まってしまっていました。
http://news22.2ch.net/test/read.cgi/liveplus/1177641490/725
> Apacheのスレッド数を 16 から 24 にしたところで反応がなくなり、
> リモートコンソールをチェックすると、
> panic: vm_thread_new: kstack allocation failed
> と言って落ちていて、
> Fatal trap 12: page fault while in kernel mode
> と言って、ダブルパニック(カーネルモードで再度しくる)して、
> 止まってしまっていました。
>>809
で、再度のリブートでも同じ panic で落ちた(今度はダブルパニックしなかった)
ので、KVM からシングルユーザで設定を元に戻して、
リブートして復活と。
しかし、久しぶりの完敗ですか。
正直ちょっとくやしいなと。
で、再度のリブートでも同じ panic で落ちた(今度はダブルパニックしなかった)
ので、KVM からシングルユーザで設定を元に戻して、
リブートして復活と。
しかし、久しぶりの完敗ですか。
正直ちょっとくやしいなと。
うーむ。
%kgdb /boot/kernel/kernel vmcore.51
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
(no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer.
(kgdb)
%kgdb /boot/kernel/kernel vmcore.51
[GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"]
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-marcel-freebsd".
(no debugging symbols found)...Attempt to extract a component of a value that is not a structure pointer.
(kgdb)
http://news22.2ch.net/test/read.cgi/liveplus/1177641490/744
やはり,これは panic するんじゃなくて本来エラーリターンするようにすべきもの,ってことですね.
panic: vm_thread_new: kstack allocation failed
http://lists.freebsd.org/pipermail/freebsd-threads/2006-September/003700.html
> I've seen this when running stress2 with a large number of
> incarnations. Why don't we return an error to the user?
programmer ENOTIME
patch welcome!
http://lists.freebsd.org/pipermail/freebsd-threads/2006-September/003701.html
On closer inspection this means that we've run out of KVA. In
principle it should be handled more gracefully, but the 1GB KVA
limitation is really a 32-bit artifact. It might be worth wading
through the kernel memory allocations to see if a subsystem has gone
beserk.
やはり,これは panic するんじゃなくて本来エラーリターンするようにすべきもの,ってことですね.
panic: vm_thread_new: kstack allocation failed
http://lists.freebsd.org/pipermail/freebsd-threads/2006-September/003700.html
> I've seen this when running stress2 with a large number of
> incarnations. Why don't we return an error to the user?
programmer ENOTIME
patch welcome!
http://lists.freebsd.org/pipermail/freebsd-threads/2006-September/003701.html
On closer inspection this means that we've run out of KVA. In
principle it should be handled more gracefully, but the 1GB KVA
limitation is really a 32-bit artifact. It might be worth wading
through the kernel memory allocations to see if a subsystem has gone
beserk.
つ PHP 5.2.2 and PHP 4.4.7 Released
【より敏感に】 リブート要請 Ver2.0
http://qb5.2ch.net/test/read.cgi/operate/1152266515/307-
サーバーダウン(鯖落ち)情報 part148
http://qb5.2ch.net/test/read.cgi/operate/1177948183/97-
・Sumaのリセット (via telnet)
・Sumaのステータスチェック
・KVM接続依頼→接続完了 by 中の人
・/home の fsck 実施、mount テスト
・oyster902 リブートテスト
の順番でいけました。
システムディスク RAID1、Suma RAID5 ともに問題なしを確認。
oyster902はしばらく(少なくとも1日程度)KVM経由で触れるように
しておいてもらう旨、依頼済。
http://qb5.2ch.net/test/read.cgi/operate/1152266515/307-
サーバーダウン(鯖落ち)情報 part148
http://qb5.2ch.net/test/read.cgi/operate/1177948183/97-
・Sumaのリセット (via telnet)
・Sumaのステータスチェック
・KVM接続依頼→接続完了 by 中の人
・/home の fsck 実施、mount テスト
・oyster902 リブートテスト
の順番でいけました。
システムディスク RAID1、Suma RAID5 ともに問題なしを確認。
oyster902はしばらく(少なくとも1日程度)KVM経由で触れるように
しておいてもらう旨、依頼済。
817ょぅι゙ょの見物人 ◆YoJo69//rM
2007/05/19(土) 17:37:44ID:y0+5nQZh0 Subject: [FreeBSD-Announce] HEADS UP: xorg 7.2 update in progress
From: Kris Kennaway <kris@obsecurity.org>
To: announce@FreeBSD.org
Dear FreeBSD Users,
Within the next 24 hours, the long-awaited update to the X.org 7.2
windowing system will be committed to the ports tree. This upgrade
has been 6 months in the making and would not have been possible
without the dedicated work of Florent Thoumie <flz@FreeBSD.org>,
Dejan Lesjak <lesi@FreeBSD.org> and many others in our army of
developers.
直接関係ないけど、オラわくわくするぞ。
From: Kris Kennaway <kris@obsecurity.org>
To: announce@FreeBSD.org
Dear FreeBSD Users,
Within the next 24 hours, the long-awaited update to the X.org 7.2
windowing system will be committed to the ports tree. This upgrade
has been 6 months in the making and would not have been possible
without the dedicated work of Florent Thoumie <flz@FreeBSD.org>,
Dejan Lesjak <lesi@FreeBSD.org> and many others in our army of
developers.
直接関係ないけど、オラわくわくするぞ。
>>817
おお、ついに、、、。
おお、ついに、、、。
2007/05/20(日) 18:36:13ID:f6WzQrV60
>>818
でもXなので2chには直接は関係ないですね・・・・
でもXなので2chには直接は関係ないですね・・・・
ここ数週間portsがUPDATEされないと思ったら、今日すげー勢いでupdateされてるw
PHPも5.2.2もxorgも7.2にupdateされてる。
PHPも5.2.2もxorgも7.2にupdateされてる。
およ、んじゃ私も後でupdateしとこうかな。。
さて、6月15日までにmod_cacheですか。
まずはフロントでmod_mem_cacheあたりなのかなと。
設定例は、、、。
まずはフロントでmod_mem_cacheあたりなのかなと。
設定例は、、、。
っていうか、そういえば、
前に一回やろうとして、squid (BG3/4)が微妙な動きをしたんでしたっけ。
(ずいぶん前のことで、記憶があいまいだったり)
前に一回やろうとして、squid (BG3/4)が微妙な動きをしたんでしたっけ。
(ずいぶん前のことで、記憶があいまいだったり)
824stream ◆PNstream2s
2007/05/24(木) 22:41:34ID:JK5UOkEs0 2ch特化型サーバ・ロケーション構築作戦 Part20
http://qb5.2ch.net/test/read.cgi/operate/1140540754/119
以前の挑戦 2006/03/01 ?
http://qb5.2ch.net/test/read.cgi/operate/1145114275/262
これは結果が見つからなかった
んで今フロントのApacheは2.2.2のようですが、2.2.xで最も更新されてるジュールは
キャッシュ関連っぽいんで、携帯関連の副作用とは関係ないかもしれないけど
最新にしといたほうがいいかもしれません
更新履歴 http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/CHANGES
http://qb5.2ch.net/test/read.cgi/operate/1140540754/119
以前の挑戦 2006/03/01 ?
http://qb5.2ch.net/test/read.cgi/operate/1145114275/262
これは結果が見つからなかった
んで今フロントのApacheは2.2.2のようですが、2.2.xで最も更新されてるジュールは
キャッシュ関連っぽいんで、携帯関連の副作用とは関係ないかもしれないけど
最新にしといたほうがいいかもしれません
更新履歴 http://svn.apache.org/repos/asf/httpd/httpd/branches/2.2.x/CHANGES
>>822 mem_cache だと個別のプロセス単位のキャッシュになるんで,
1プロセスあたりのスレッド数を増やしてプロセス数を絞るとかしないと
効率が落ちると思います.なので,disk_cache を /md で使う方がいいのかも.
>>823 ですねぇ.Squid でキャッシュされた dat が更新されない状態でしたね.
んで,Age 等 mod_cache を使った場合に固有のヘッダが悪さしているのかと思い
mod_headers で Age を出さないようにしたものの,その状態は変わらなかった,
でとりあえず断念,というのが以前の経緯だったと.
例えば,Squid が Cache-Control: max-stale=xx のようなリクエストヘッダを
付けているなら起こり得なくもないんですが,果たしてわざわざそんなヘンな
リクエストをすることがあるのかということと,たとえ Squid がそうしていても
他の普通のリクエストで mod_cache が保持するキャッシュは更新されるはずなので,
やはりちょっと考えにくい...... まぁ,レスポンスヘッダで Cache-Control: s-maxage=xx
のようなのを付ければちゃんと更新してくれるかな......?
1プロセスあたりのスレッド数を増やしてプロセス数を絞るとかしないと
効率が落ちると思います.なので,disk_cache を /md で使う方がいいのかも.
>>823 ですねぇ.Squid でキャッシュされた dat が更新されない状態でしたね.
んで,Age 等 mod_cache を使った場合に固有のヘッダが悪さしているのかと思い
mod_headers で Age を出さないようにしたものの,その状態は変わらなかった,
でとりあえず断念,というのが以前の経緯だったと.
例えば,Squid が Cache-Control: max-stale=xx のようなリクエストヘッダを
付けているなら起こり得なくもないんですが,果たしてわざわざそんなヘンな
リクエストをすることがあるのかということと,たとえ Squid がそうしていても
他の普通のリクエストで mod_cache が保持するキャッシュは更新されるはずなので,
やはりちょっと考えにくい...... まぁ,レスポンスヘッダで Cache-Control: s-maxage=xx
のようなのを付ければちゃんと更新してくれるかな......?
んん?
なんでリブートが入ったのかしら?
9:08PM up 2 days, 3:09, 0 users, load averages: 0.10, 0.21, 0.21
@bbq
なんでリブートが入ったのかしら?
9:08PM up 2 days, 3:09, 0 users, load averages: 0.10, 0.21, 0.21
@bbq
cobra2245.maido3.com = bbq.2ch.net,hack72.2ch.net落ちてますね。
立て続けに2回ですか。
ううむ、dmesg的には異常ないですね。
しばらく経過観察で。
ううむ、dmesg的には異常ないですね。
しばらく経過観察で。
dmesgにはこれと言った出力はないもより(´・ω・`)
・・・と書こうとしていたところ♪
2 users になってた♪
$w
4:41AM up 3:34, 2 users, load averages: 0.54, 0.31, 0.24
・・・と書こうとしていたところ♪
2 users になってた♪
$w
4:41AM up 3:34, 2 users, load averages: 0.54, 0.31, 0.24
そしてbanana238も。。。(´・ω・`)
シグナルが飛んできていないからやっぱり電源が不安定なのかしら?
Rock54ご本尊様がリブートしなかった(´・ω・`)
May 30 23:08:03 <0.6> banana238 kernel: pid 2187 (httpd), uid 80: exited on signal 10
リブート後にこんな人がいたもより。。。
シグナルが飛んできていないからやっぱり電源が不安定なのかしら?
Rock54ご本尊様がリブートしなかった(´・ω・`)
May 30 23:08:03 <0.6> banana238 kernel: pid 2187 (httpd), uid 80: exited on signal 10
リブート後にこんな人がいたもより。。。
2007/05/31(木) 20:29:14ID:NmIFmYg+0
>>832
とりあえずJimさんにクランプメータでチェックしてほしい旨いっときました。
Let's talk with Jim-san. Part5
http://pie.bbspink.com/test/read.cgi/erobbs/1178546129/
とりあえずJimさんにクランプメータでチェックしてほしい旨いっときました。
Let's talk with Jim-san. Part5
http://pie.bbspink.com/test/read.cgi/erobbs/1178546129/
>>833
あっー♪
人為的リブートが入ったもよりですー♪
サーバーダウン(鯖落ち)情報 part148
http://qb5.2ch.net/test/read.cgi/operate/1177948183/257
あっー♪
人為的リブートが入ったもよりですー♪
サーバーダウン(鯖落ち)情報 part148
http://qb5.2ch.net/test/read.cgi/operate/1177948183/257
って事ですので単にSIGNAL(SIGTERM?)をうまくキャプチャできなかっただけかもです(苦笑)
local %SIG;
$SIG{'PIPE'} = $SIG{'INT'} = $SIG{'HUP'} = $SIG{'QUIT'} = $SIG{'TERM'} = &SigExit;
$SIG{'ALRM'} = "IGNORE";
sub SigExit{
unlink $Pid while -f $Pid;
die "$Prog has terminated.(Receive SIGNAL($_[0]))n";
}
今時のFreeBSDだと、whileでunlinkをループしなくても墜ちてくれるのかな?
local %SIG;
$SIG{'PIPE'} = $SIG{'INT'} = $SIG{'HUP'} = $SIG{'QUIT'} = $SIG{'TERM'} = &SigExit;
$SIG{'ALRM'} = "IGNORE";
sub SigExit{
unlink $Pid while -f $Pid;
die "$Prog has terminated.(Receive SIGNAL($_[0]))n";
}
今時のFreeBSDだと、whileでunlinkをループしなくても墜ちてくれるのかな?
2007/05/31(木) 21:26:13ID:NmIFmYg+0
えー・・・・Jimさんにはそちらからいってくださいorz
>>836
逝ってキタ━━━(゚∀゚)━━━ッ!!
逝ってキタ━━━(゚∀゚)━━━ッ!!
>>838
投稿時に単に文字化けしちゃっただけです(苦笑)
$SIG{'PIPE'} = $SIG{'INT'} = $SIG{'HUP'} = $SIG{'QUIT'} = $SIG{'TERM'} = \&SigExit
投稿時に単に文字化けしちゃっただけです(苦笑)
$SIG{'PIPE'} = $SIG{'INT'} = $SIG{'HUP'} = $SIG{'QUIT'} = $SIG{'TERM'} = \&SigExit
840ょぅι゙ょの見物人 ◆YoJo69//rM
2007/05/31(木) 23:40:51ID:AZQ97cqn0 Jimさんは事務ばっかりやってろと。
ひゅ〜るり〜〜〜〜〜〜ひゅ〜るり〜ららあ〜♪
ひゅ〜るり〜〜〜〜〜〜ひゅ〜るり〜ららあ〜♪
841NA1 ◆x..Fuck.FE
2007/06/01(金) 23:21:55ID:DTz/YXczP ( ´,_ゝ`)プッ
cobra2248退役しますー(^_^;)
843ピロリ今日も@株主 ★
2007/06/11(月) 15:34:11ID:6cQa3RJa0 今使ってないんですよね?
>>842
現在未使用です。データもmemoriesに退避済。
cobra2248.maido3.com (Opteron ??? dual (dual core)、??Bytes memory、FreeBSD 5.5R)
現在空き
FreeBSD 5.5R/amd64 GENERICカーネルで動作
現在シングルCPU設定の模様
現在未使用です。データもmemoriesに退避済。
cobra2248.maido3.com (Opteron ??? dual (dual core)、??Bytes memory、FreeBSD 5.5R)
現在空き
FreeBSD 5.5R/amd64 GENERICカーネルで動作
現在シングルCPU設定の模様
845ピロリ今日も@株主 ★
2007/06/11(月) 15:47:33ID:6cQa3RJa0 はーい、
どもでした。
ちょっと別の用途に改装して再登場の予定。
どもでした。
ちょっと別の用途に改装して再登場の予定。
んでは、cobra2248引き取ります(^_^;)
847[es] ◆MUMUMUhnYI
2007/06/12(火) 00:32:33ID:CfgGtuSr0 そんなわけで、
・httpdを更新する
・mod_mem_cacheを有効にする
という路線でいこうと思っているわけです。
この場合、
・有効にするのはフロント?バック?それとも両方?
・それぞれの場合、httpd.confをどう書いたらいい?
あたりを、ここに書いておいていただけると
とてもうれしかったりして。
・httpdを更新する
・mod_mem_cacheを有効にする
という路線でいこうと思っているわけです。
この場合、
・有効にするのはフロント?バック?それとも両方?
・それぞれの場合、httpd.confをどう書いたらいい?
あたりを、ここに書いておいていただけると
とてもうれしかったりして。
848[es] ◆MUMUMUhnYI
2007/06/12(火) 00:41:23ID:CfgGtuSr0 で、mod_disk_cacheにも限りない魅力を感じるのですが、
前にhtcachecleanが挙動不審だったので、
少し躊躇しているです。
でも、同様に設定サンプルがあると、うれしいかもです。
なんかくれくれですみませんです。
前にhtcachecleanが挙動不審だったので、
少し躊躇しているです。
でも、同様に設定サンプルがあると、うれしいかもです。
なんかくれくれですみませんです。
2007/06/12(火) 01:25:44ID:1bY0SzBD0
一応貼っておきます。
ttp://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1862
ttp://nvd.nist.gov/nvd.cfm?cvename=CVE-2007-1862
帰宅。
>>849
ううむ、ざっとしか読んでませんが
Apache 2.2.4のmod_mem_cacheはVulnerableで、
かつRemotely exploitableですか、、、。
だとすると、cの応用で、
squid等をローカルに動かしてみるとかか。
まずは、いったんめしで。
>>849
ううむ、ざっとしか読んでませんが
Apache 2.2.4のmod_mem_cacheはVulnerableで、
かつRemotely exploitableですか、、、。
だとすると、cの応用で、
squid等をローカルに動かしてみるとかか。
まずは、いったんめしで。
>>847-850 出張とかある中乙です......
Apache の mod_*_cache がいまいちということだと,確かに Squid の方が手堅いかもですね.
キャッシュさせる目的が dat 等の読み出しによるバックエンドの負荷を軽減させることであることからすると,
入れるのはフロントですね.
フロントの httpd -> バックエンドの dat 用 httpd
というのを
フロントの httpd -> フロントの Squid -> バックエンドの dat 用 httpd
という形にすると.
Apache の mod_*_cache がいまいちということだと,確かに Squid の方が手堅いかもですね.
キャッシュさせる目的が dat 等の読み出しによるバックエンドの負荷を軽減させることであることからすると,
入れるのはフロントですね.
フロントの httpd -> バックエンドの dat 用 httpd
というのを
フロントの httpd -> フロントの Squid -> バックエンドの dat 用 httpd
という形にすると.
852[es] ◆MUMUMUhnYI
2007/06/12(火) 02:18:50ID:oOEqiEVQ0 >>852 Squid -> httpd の部分は HTTP/1.0 になりますね.
もっとも,直接ユーザから見える部分ではないですけど.
で,その方向でやるとすると,httpd では
RewriteRule ^/(\w+/(?:|subject\.txt|(?:subback|index)\.html|index\.css|dat/(?:\d+\.dat)?))$ http://live23.2ch.net:pppp/$1 [P]
の部分を
RewriteRule ^/(\w+/(?:|subject\.txt|(?:subback|index)\.html|index\.css|dat/(?:\d+\.dat)?))$ http://localhost:3128/$1 [P]
のようにして,Squid では
http_port 127.0.0.1:3128 defaultsite=live23.2ch.net
cache_peer private_addr_of_live23b parent port_of_httpd_for_dat 0 no-query originserver
refresh_pattern . 0 0% 0
collapsed_forwarding on
refresh_stale_hit 1
のようにするといいのかな...... まぁ,とりあえずじっk(ry
もっとも,直接ユーザから見える部分ではないですけど.
で,その方向でやるとすると,httpd では
RewriteRule ^/(\w+/(?:|subject\.txt|(?:subback|index)\.html|index\.css|dat/(?:\d+\.dat)?))$ http://live23.2ch.net:pppp/$1 [P]
の部分を
RewriteRule ^/(\w+/(?:|subject\.txt|(?:subback|index)\.html|index\.css|dat/(?:\d+\.dat)?))$ http://localhost:3128/$1 [P]
のようにして,Squid では
http_port 127.0.0.1:3128 defaultsite=live23.2ch.net
cache_peer private_addr_of_live23b parent port_of_httpd_for_dat 0 no-query originserver
refresh_pattern . 0 0% 0
collapsed_forwarding on
refresh_stale_hit 1
のようにするといいのかな...... まぁ,とりあえずじっk(ry
live23f5(squid挟み)
HTTP/1.1 200 OK
Date: Thu, 14 Jun 2007 17:45:56 GMT
Server: Apache/2.2.2
Content-Length: 3059
Content-Type: text/html; charset=shift_jis
X-Cache: MISS from tiger507.maido3.com
X-Cache-Lookup: MISS from tiger507.maido3.com:ぽわわ
Via: 1.0 tiger507.maido3.com:ぽわわ (squid/2.6.STABLE13)
Vary: Accept-Encoding
live23f4(直接)
HTTP/1.1 200 OK
Date: Thu, 14 Jun 2007 17:46:30 GMT
Server: Apache/2.2.2
Content-Length: 3059
Content-Type: text/html; charset=shift_jis
Vary: Accept-Encoding
HTTP/1.1 200 OK
Date: Thu, 14 Jun 2007 17:45:56 GMT
Server: Apache/2.2.2
Content-Length: 3059
Content-Type: text/html; charset=shift_jis
X-Cache: MISS from tiger507.maido3.com
X-Cache-Lookup: MISS from tiger507.maido3.com:ぽわわ
Via: 1.0 tiger507.maido3.com:ぽわわ (squid/2.6.STABLE13)
Vary: Accept-Encoding
live23f4(直接)
HTTP/1.1 200 OK
Date: Thu, 14 Jun 2007 17:46:30 GMT
Server: Apache/2.2.2
Content-Length: 3059
Content-Type: text/html; charset=shift_jis
Vary: Accept-Encoding
X-Cache: MISS from tiger507.maido3.com
X-Cache-Lookup: MISS from tiger507.maido3.com:ぽわわ
Via: 1.0 tiger507.maido3.com:ぽわわ (squid/2.6.STABLE13)
この3行を出させなくするには、どうしたらいいのかしら。
X-Cache-Lookup: MISS from tiger507.maido3.com:ぽわわ
Via: 1.0 tiger507.maido3.com:ぽわわ (squid/2.6.STABLE13)
この3行を出させなくするには、どうしたらいいのかしら。
# TAG: via on|off
# If set (default), Squid will include a Via header in requests and
# replies.
#
#Default:
# via on
これではないみたい。
# If set (default), Squid will include a Via header in requests and
# replies.
#
#Default:
# via on
これではないみたい。
header_access Via deny all
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
ふむ。これか。
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
ふむ。これか。
とりあえずできたかな。
ちょっとフロントに入れてみるか。
ちょっとフロントに入れてみるか。
入れた。様子を確認中。
>>854-859 乙です.以前未解決だった黒山羊問題もどうか,ってとこですかね......
動いていそうなので、負荷テスト。
live23f5 にだけ流し込み。
live23f5 にだけ流し込み。
しばらく見ていて問題ないようなら、
・お風呂に入る
・live23f1-f4にも同じ設定を入れる
・もとどおりフロントを5台にする
という方向で。
・お風呂に入る
・live23f1-f4にも同じ設定を入れる
・もとどおりフロントを5台にする
という方向で。
あとフロントのsquidはほとんどアクセスログとってないけど、
# for squid log rotate
0 0 * * * /usr/local/sbin/squid -k rotate
を入れるのを忘れないようにと。
# for squid log rotate
0 0 * * * /usr/local/sbin/squid -k rotate
を入れるのを忘れないようにと。
ログインいただいているようなので、
squid.conf を見られるようにしておきます。
チェックいただけると、とてもうれしいです。
squid.conf を見られるようにしておきます。
チェックいただけると、とてもうれしいです。
>>864 乙です.こちらで見た限りではいいんじゃないかと思います.
さて,これで実運用でどんな感じになるか,ってとこですか......
さて,これで実運用でどんな感じになるか,ってとこですか......
>>865
どもです。
daemontools配下にして、reniceを弾力的にできるようにしようと。
rtprioするのはちょっと不安なので、とりあえず-14(cフロントと同じ)で。
#!/bin/sh
exec 2>&1
#exec env - PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
# /usr/sbin/rtprio 31 setuidgid squid /usr/local/sbin/squid -D -N
exec env - PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
/usr/bin/nice -n -14 setuidgid squid /usr/local/sbin/squid -D -N
どもです。
daemontools配下にして、reniceを弾力的にできるようにしようと。
rtprioするのはちょっと不安なので、とりあえず-14(cフロントと同じ)で。
#!/bin/sh
exec 2>&1
#exec env - PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
# /usr/sbin/rtprio 31 setuidgid squid /usr/local/sbin/squid -D -N
exec env - PATH="/usr/sbin:/usr/bin:/bin:/usr/local/bin" \
/usr/bin/nice -n -14 setuidgid squid /usr/local/sbin/squid -D -N
いい感じかな。
この設定を全フロントに仕込もうかと。
この設定を全フロントに仕込もうかと。
ただし、とりあえず適用はlive23にだけ。
live24/news20(現在使用せず)は従来どおり。
live24/news20(現在使用せず)は従来どおり。
で、みんなでおんなじスレを読んでもらえば、
さらに効果が上がると。
なんていう皮算用で。
さらに効果が上がると。
なんていう皮算用で。
>>870 ですね.特に,同一ファイルに対する同時アクセスで効果が大きいってことで.
>>853 以外の主な squid.conf の設定
cache_mem 128 MB
maximum_object_size_in_memory 4096 KB
cache_replacement_policy heap GDSF
memory_replacement_policy heap LFUDA
cache_dir null /dev/null
logfile_rotate 3
memory_pools off
forwarded_for off
header_access Via deny all
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
cache_mem 128 MB
maximum_object_size_in_memory 4096 KB
cache_replacement_policy heap GDSF
memory_replacement_policy heap LFUDA
cache_dir null /dev/null
logfile_rotate 3
memory_pools off
forwarded_for off
header_access Via deny all
header_access X-Cache deny all
header_access X-Cache-Lookup deny all
フロント5台に対して >>872 を適用。
2007/06/15(金) 04:37:38ID:homxQgJI0
遅くまでお疲れ様です
>>874 乙です.
>>http://qb5.2ch.net/test/read.cgi/operate/1180971685/417-418n
そう言われればそうですね.まぁ,以前ダメだった原因はナゾのままですが......
>>http://qb5.2ch.net/test/read.cgi/operate/1180971685/417-418n
そう言われればそうですね.まぁ,以前ダメだった原因はナゾのままですが......
http://qb5.2ch.net/test/read.cgi/operate/1179399581/735-766n
Pragma: no-cache 対策として refresh_pattern に ignore-reload とか
入れた方がいいのかな.あとは,refresh_stale_hit をどうするか,か.
0 にすれば遅延は生じないけど,負荷とのトレードオフですからねぇ.
まぁ,お陰様で >>869 のグラフでも昨日までよりかなりフラットになってるけど.
Pragma: no-cache 対策として refresh_pattern に ignore-reload とか
入れた方がいいのかな.あとは,refresh_stale_hit をどうするか,か.
0 にすれば遅延は生じないけど,負荷とのトレードオフですからねぇ.
まぁ,お陰様で >>869 のグラフでも昨日までよりかなりフラットになってるけど.
2007/06/15(金) 23:34:02ID:405DQ2F30
live鯖スレが騒がしくなった
http://qb5.2ch.net/test/read.cgi/operate/1179399581/800
今 Nida070422 試したみたけど、投稿後のには Pragma はついていた。
http://qb5.2ch.net/test/read.cgi/operate/1179399581/757
の報告もあるくらいだから、janeがこれと同じタイミングでやれば
416になるのは間違いないとは思うのだけれど、
http://qb5.2ch.net/test/read.cgi/operate/1179399581/766
を見る限り、それだけじゃないっぽいのも確かっぽいのでむむむむ
http://qb5.2ch.net/test/read.cgi/operate/1179399581/800
今 Nida070422 試したみたけど、投稿後のには Pragma はついていた。
http://qb5.2ch.net/test/read.cgi/operate/1179399581/757
の報告もあるくらいだから、janeがこれと同じタイミングでやれば
416になるのは間違いないとは思うのだけれど、
http://qb5.2ch.net/test/read.cgi/operate/1179399581/766
を見る限り、それだけじゃないっぽいのも確かっぽいのでむむむむ
880stream ◆PNstream2s
2007/06/15(金) 23:56:11ID:V4emkufx0 >>879 そのあたりをどうするかは,ある意味ポリシーの問題でもありますね.
方向性としては2つあると思いますが,
1. refresh_stale_hit を 0 にして遅延をなくす.
2. refresh_stale_hit は 1 のままで,ブラウザ側で
書き込み後のリロードの際は1秒ぐらい間を空けてもらう.
1. は単純明快ですが,その代わりキャッシュの効率が低下しますね.
2. の方がキャッシュの効率はいいのですが,専ブラ作者さんの協力も必要,と.
とりあえず,今回の簡単なまとめ:
http://news22.2ch.net/test/read.cgi/liveplus/1180626141/759
759 : 株価【350】 △△ ◆cZfSunOs.U :2007/06/15(金) 23:41:10 ID:kXgE7+X60
まぁ,バックエンドがおおむね静かな状態だったことからすれば,キャッシュ導入によって
怒濤のような ROM の大群からバックエンドを守ることができたという点で前進だと思います.
ただ,Squid のチューニングに十分時間が取れないまま本番を迎えたので,
メモリ大量消費によりかなり swap が発生してしまった,というのを改善するのが今後の課題ですね.
方向性としては2つあると思いますが,
1. refresh_stale_hit を 0 にして遅延をなくす.
2. refresh_stale_hit は 1 のままで,ブラウザ側で
書き込み後のリロードの際は1秒ぐらい間を空けてもらう.
1. は単純明快ですが,その代わりキャッシュの効率が低下しますね.
2. の方がキャッシュの効率はいいのですが,専ブラ作者さんの協力も必要,と.
とりあえず,今回の簡単なまとめ:
http://news22.2ch.net/test/read.cgi/liveplus/1180626141/759
759 : 株価【350】 △△ ◆cZfSunOs.U :2007/06/15(金) 23:41:10 ID:kXgE7+X60
まぁ,バックエンドがおおむね静かな状態だったことからすれば,キャッシュ導入によって
怒濤のような ROM の大群からバックエンドを守ることができたという点で前進だと思います.
ただ,Squid のチューニングに十分時間が取れないまま本番を迎えたので,
メモリ大量消費によりかなり swap が発生してしまった,というのを改善するのが今後の課題ですね.
882reffi@報告人 ★
2007/06/16(土) 00:52:49ID:???0 Squid関連で面白い記事が見つかったので
ttp://d.hatena.ne.jp/yamaz/20061015
ttp://d.hatena.ne.jp/yamaz/20061026
ttp://d.hatena.ne.jp/yamaz/20061015
ttp://d.hatena.ne.jp/yamaz/20061026
883stream ◆PNstream2s
2007/06/16(土) 01:02:45ID:WHOQe+e20 RFCで実際どのように規定されてるかは知りませんが
Pragma: no-cache と If-Modified-Since が同時に設定されてる場合
Apacheは(Squidも?) If-Modified-Since は実質的に無視されるから
416になるのはまあ当たりまえだね
んで普通にリロードしてて416になるのもあって、これはなんだろうね?
今重くて実験にならないけど
Pragma: no-cache と If-Modified-Since が同時に設定されてる場合
Apacheは(Squidも?) If-Modified-Since は実質的に無視されるから
416になるのはまあ当たりまえだね
んで普通にリロードしてて416になるのもあって、これはなんだろうね?
今重くて実験にならないけど
884stream ◆PNstream2s
2007/06/16(土) 01:19:18ID:WHOQe+e20 これはあくまでも予想ですが…
2chブラウザに 更新時刻 00:00:04 の100バイトのdat
Squidに 更新時刻 00:00:01 の50バイトのdat
バックエンドに 更新時刻 00:00:04 の100バイトのdat
このときJaneは
Range: bytes=100-
If-Modified-Since: 00:00:04
をSquidにリクエストするけど、Squidが持ってるのは00:00:01だから
Range: bytes=100-
If-Modified-Since: 00:00:01
をバックエンドにリクエストしてるのかな?
2chブラウザに 更新時刻 00:00:04 の100バイトのdat
Squidに 更新時刻 00:00:01 の50バイトのdat
バックエンドに 更新時刻 00:00:04 の100バイトのdat
このときJaneは
Range: bytes=100-
If-Modified-Since: 00:00:04
をSquidにリクエストするけど、Squidが持ってるのは00:00:01だから
Range: bytes=100-
If-Modified-Since: 00:00:01
をバックエンドにリクエストしてるのかな?
■ このスレッドは過去ログ倉庫に格納されています
ニュース
- 山陽新幹線で乗客が非常ボタン 車掌に切符の問い合わせしようと [蚤の市★]
- 【テレビ】中居正広出演『ザ!世界仰天ニュース4時間SP』日テレ「現時点で変更の予定はございません」★2 [Ailuropoda melanoleuca★]
- 「被告と事件前に不倫していた」“旭川17歳女子高生殺害”内田梨瑚(22)と禁断不倫のX警部補、ひそかに退職 [おっさん友の会★]
- 【新潟】「薪ストーブが燃えている」住宅火災で1棟全焼 [シャチ★]
- 【お菓子】ロッテ「クーリッシュ 飲む贅沢練乳」発売、“まるで練乳チューブを直飲み”したよう [おっさん友の会★]
- 生活保護の受給者、週15時間から20時間の労働活動が義務付けられることが決まる、180万人の生活保護 2025年フランス ★4 [お断り★]