何でも掲示板一括表示
［表示範囲：91〜141］［スレッドモード］

フォロー記事投稿

記事のキャンセル

8月23日に、夢職人さんは書きました。

＞事務所からメールが来た
＞混雑による、サーバー高負荷だってさ(^^;)
＞うっそだー(^^;)
＞
よくも、meshがぬけぬけとそんなことを言ったのですか？

昨日の深夜、３時頃、負荷が、１を切っているのに、
なかなか、繋がらなくて、いらいらしてたのに。

フォロー記事投稿

記事のキャンセル

8月23日に、まじんさんは書きました。

＞8月23日に、夢職人さんは書きました。
＞
＞＞事務所からメールが来た
＞＞混雑による、サーバー高負荷だってさ(^^;)
＞＞うっそだー(^^;)
＞＞
＞よくも、meshがぬけぬけとそんなことを言ったのですか？
＞
＞昨日の深夜、３時頃、負荷が、１を切っているのに、
＞なかなか、繋がらなくて、いらいらしてたのに。
＞
どうも情報を出そうと言うつもりが無いようですね。

ユーザ側から分かる情報はごくわずかですが、それでもサーヴァ負荷などが通常と
変わらなかった事は分かるのにね〜

少なくとも各種ログファイルから分かる情報としては、22日の13:23にシステム管理者が
サーヴィス端末からログインし、13:27にサーヴァプロセスがリスタートされている事ですね。

その結果アクセス状況は劇的に改善されました。それは１分ごとのアクセス数を見ても
明らかです。以下は昨日(8/22)のアクセス状況のグラフです。リスタートの結果、回復
しているのが見て取れます。



問題はどこをいじってリスタートしたのか？何ですが、これが良く分からない。
少なくともサーヴァの設定ファイルはいじってないのでどこか他の所だと思うのですが...

夢さんがクレームメール出した、って聞いたので、何か分かるかな〜 と思ってたんですが。(;_;)
＃ 単なるリスタートで済むんなら簡単ですが。ユーザにだって出来るし。

フォロー記事投稿

記事のキャンセル

ftpアクセスができない(^^;)
一体何がおこってんだ？

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　夢職人

フォロー記事投稿

記事のキャンセル

8月29日に、夢職人さんは書きました。

＞ftpアクセスができない(^^;)
＞一体何がおこってんだ？
＞
ftpd自体は正常に動いていますね。
＃ にあも今日になってから何回も繋いでいます。

でも夢さんが昨日から今日にかけて接続したftpdが6個切れずに残っています。
夢さんがftpで入ろうとしても "FTP LOGIN REFUSED (bad shell)" になっていますね。

うーん、システムの設定ファイルが読めるともうチョット何が起こっているのか判ると
思うのですが、一般ユーザモードではこのぐらいしか見えないですね。いずれにせよ、
ユーザ側では対処の方法が無いと思うので、障害受け付けに電話して切ってもらうしか
無いんじゃないかしら？

＃ 切れているはずのftpdが残ってしまう現象は、meshと同じwu-ftpd-2.4を使っている
＃ うちでもときどき起こっています。ホントはタイムアウトするはずなんだけど...
＃ うちでは頻度が低いので気が付くと手動で切っていますが、チャンと原因を
＃ 突き止めた方が良いんですよね。面倒だからやってないけど。(^^;;

フォロー記事投稿

記事のキャンセル

8月29日に、にあさんは書きました。

＞8月29日に、夢職人さんは書きました。
＞
＞＞ftpアクセスができない(^^;)
＞＞一体何がおこってんだ？
＞＞
＞ftpd自体は正常に動いていますね。
＞＃ にあも今日になってから何回も繋いでいます。
＞
＞でも夢さんが昨日から今日にかけて接続したftpdが6個切れずに残っています。
＞夢さんがftpで入ろうとしても "FTP LOGIN REFUSED (bad shell)" になっていますね。
＞
＞うーん、システムの設定ファイルが読めるともうチョット何が起こっているのか判ると
＞思うのですが、一般ユーザモードではこのぐらいしか見えないですね。いずれにせよ、
＞ユーザ側では対処の方法が無いと思うので、障害受け付けに電話して切ってもらうしか
＞無いんじゃないかしら？
＞
＞＃ 切れているはずのftpdが残ってしまう現象は、meshと同じwu-ftpd-2.4を使っている
＞＃ うちでもときどき起こっています。ホントはタイムアウトするはずなんだけど...
＞＃ うちでは頻度が低いので気が付くと手動で切っていますが、チャンと原因を
＞＃ 突き止めた方が良いんですよね。面倒だからやってないけど。(^^;;

ふむ(^^;)了解
あぅう(^^;)

フォロー記事投稿

記事のキャンセル

すいません、またリミッター伸ばして下さい(^^;)
たぶん先月より悪化してます(笑）＞にあさん
＃一日平均３５０アクセスー平均１５０ＭＢだうーん(^^;)

　　　　　　　　　　　　　　　　　　　　　　夢職人

フォロー記事投稿

記事のキャンセル

8月30日に、夢職人さんは書きました。

＞すいません、またリミッター伸ばして下さい(^^;)
＞
了解です。５時間にしておきました。
＃ そこまではかからないとは思うけど。(^^;;

＞たぶん先月より悪化してます(笑）＞にあさん
＞＃一日平均３５０アクセスー平均１５０ＭＢだうーん(^^;)
＞
それはたいそう「悪化」していますね。(^^)(^^)

この頃、ホスト名の圧縮リストを増やしたので、以前よりは "何とか-ppp1234" 見たいな
無意味な名前は減っていると思います。そのうちオプションで表示する項目を選べるように
しますが。（って、懸案事項ばかりスタックされていく〜）(笑)

フォロー記事投稿

記事のキャンセル

昼頃つないで、いやにサーヴァが重いな〜 と思っていた。
夕方つないでもまだ重かったので、どうしたのかな、と思っていたら
突然ふっと、軽くなった。

見てみると、案の定、サーヴァプロセスがリスタートされていた。

うーん、リスタートも良いけど、原因を突き止めるのが先決だと思うぞ。＞ Mesh

フォロー記事投稿

記事のキャンセル

8月30日に、にあは書きました。

＞見てみると、案の定、サーヴァプロセスがリスタートされていた。
＞
これがアクセスカウントの状態です。リスタートは 8/30 17:43 ですね。

フォロー記事投稿

記事のキャンセル

月の統計とりおわりました。
あれ？８月１日分が無い(^^;）
まわっちゃってたかな。まあ、いいか(^^;)

予想通り凄まじいアクセス量が(^^;)
＃どこでサーバーが腐ってたかも一目一目瞭然つーのも(笑）

　　　　　　　　　　　　　　　　　　　　　　

フォロー記事投稿

記事のキャンセル

9月1日に、夢職人さんは書きました。

＞月の統計とりおわりました。
＞あれ？８月１日分が無い(^^;）
＞
どうもログ回転は手動でやっているようで、月ごとにやり方が違いますね。

ちゃんとした人がやると、抽出している最中のログも、後から加えてくれて
統計誤差が無い様になっているんですが、先月はログ回転した時点から後の
ログしか残っていませんでしたね。きっと、複数の人が管理をしているので、
どうしても資質による差が出てしまうのでしょうね。(^^;;

今月はまだ回転していないけど、どうなるのかな？

＃ 今月は忘れず月統計を取りました。(^^)

＞予想通り凄まじいアクセス量が(^^;)
＞＃どこでサーバーが腐ってたかも一目一目瞭然つーのも(笑）
＞
30日なんかも午後の間腐っていましたが、合計のログからは分からないですね。
＃ ハッ、気が付いていないだけで、実は毎日腐っているのかぁ？ (^^;;

フォロー記事投稿

記事のキャンセル

どーも、変なところから回してくれたようで、
昨日の分のwwwstateはまともにとれんようですな(^^;)
あぅう(^^;)こんなの、文句もいえんし、なんだかなぁあ。
いかん、先日分残しとくべきだったよ(;;)

　　　　　　　　　　　　　　　　　　　　　　　　　夢職人

フォロー記事投稿

記事のキャンセル

9月4日に、夢職人さんは書きました。

＞どーも、変なところから回してくれたようで、
＞昨日の分のwwwstateはまともにとれんようですな(^^;)
＞
のようですねぇ。夕方、ログをテープに落としていましたからね。

しかし、毎月、五月分のWWW統計取っているのが、とっても謎。
＃ 何やっているんだ？？ (^^;;

フォロー記事投稿

記事のキャンセル

おひさしぶりです(^-^)/

9月4日に、にあさんは書きました。

＞＞昨日の分のwwwstateはまともにとれんようですな(^^;)
＞＞
＞のようですねぇ。夕方、ログをテープに落としていましたからね。
＞
＞しかし、毎月、五月分のWWW統計取っているのが、とっても謎。
＞＃ 何やっているんだ？？ (^^;;

ひさしぶりに来てみたらwwwstatの話が(^-^;
それってmeshがやってるんですか？それとも自前で入れて裏で処理させてるのかなぁ？

プロバイダのログってめちゃくちゃ大きい気がするんだけど、それでwwwstatやるとなると、
めちゃくちゃ時間かかりません？(^-^;

うちのサーバはwwwstatやめてaccesswatchにしました〜

＃もしかしてにあさんってmeshの方？

ところでmeshでアクセス制御ってできるんですか？(.nsconfigとか使って...)
CGIやcookieでパスワード受けて・・・ってのはできるんだけど、
なんとなく格好悪いので(笑)

フォロー記事投稿

記事のキャンセル

9月4日に、かん(管理人)さんは書きました。

＞＞＞昨日の分のwwwstateはまともにとれんようですな(^^;)
＞＞のようですねぇ。夕方、ログをテープに落としていましたからね。
＞＞しかし、毎月、五月分のWWW統計取っているのが、とっても謎。
＞＞＃ 何やっているんだ？？ (^^;;
＞ひさしぶりに来てみたらwwwstatの話が(^-^;
＞それってmeshがやってるんですか？それとも自前で入れて裏で処理させてるのかなぁ？
＞
えーと、両方です。(^^)

夢さんが言ってたのは、にあのMeshNetユーザ専用ペーヂでやっているWWW統計 (wwwstat改を
使っています) の事ですが、五月分云々と言うのはシステムでやっているWWW統計の話です。

システムがやったアクセスログ回転がタコなので、WWW統計に誤差（と言うか欠落）が
出てしまった、と言う嘆きです。(^^)

＞プロバイダのログってめちゃくちゃ大きい気がするんだけど、それでwwwstatやるとなると、
＞めちゃくちゃ時間かかりません？(^-^;
＞
生にアクセスログを wwwstat に食わせると半端じゃなく時間がかかりますね。
システムが 9/1 に始めたWWW統計は現在(9/4 23:30)になっても終わっていません。(^^;;
既に CPUタイムを 48時間近く消費しています。(*_*)

なおかつそのWWW統計の元データと言うのが、五月のアクセスログなので、何やっているの？？
と言う事なのです。

始めたのが 9/1 と休日なので、おそらく大昔にかけた cron の設定がそのままになっていて
忘れているんじゃないのか？と思うんですが。先月も先々月も同じ事していたような気がするし。
＃ 設定消し忘れてないかい？ ＞ Mesh

にあのペーヂでやっているサーヴィスは、各個人のペーヂに対するアクセスのみを抽出して
から行なっているので、そこまで時間はかかりませんが、夢さんとこみたいに恐ろしくアクセス数が
多いペーヂの場合は月統計を取ったりすると相当かかりますね。
＃ 今月は、三時間半以上かかっています。(^^;; ＞ 夢さん

毎日の統計はそんな恐ろしいことにはなりませんが。（ひどくとも数十分）

＃ あ、そうそう、この頃システムが前日のログ抽出をしてくれているみたいです。
＃ しばらく観察していたのですが、cron で定時に抽出されているようですので、
＃ そろそろ前日の場合は、これを使うように変更したいと思います。ここしばらく、
＃ 自分の統計はこの抽出ログを使っていたのですが、毎日大体１分そこそこでWWW統計が
＃ 済んでいます。これ使えば、前日のアクセスランキングなんかも簡単に出来るな〜 (^^)

＞うちのサーバはwwwstatやめてaccesswatchにしました〜
＞
うーん、ここで使っているやつは、名前圧縮したり、DNS自分で引いたりと、手を入れて
あるので、他のにかえるのは億劫ですね。(^^;;

＞＃もしかしてにあさんってmeshの方？
＞
いいえ、全然。(^^)

ですから、にあが知りうる情報は、１号機にアカウントを持っている人なら、誰でも
手に入れることが出来る物ばかりです。

＞ところでmeshでアクセス制御ってできるんですか？(.nsconfigとか使って...)
＞
Mesh のサーヴァの obj.conf には、

PathCheck file=".nsconfig" fn="load-config"

の行が無いので、ユーザペーヂでのアクセス制限は出来ないと思いますよ。

と言う事で、にあのペーヂでは...
＞CGIやcookieでパスワード受けて・・・ってのはできるんだけど、
＞なんとなく格好悪いので(笑)
＞
まさにこの、全て CGIってやつでアクセス制限しています。

＃ HTTP-cookie はクライアント側に plain text で記録されちゃうので、パスワードに
＃ 使うのは避けたのですが。あ、クライアント側でも何らかのコード化を行なえば、
＃ 多少は安全になるかな？ うーん、大して変わらないか。(^^;;

フォロー記事投稿

記事のキャンセル

9月5日に、にあさんは書きました。

＞夢さんが言ってたのは、にあのMeshNetユーザ専用ペーヂでやっているWWW統計 (wwwstat改を
＞使っています) の事ですが、五月分云々と言うのはシステムでやっているWWW統計の話です。

こっちではそゆことしてるのかぁ、www2aではmeshに関係ないのは、kingdomのサーバと
cannaserverくらいしか動いてなさそうな気が・・・(笑)

＞生にアクセスログを wwwstat に食わせると半端じゃなく時間がかかりますね。
＞システムが 9/1 に始めたWWW統計は現在(9/4 23:30)になっても終わっていません。(^^;;
＞既に CPUタイムを 48時間近く消費しています。(*_*)

うんうん、σ(^-^)も生ログをどうにかしてみようかな〜って思ったけど、うちのサーバでも
合計20ＭＢ近くあるから、こっち(mesh)はもっと凄いんだろうな〜と思ってやってません

＞なおかつそのWWW統計の元データと言うのが、五月のアクセスログなので、何やっているの？？
＞と言う事なのです。

ふみゅ〜、ほんとなにしてるんだろね？(^-^;

＞始めたのが 9/1 と休日なので、おそらく大昔にかけた cron の設定がそのままになっていて
＞忘れているんじゃないのか？と思うんですが。先月も先々月も同じ事していたような気がするし。
＞＃ 設定消し忘れてないかい？ ＞ Mesh

crontab見てみるとか〜(謎)

＞にあのペーヂでやっているサーヴィスは、各個人のペーヂに対するアクセスのみを抽出して
＞から行なっているので、そこまで時間はかかりませんが、夢さんとこみたいに恐ろしくアクセス数が
＞多いペーヂの場合は月統計を取ったりすると相当かかりますね。
＞＃ 今月は、三時間半以上かかっています。(^^;; ＞ 夢さん

ほほぉ、じゃあgrepかまして、wwwstatしてるん？(^-^;
それともperlか何かで切り分けながら処理してるのかな？
それでもなんとなく凄そう...

こういうのってmesh側でやってくれてもよさそうな気がするんだけど、アクセスが重いのと
か、meshとかkingdomとかごっちゃごちゃでわけわからんのとか、そういう状態見てると
頼んでも無理そうな所がなんか・・・(^-^;

＞＃ あ、そうそう、この頃システムが前日のログ抽出をしてくれているみたいです。

これってwww2aのもやってくれてるのかな？(・＿・;

＞うーん、ここで使っているやつは、名前圧縮したり、DNS自分で引いたりと、手を入れて
＞あるので、他のにかえるのは億劫ですね。(^^;;

ふみゅ、meshべったりな部分もあるだろうし面倒かもね(^-^;

＞ですから、にあが知りうる情報は、１号機にアカウントを持っている人なら、誰でも
＞手に入れることが出来る物ばかりです。

そかぁ、じゃあこっちもwww2aの方で頑張るしかないかぁ(^-^;

＞Mesh のサーヴァの obj.conf には、
＞PathCheck file=".nsconfig" fn="load-config"
＞の行が無いので、ユーザペーヂでのアクセス制限は出来ないと思いますよ。

あぅ、やっぱり無理なのかぁ
となると、自前で...

＞まさにこの、全て CGIってやつでアクセス制限しています。

こうするしかないんですね(^-^;

＞＃ HTTP-cookie はクライアント側に plain text で記録されちゃうので、パスワードに
＞＃ 使うのは避けたのですが。あ、クライアント側でも何らかのコード化を行なえば、
＞＃ 多少は安全になるかな？ うーん、大して変わらないか。(^^;;

コード化しても、そのクライアイントからアクセスすれば同じだし、cookieをコピーすれば
別のマシンからも使えるから、同じかも(笑)

フォロー記事投稿

記事のキャンセル

9月5日に、かん(管理人)さんは書きました。

＞こっちではそゆことしてるのかぁ、www2aではmeshに関係ないのは、kingdomのサーバと
＞cannaserverくらいしか動いてなさそうな気が・・・(笑)
＞
ほお、www2a でも kingdom が走っているのか、と思って調べてみたら、
kingdom-0〜kingdom-6 と言うのは、www2〜www2f(1号機〜7号機)に
寄生しているんですね。
＃ kingdom が寄生しているのは、1号機だけかと思ってた。(^^;;

＞crontab見てみるとか〜(謎)
＞
いや、さすがにその辺は読めないから。(^^)

＞ほほぉ、じゃあgrepかまして、wwwstatしてるん？(^-^;
＞
です。

＞ふみゅ、meshべったりな部分もあるだろうし面倒かもね(^-^;
＞
サイトに特有な部分は変数に追い込んであるんで良いんですが (実際、うちでも同じ
スクリプト使っている)、mesh はアクセスログのリモートホストを IP でしか記録
していないので、その辺を元に戻す処理とかあって面倒なんです。
＃ accesswatch とかは、DNS 引きもサポートしてくれるのかしら？

フォロー記事投稿

記事のキャンセル

9月6日に、にあさんは書きました。

＞＃ kingdom が寄生しているのは、1号機だけかと思ってた。(^^;;

うんうん、meshの1/3のプロセス数しか動かない様になってるみたいけど、じゃま(笑)

＞＞ほほぉ、じゃあgrepかまして、wwwstatしてるん？(^-^;
＞＞
＞です。

あぅ、grepかましてみたら、毎日のログしかなかった(/_;)
どこかに過去のログってあるのかなぁ？
できればここでもaccesswatch使ってみたいぃぃぃ(^-^;

フォロー記事投稿

記事のキャンセル

9月9日に、かん(管理人)さんは書きました。

＞あぅ、grepかましてみたら、毎日のログしかなかった(/_;)
＞どこかに過去のログってあるのかなぁ？
＞
過去ログって、先月のログのこと？
例えば１号機だと、一ヶ月のログは約800MBだから... (爆)

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞過去ログって、先月のログのこと？
＞例えば１号機だと、一ヶ月のログは約800MBだから... (爆)

2号機は1日50〜100Mだから1ヶ月は.....(^-^;ははは
でも、欲しいものは欲しいのだぁぁ(笑)←わがままかも

せめて前日のログでもいいから欲しいなぁ〜
よく調べてないけど、もうひとつログがあった気がする....調べてみよっと

フォロー記事投稿

記事のキャンセル

9月10日に、かん(管理人)さんは書きました。

＞2号機は1日50〜100Mだから1ヶ月は.....(^-^;ははは
＞でも、欲しいものは欲しいのだぁぁ(笑)←わがままかも
＞せめて前日のログでもいいから欲しいなぁ〜
＞
２号機はそんなにアクセスがあるんですか！
それでは毎日消されても仕方がないかもね。

＃ やっぱり、カウンタ利用でもダントツ１位のあのペーヂですか？(^^;;

フォロー記事投稿

記事のキャンセル

9月10日に、にあさんは書きました。

＞２号機はそんなにアクセスがあるんですか！
＞それでは毎日消されても仕方がないかもね。

さっきみてきたら、10Mも行ってなかったみたい
先週は80MBあったみたいだけど、今週はこんなものなのかな？
最近は重くなる事も少ないし、アクセスする人が減ったとか(･_･;
あ、夏休みが終わったからかも(笑)

＞＃ やっぱり、カウンタ利用でもダントツ１位のあのペーヂですか？(^^;;

うーん、それは調べてみないとわからないです(^-^;

σ(^-^)プログラムは作るけど、コマンド知らないので、簡単なコマンドでログ中の最大出現数を
調べられるんだったら教えて〜(笑)

そいえば、nph-npcってログに残らないんだよね？
さっきgrepしてみたら、"GET /~nir/cgi-bin/nph-npc.cgi?L=/...."って出てきたので
ちょっと不思議に思ってみたりする(･_･;

フォロー記事投稿

記事のキャンセル

9月10日に、かん(管理人)さんは書きました。

＞そいえば、nph-npcってログに残らないんだよね？
＞さっきgrepしてみたら、"GET /~nir/cgi-bin/nph-npc.cgi?L=/...."って出てきたので
＞ちょっと不思議に思ってみたりする
＞
２号機に /~nir/cgi-bin/nph-npc.cgi は無いので(^^)、それは誰かが間違ってアクセス
したのが、エラーとして記録されているのでしょう。
"GET /~nir/... HTTP/1.0" 404 nnn みたいになってたんじゃ無いでしょうか？
                         ^^^
＃ 先日のサーヴァエラーの頻発で、昨日、一昨日とアクセス数が１万越えてる。(^^;;
＃ 半分以上は npc.cgi アクセスのサーヴァエラー (爆)

フォロー記事投稿

記事のキャンセル

9月10日に、にあさんは書きました。

＞２号機に /~nir/cgi-bin/nph-npc.cgi は無いので(^^)、それは誰かが間違ってアクセス
＞したのが、エラーとして記録されているのでしょう。
＞"GET /~nir/... HTTP/1.0" 404 nnn みたいになってたんじゃ無いでしょうか？

あぅ、そこまで気をつけて見てなかった(^-^;

そかそか、そゆエラーはエラーログには残らないのかぁ(笑)
not foundは残るのにね(･_･;(謎)

フォロー記事投稿

記事のキャンセル

9月5日に、にあは書きました。

＞＃ あ、そうそう、この頃システムが前日のログ抽出をしてくれているみたいです。
＞＃ しばらく観察していたのですが、cron で定時に抽出されているようですので、
＞＃ そろそろ前日の場合は、これを使うように変更したいと思います。ここしばらく、
＞＃ 自分の統計はこの抽出ログを使っていたのですが、毎日大体１分そこそこでWWW統計が
＞＃ 済んでいます。これ使えば、前日のアクセスランキングなんかも簡単に出来るな〜 (^^)
＞
そういえば、9日の事故以来、システム側による前日のログ抽出が止まったまま
なんだけど、やめちゃったのかな〜

これ使って、色々やろうかと目論んで居ただけに、止めちゃったんならチョット残念。

フォロー記事投稿

記事のキャンセル

昨日(9/6)はいやにアクセスが多かったな。サーヴァ全体で38万アクセス近くあるし...
と思ってサーヴァを見てみたところ、大きな変更が加えられていました。

ここ、１号機の名前は www2.meshnet.or.jp ですが、これは meshsv14.tk.mesh.ad.jp と
言うマシンに付けられた別名だと言う事はご存じの方も多いと思います。

今回 meshsv14 以外に、新たに meshsv14-1、meshsv14-2、meshsv14-3 と言うマシンが
設置されて、そのどれにも www2.meshnet.or.jp と言う別名が付けられました。

つまり、www2.meshnet.or.jp にアクセスした人は、その時々によって、meshsv14 〜
meshsv14-3 と言う４台のマシンに振り分けられて負荷分散が計れるわけです。

ところが、ここで meshsv14 〜 meshsv14-3 と言う４台のマシンのうち meshsv14 以外の
マシンは全て仮想マシンで、実の所全て meshsv14 であるここを使っています。
＃ これは、kingdom-0 が、実はここだと言うのと同じ事です。

また、４台のマシンともサーヴァ名には www2.meshnet.or.jp を使っていますから、
生に IPアドレスでも使わない限り、ユーザからはその違いは分かりません。

では、何故この様な面倒なことをするのか？と言うと、ここからは推測になるのですが、
アクセスが集中して接続しにくい時でもサーヴァのCPU負荷はさほどでもない。
同じ時に kingdom-0 は、程々にはつながることから、アクセス上限を決めてしまって
いるのはサーバの計算能力では無くネットワーク側である。と言う事から、ネットワークの
受け口を増やしたのでは無いかと思われます。(^^)

各サーヴァでは、50〜100 (meshsv14)、10〜30 (meshsv14-1〜meshsv14-3) のサーヴァ
プロセスが働きますので、最大プロセス数でも今までの 100 よりは増えていますね。

同様の事は、２号機についても行なわれていて、やはり３台の仮想マシンが追加されています。
３〜７号機については変更されていませんね。まだ、それほど重くなっていないのでしょうか？

まあ、これで少しはアクセス状況が改善されるのではないかと思われます。(^^)
良かった、良かった（となると良いなぁ）

フォロー記事投稿

記事のキャンセル

9月7日に、にあは書きました。

＞各サーヴァでは、50〜100 (meshsv14)、10〜30 (meshsv14-1〜meshsv14-3) のサーヴァ
＞プロセスが働きますので、最大プロセス数でも今までの 100 よりは増えていますね。
＞
今日の夕方から meshsv14-3 落としたり、プロセス数変えてリスタートしたりと、
色々いぢっていましたけど、結局 36プロセス(meshsv14〜meshsv14-2) と
10〜30プロセス(meshsv14-3) に落ちついたようです。

負荷分散と言う意味では、以前より真っ当になっているとは思いますが...

＃ これって、昨日の事故の原因が分からなくって、プロセス数を調整してごまかして
＃ いるつもりだったりしないよね？ しないって言って。(^^;;

フォロー記事投稿

記事のキャンセル

9月9日に、にあは書きました。

＞今日の夕方から meshsv14-3 落としたり、プロセス数変えてリスタートしたりと、
＞色々いぢっていましたけど、結局 36プロセス(meshsv14〜meshsv14-2) と
＞10〜30プロセス(meshsv14-3) に落ちついたようです。
＞
チョット設定を読み間違えていました。(^^;;

今日(9/11)の午前中にまた設定変更がありました。
最終的には meshsv14-1 と meshsv14-2 がそれぞれ 32プロセス、
meshsv14 と meshsv14-3 が合わせて 32プロセスになりました。
＃ meshsv14 と meshsv14-3 を一緒にしたのは 9日からだったようです。

結局、総プロセス数は変更前と変わらなくなったので、もしもアクセスが容易に
なったとすれば、いままでいかにネットワーク側がボトルネックになっていたか、
と言う証拠でしょう。
＃ ただで出来るんだから、早くやって欲しかったぞ。まあ、結果論ですが。(^^;;

フォロー記事投稿

記事のキャンセル

9月11日に、にあは書きました。

＞今日(9/11)の午前中にまた設定変更がありました。
＞最終的には meshsv14-1 と meshsv14-2 がそれぞれ 32プロセス、
＞meshsv14 と meshsv14-3 が合わせて 32プロセスになりました。
＞
今日(9/12)の未明にまた変更があって、meshsv14〜meshsv14-3全てが32プロセス
ずつになりました。変更した後しばらく、仮想メモリの統計情報を監視していたけど、
結局このままになったようなので、これで固定かな？ (^^)

フォロー記事投稿

記事のキャンセル

9月7日に、にあは書きました。

＞まあ、これで少しはアクセス状況が改善されるのではないかと思われます。(^^)
＞良かった、良かった（となると良いなぁ）
＞
Meshにしては珍しく、サーヴァをいじったことを、BiGlobeのTop Pageでアナウンスしていますね。
今回の変更は相当自信アリと見たぞ。(^^)

フォロー記事投稿

記事のキャンセル

１号機ＣＧＩ全滅ですね。
９割以上サーバエラーになっちゃいます。
自分のページの簡易ログ見ると１７時４５分が最後のアクセスに
なっています。もうだいぶ時間経つんですけどねー。
いつなおるのでしょう？(^^;)

フォロー記事投稿

記事のキャンセル

9月8日に、NKさんは書きました。

＞１号機ＣＧＩ全滅ですね。
＞９割以上サーバエラーになっちゃいます。
＞
ダメですね。
現在システムリソースがほとんど枯渇してしまっています。

$ pstat -T

1881/1888 files
736/1018 inodes
520/522 processes
358592/364436 swap

と言うすさまじい状態です。

＃ これだけ取るのもやっとで、具体的なプロセステーブルは取れていませんので
＃ どのプロセスが原因なのかが分かりません。(^^;;

これだと、既に走っているプロセスが応答する *.html 出力は可能でも、新たな
プロセス生成のある CGI は非常に実行し辛い(ほとんど実行できない)状態ですね。
FTP すら走らないからペーヂの更新も出来ない。

＞自分のページの簡易ログ見ると１７時４５分が最後のアクセスに
＞なっています。もうだいぶ時間経つんですけどねー。
＞いつなおるのでしょう？(^^;)
＞
システムサポートに電話したら、「現在この電話は非常に混雑しています。(プツ)」
だったので、既に状況は把握していると思うんですけどね。

＃ この状態で書き込むとは NK さんもヤリますですね。(^^)
＃ この記事は何回リトライしたら投稿できるかな？

フォロー記事投稿

記事のキャンセル

9月9日に、にあは書きました。

＞＃ これだけ取るのもやっとで、具体的なプロセステーブルは取れていませんので
＞＃ どのプロセスが原因なのかが分かりません。(^^;;
＞
プロセステーブルが取れました。
あるユーザのチャットスクリプトが原因でした。

プロセステーブルが取れた時点で 364 個も溜まっていました。
こちらで100個近く消したんで、今は CGI も普通に動いていると思いますが、
そのプロセスは、まだ今でも続々と生成されているようなので、また朝になるまでには
動かなくなるかも知れません。(^^;;

１号機のユーザなら、にあの MeshNet専用ペーヂでプロセスチェックすれば、
どのプロセスが原因になったかは、すぐ分かると思いますよ。なんと言っても
凄い量溜まっていますから。(^^;;

＃ さて、どうしたものでしょうかね〜

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞１号機のユーザなら、にあの MeshNet専用ペーヂでプロセスチェックすれば、
＞どのプロセスが原因になったかは、すぐ分かると思いますよ。なんと言っても
＞凄い量溜まっていますから。(^^;;
＞
＞＃ さて、どうしたものでしょうかね〜

ほんとに凄い量ですね。
meshが対処してくれなければ本人にmailするしか無いのかな。
Chatに割り込むとか。本人がいなければ意味ないですけど。

でも１ユーザーのCGIでここまで影響が出てしまうとは・・。
やっぱり慎重に扱ったほうがいいですね。CGIは。

フォロー記事投稿

記事のキャンセル

9月9日に、NKさんは書きました。

＞＞＃ さて、どうしたものでしょうかね〜
＞
＞ほんとに凄い量ですね。
＞meshが対処してくれなければ本人にmailするしか無いのかな。
＞
さっき見てみたら、相変わらず 350以上残ってたので、いい加減頭にきて
全部捨ててしまいました。

朝から何回もシステム管理者がログインしているのに何やっているんだ！
ちっとも危機的状況を理解出来ていないんじゃないか？

...と少し怒っています。(^^;;

＞でも１ユーザーのCGIでここまで影響が出てしまうとは・・。
＞やっぱり慎重に扱ったほうがいいですね。CGIは。
＞
ユーザがCGIを扱う時に注意深くする必要があるのは当然の事ですが、素人にCGIを
開放している以上、こう言うことが起こるのは絶対に避けられ無いのですから、
もっとシステムの安定性に気を配っていて欲しいです。

今回の事でも、プロセスが溜まり始めてからプロセステーブルが枯渇するまでには
半日以上あったわけですから、定期的にプロセスチェックして、まずくなったら
メールを出すようにしておくだけでも防げたはずなんですけどねぇ。
＃ まあ、休日に起こったことは考慮すべきとは思いますが。

ちょっとシステムの管理体制に不安の残る今日この頃でした。

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞＃　 さて、どうしたものでしょうかね〜

そのユーザーに、つっこみ入れるしかないんじゃないでしょうか(^^;)
プロセスリストみたら・・・むぅうだったし・・・
こんな理由で、せっかく軽くなったサーバー資源を重くしたくない(笑）

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞プロセステーブルが取れました。
＞あるユーザのチャットスクリプトが原因でした。

にあさん、NKさん、夢職人さん、こんにちわ。
すっかり、出遅れて、事象はよく飲み込んでませんが、
私のところにも、「動きませんメール」がいっぱい来ていましたので、
かなり酷い状態だったと想像してますが、

そのチャットスクリプトって、まさか、私のところではないですよね？
ま、私のところだったら、きっと、にあさんあたりがメールしてくれるとは
思うのだけど。甘いかな。

参考までに、どんなタイプのチャットスクリプトなのか、こっそり教えてもらえないでしょうか？プロセスリストを見てみましたが、
もう、それらしいのは発見できないのですが・・・

私のページでは、一応、チャットコーナーも主力コーナーで
一晩で、１０００ヒットを越えることもあるので、少し心配です。
自動リロードをしてないので、ましかなぁと思ってますが、
どんなものでしょうか？

フォロー記事投稿

記事のキャンセル

プロセスふえまくり(^^;)
場所はどこなんだろう。

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　夢職人

フォロー記事投稿

記事のキャンセル

9月9日に、まじんさんは書きました。

＞そのチャットスクリプトって、まさか、私のところではないですよね？
＞ま、私のところだったら、きっと、にあさんあたりがメールしてくれるとは
＞思うのだけど。甘いかな。
＞
いや、まじんさんではないです。(^^;;

まじんさんなら今頃袋叩き... ではなくて (^^;; 指摘のメールが行ってるはずです。

CGIスクリプトは、たぶんオリヂナルだと思います。
少なくとも、ペーヂオーナーの Copyright (C) が入っています。(^^)

チョット読んでみたところでは、れいの kingdom 事件とおなじ、ブロッキングモードの
ファイルロックが原因みたいです。ログを書く時ファイルロックしているんですが、
ブロッキングで排他処理していますね〜

＃ 頼むから、ファイルをロックするときはノンブロッキングでやってくれー

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞＞そのチャットスクリプトって、まさか、私のところではないですよね？

これってどんなのだか教えてほしいです(^-^;

σ(^-^)がお邪魔してる2号機の方でも以前スリープしてるのが原因で
めちゃくちゃ重くなった時があったみたいだしmeshって災難続きですね〜

そいえば、CGI用のサーバを立ち上げるって話がkingdomに書いてあった気が
するんだけど、あれってどうなったのかな？

＞＃ 頼むから、ファイルをロックするときはノンブロッキングでやってくれー

ふみゅ、それってどんなのか教えてください(^-^;

＃そいえばuidがwwwだと他のプロセスも殺せるのね(･_･;

フォロー記事投稿

記事のキャンセル

9月9日に、かん(管理人)さんは書きました。

＞＞＞そのチャットスクリプトって、まさか、私のところではないですよね？
＞
＞これってどんなのだか教えてほしいです(^-^;
＞
これは Mike Wheeler さんの Chatpro 1.1 と言うのを、まじんさんが日本語化した
物ですね。にあも一度まじんさん達とお話ししたことがありますが、なかなか良かった
ように思います。
＃ どうも、チャットにはまりそうだったので、以来近寄らない様にしてますが。(^^;;

まじんさんの倉庫で配布されていますよ。
＃ って、勝手に宣伝してしまってすいません。(^^;; ＞ まじんさん

フォロー記事投稿

記事のキャンセル

9月9日に、にあさんは書きました。

＞9月9日に、かん(管理人)さんは書きました。
＞
＞＞＞＞そのチャットスクリプトって、まさか、私のところではないですよね？
＞＞
＞＞これってどんなのだか教えてほしいです(^-^;
＞＞
＞これは Mike Wheeler さんの Chatpro 1.1 と言うのを、まじんさんが日本語化した
＞物ですね。にあも一度まじんさん達とお話ししたことがありますが、なかなか良かった
＞ように思います。
＞＃ どうも、チャットにはまりそうだったので、以来近寄らない様にしてますが。(^^;;
＞
＞まじんさんの倉庫で配布されていますよ。
＞＃ って、勝手に宣伝してしまってすいません。(^^;; ＞ まじんさん

いえいえ、宣伝ありがとう。とっても、嬉しいです。
あれは、一応、コンスタントにダウンロードだけは、されてるようです。
未だ、他で動いてるのをみたことはないけど。

ちなみに、かん（管理人）さんも、私のチャットコーナーには、
いらっしゃったことがあるので、
かん（管理人）さんが尋ねてるのは
今回の問題のチャットスクリプトなのかも知れません。

でも、せっかくですから、ここをご覧になっている方で、
チャットコーナーを作ろうかなと思っている方は一度検討してみて下さい。
この「うえっぶ会議室」同様、完成度の高いスクリプトだと思います。

フォロー記事投稿

記事のキャンセル

9月10日に、まじんさんは書きました。

＞ちなみに、かん（管理人）さんも、私のチャットコーナーには、
＞いらっしゃったことがあるので、
＞かん（管理人）さんが尋ねてるのは
＞今回の問題のチャットスクリプトなのかも知れません。

あ、そです、わかりにくくてごめんなさい(^-^;

＃サーバの引っ越しで疲れ中(爆)

フォロー記事投稿

記事のキャンセル

9月9日に、かん(管理人)さんは書きました。

＞＞＃ 頼むから、ファイルをロックするときはノンブロッキングでやってくれー
＞
＞ふみゅ、それってどんなのか教えてください(^-^;
＞
ファイルをロックする時のモードには、ロックできるまで待つブロッキングモードと
ロックできないときは待たずにエラーを返すノンブロッキングモードがあります。

もしブロッキングモードでファイルロックを行なっていると、何らかの事故でロックが
外れなくなったプロセスが出来た時、後から起動された同じファイルを必要とする
プロセスが、次から次へとロック待ちで止まってしまい、プロセステーブルを食い
つぶしてしまうことになります。

ノンブロッキングモードでロックしていれば、この様な場合、後から起動したプロセスは
エラーにはなっても、システムダウンへと導くような恐ろしいことは起きない訳ですね。

具体的にはここのスクリプトなどを見ていただければよろしいのですが、flock() を
LOCK_EX|LOCK_NB (=6) で呼んで、もしもその時ロックできなければ、少し待ってから
またロックしてみる、と言うのをくり返し、ある限度回数試みてもダメな時はエラーに
する、と言うような事をすれば良いと思います。

この限度回数（と言うか限度時間）はそのプロセスが呼ばれるであろう頻度と相談して
決める必要があります。例えば、1秒間に10回呼ばれるようなプロセスで、1分も待って
いたら、たちまちプロセスが溜まってしまいますから、チョットしたさじ加減が必要
でしょう。

フォロー記事投稿

記事のキャンセル

9月10日に、にあさんは書きました。

＞具体的にはここのスクリプトなどを見ていただければよろしいのですが、flock() を
＞LOCK_EX|LOCK_NB (=6) で呼んで、もしもその時ロックできなければ、少し待ってから
＞またロックしてみる、と言うのをくり返し、ある限度回数試みてもダメな時はエラーに
＞する、と言うような事をすれば良いと思います。

ふみゅみゅみゅ、なんとなく当たり前の様な気が(^-^;
つまり手抜きしてたってことなんね(笑)＞へんなスクリプト

σ(^-^)はリンク／アンリンクでする方が好き〜

フォロー記事投稿

記事のキャンセル

9月10日に、かん(管理人)さんは書きました。

＞ふみゅみゅみゅ、なんとなく当たり前の様な気が(^-^;
＞つまり手抜きしてたってことなんね(笑)＞へんなスクリプト
＞
まあ、一般ユーザの書いたスクリプトなら仕方がないかと諦めもつくんですが、
以前kindom本体が１号機にあった時には、(おそらく) 今回の事故と同じ事を、
システムの FreeTalk スクリプトが起こしてくれて、サーヴァが何度も止まりました。(^^;;

＃ キノトロープって言ったら、結構ちゃんとした所だと思うんですけどね。

フォロー記事投稿

記事のキャンセル

9月9日に、にあは書きました。

＞プロセステーブルが取れました。
＞あるユーザのチャットスクリプトが原因でした。
＞
先ほどサーヴァを見たらまた溜まっていました。(^^;;

今度は、プロセス数上限にはまだまだ余裕があったので、じっくり見て、最初に起動されていた
奴を 一つだけ 消したら、残り 50個ばかりが一気に消えてくれました。(^^)

と言う事で、原因はファイルロックアルゴリズムの欠陥と言うので、確定でしょう。

＃ そんな悠長なことやっていないで、早く Mesh なり、作者なりに連絡しろ、って？
＃ ハハハ、たとえ人のプログラムでも、バグと見ると原因を追究したくなってしまって。(^^;;

フォロー記事投稿

記事のキャンセル

http://host/cgi-bin/npc.cgi/~yasuf/foo.idx として呼び出すと
Cannot Open Index File "/home/yasuf/foo.idx/" とか言われた^^;;;;

とりあえず I= で設定してるけど、なんだかなぁ...

# 現在個人的に(笑)Spinnerで運用中
## テストしようとして http://host/~yasuf/hoge.cgi/uge とやったら Not Found だって(;_;) 当たり前か

フォロー記事投稿

記事のキャンセル

9月10日に、Yasu.Fさんは書きました。

＞http://host/cgi-bin/npc.cgi/~yasuf/foo.idx として呼び出すと
＞
と言う事で、npc.cgiの部屋に振りますね。

フォロー記事投稿

記事のキャンセル

とりあえず、平和になったようですね(笑）
やっぱり、まともに稼動してると軽いだわ(^^)

#でも最近はＡＰに繋がらなかったりする(涙)

　　　　　　　　　　　　　　　　　　　　　　　　　　　　　夢職人

以上51記事（キャンセル分を含む）

ホームペーヂに戻る