いよいよ3回目

いよいよ第3回となってきました。
今回は、各システムにFeedで受信した飛行機情報を提供する設定を行う。
それでは、今回も行って見よう！！

第1回・第2回を読まれていない方は、先にそちらを読んでみて下さい。

受信したデータの提供（Feed設定）

受信環境が整ったので、受信したデータを各サービスに提供すべき設定を行って行きます。
提供先は、下記の2つにデータを送る為設定を進めます。

・flightAwarc
・flightradar24

どちらのサービスにも、最初にアカウントを作成しておいてください。

まずは、flightAwarcに送る設定を行う

どうも、順番をこちらを先に設定する方が良いとされる為、先に設定しちゃいましょう。
今回構築したラズパイにSSHでログインします。

$ sudo apt update
$ sudo apt install piaware

上記を実行してください。正常にインストールされたら下記を実行しておいてください。

$ sudo piaware-config allow-auto-updates yes
$ sudo piaware-config allow-manual-updates yes

設定はこれで終了です。
上手く転送されているか？確認するには下記を実行します

sudo cat /var/log/piaware.log

上記ログを見ると、初回データを送付した際に、
feederID(********-****-****-****-************の部分)が記録されるので、そちらを書き留めておいてください。
サンプル－＞Aug 17 17:09:13 ads-s piaware[590]: my feeder ID is 1fedfdsfsd5723-615f-5371-a6c8-55fefdsfdsfsdf801f0

続いて、下記にAccessします。そちらで紐付けが行えます。
https://flightaware.com/adsb/piaware/claim/<my feeder ID >
例>https://flightaware.com/adsb/piaware/claim/1fedfdsfsd5723-615f-5371-a6c8-55fefdsfdsfsdf801f0

接続したネットワークにファイヤーウォールがいる場合

接続しているネットワークにファイヤーウォールがいる場合、
筆者の環境は物理ファイヤーウォールを設置している為、当初通信が阻害されてステータスが一向に変わらず
これ、ファイヤーウォールにブロックされていないか？を確認したところ、がっつりブロックされていた。
一般の方は、問題無いかも知れませんが、特殊環境の場合ご注意を！！
下記のようにPort：1200をあけてあげましょう。

2024/08/22追記
MLATの情報Feedには、これにくわえて下記を開ける必要がある。
送信先:piaware.flightaware.com 　パケットタイプ: UDP / Port:4999-19999

動作確認

下記にアクセスすると、Feedの統計が見れます。
https://www.flightaware.com/adsb/stats/user/ <USER NAME>

process監視を行うなら

ps -ef | grep "piaware.pid" | grep -v grep

上記コマンドを流すと下記の用に1件ヒットすると思います。
そちらを使ってZabbixなどで、process監視を行って、processダウン等はトリガー引っかけて
自動再実行等のアクションを入れるとよいと思います。

piaware      590       1  0 Aug17 ?        00:03:50 /usr/bin/piaware -p /run/piaware/piaware.pid -plainlog -statusfile /run/piaware/status.json

flightradar24にFeedを送る

sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"sudo bash -c "$(wget -O - https://repo-feed.flightradar24.com/install_fr24_rpi.sh)"

シェルがキックされて、インストールが行われます。
その最中下記の質問事項が対話式で出てくるので、それぞれを入力してください。

入力に必要な物を先にパラメーターとして、準備しておいてください。
・観測点の緯度経度　－＞　https://fukuno.jig.jp/app/map/latlng/
・メールアドレス

Step 1.1 - Enter your email address (username@domain.tld)
$:＜★flightradar24で使うメールアドレスを入力＞ Enter

Step 1.2 - If you used to feed FR24 with ADS-B data before, enter your sharing key.
If you don't remember your sharing key, you can find it in your account on the website under "My data sharing".
https://www.flightradar24.com/account/data-sharing

Enter your sharing key or press ENTER/RETURN to continue.
$:＜★新規の方はこちらは入力せず（過去の環境を引継ぐならアカウントIDを入力する）＞ Enter

Step 1.3 - Would you like to participate in MLAT calculations? (yes/no)$:
＜★MLATのサービスを使うかどうか？の設定で、他のサービス（flightAwarcなど）に情報共有してる場合は "no" を入れる＞ Enter

※筆者の環境がPeerなのか、MLATのflightradar24のprocessと使用ポートがバッティングして
　サービスが開始できないので、ちょっと工夫しないとMLATの同居は無理そう。

Step 3.A - Enter antenna's latitude (DD.DDDD)
$:＜★受信場所の緯度を入力する　ex: 35.????＞ Enter

Step 3.B - Enter antenna's longitude (DDD.DDDD)
$:＜★受信場所の経度を入力する ex: 139.????＞ Enter

Step 3.C - Enter antenna's altitude above the sea level (in feet)
$:＜★受信場所の標高一般住宅ならアンテナ設置までの高さ（フィートで入れる） ex:30＞ Enter

Using latitude: 35.????, longitude:139.????, altitude: ??ft above sea level
Validating email/location information...OK

The closest airport found is ICAO:RJTT IATA:HND near Tokyo.

Latitude: 35.552250
Longitude: 139.779602
Country: Japan

Flightradar24 may, if needed, use your email address to contact you regarding your data feed.

Would you like to continue using these settings?
Enter your choice (yes/no)$:＜★設定値確認なので問題無ければ "yes"＞ Enter

We have detected that you already have a dump1090 instance running. We can therefore automatically configure the FR24 feeder to use the existing receiver configuration, or you can manually configure all the parameters.

Would you like to use autoconfig (*yes*/no)$:＜★dump1090-fa が同居し稼働してる場合 "yes"を入力する＞ Enter

Submitting form data...OK

Congratulations! You are now registered and ready to share ADS-B data with Flightradar24.
+ Your sharing key (★※ここにキーが表示されるので書き留めておいてください※) has been configured and emailed to you for backup purposes.
+ Your radar id is ★T-※radar-ID※が表示される。こちらも書き留めておいてください, please include it in all email communication with us.
+ Please make sure to start sharing data within one month from now as otherwise your ID/KEY will be deleted.

Thank you for supporting Flightradar24! We hope that you will enjoy our Premium services that will be available to you when you become an active feeder.

To start sending data now please start the fr24feed daemon again by running the following command: sudo systemctl start fr24feed!

Saving settings to /etc/fr24feed.ini...OK
Settings saved, attempting to enable and start the fr24feed service
Enabled fr24feed service...OK
Restarted fr24feed service...OK
All done, you can check the status by using the fr24feed-status command

Starting the fr24feed service, it may take a while if dump1090 needs to be installed...
Installation and configuration completed!

※上記 completed!が表示されれば、設定を完了したことを示す
　途中でてきたキーやIDについては、後ほどメールで送られてくるが、
　念の為書き留めておいてください。

差出人名: Flightradar24 Support / subject： Your Flightradar24 sharing key

動作確認

ブラウザで下記でAccessする。
http://ラズパイのIPアドレス:8754

上記のような画面が出れば、現在Feedしている数等も表示されているので、上手く動作しているか確認出来ます。
続いて、アカウントとFeedを紐付けを行います。

下記のURLに接続します。
https://www.flightradar24.com/account/data-sharing

上記画面に設定時、表示されいてるradarIDやキーが表示されて、
オンラインと表示されている事を確認してください。
Online No dataになっているかも知れませんが、いったんOKです。
飛行機からの電波を受信された場合、上記のOnlineと表記が変わると思います。
夜間等、飛行機がいない時間帯は筆者の家でも、No Data表記となります。

詳細な受信データも見れますので、改善計画を立てるにはよいかも知れません。
後ディスコーンアンテナなので、割と360度一部開けている方向が多いが、それ以外は
まるっと拾えているっぽい。さすがディスコーンアンテナと思った瞬間！

接続して環境にファイヤーウォールがいる場合

冒頭と同じですが、接続しているネットワークにファイヤーウォールがいる場合、
筆者の環境は物理ファイヤーウォールを設置している為、当初通信が阻害されてステータスが一向に変わらず
これ、ファイヤーウォールにブロックされていないか？を確認したところ、がっつりブロックされていた。
一般の方は、問題無いかも知れませんが、特殊環境の場合ご注意を！！
下記のように、Port：8099をあけてあげましょう。おそらくUDPで大丈夫だと思いますが
ファイヤーウォールでTCPをブロックしていたので、いったんTCP/UDPどちらも開けています。

process確認を行うなら

rurineko@ads-s:~ $ ps -ef | grep fr24feed | grep -v grep
fr24        2517       1  0 Aug17 ?        00:03:08 /usr/bin/fr24feed

上記コマンドを投げると、1件引っかかってくると思うので、Zabbixでprocess監視してもいいかと思います。

各サービス共に

Feedをおこなうことで、ビジネスアカウント・エンタープライズアカウントに昇格し
無料でフル機能を使うことが出来ます。

flightradarのビジネスアカウントは、下記の通りかなり高額です。
Feed環境を整えると無償化できるので、機材の金額や運用費はかかりますが
毎月毎月50ドル弱支給されていると思えば、全くマイナスではありません。

• $49.99/month
• $499.99/year

下記のサイトで、詳しく解説されているようです。
https://fr24.wporep.com/paid-plan

利便性向上の為

筆者は、外から自宅の環境にアクセス出来るように、DMZにNginxを配置して
内部アクセスはリバプロで、digest認証をかけてDNSにてドメインを付与して
各管理画面を外からアクセス出来る様にしています。
DMZからローカルIPで、各管理画面Port番号が違うので、フロントのNginxでリパプロで
そこを解消しつつ、SSL証明書を食わせて外部からSSL化している。
ただ、そこまでしなくても、下記にアクセスしログインした状態であれば
Feedにより、自宅で見れる画面と同じ状況で見れるので、そこまでする必要がなかったかなと思っています。
https://www.flightaware.com/skyaware

ただ、DNSで覚えやすいドメインを設定できるので、良いかなと思います。
そのくらいの利便性しかないですね。

次回本番環境構築準備

検証環境が構築できて、問題無く飛行機からの情報をゲット出来ており
さらに、flightradar24やflightAwareにFeedが問題無くできているところまで確認出来ているので
それらを運用しつつ、本番機を構築し検証機から本番機へと切り替えて行く。

必要部材

・raspberry Pi 4B
・PoE HAT基板
・防水ボックス（一部放熱加工が必要かも）
・アンテナ直下から部屋うちまでのLANケーブル（自作する）
・SDカード（本番用）ドラレコ用高耐久モデルを採用（検証機に使っている銘柄）
・フィルター＆ブースター（取付は行っておくが、接続せずバイパスしておく）

アンテナについて

・1090Mhzアンテナ（9dB高利徳の物110ｃｍ）

アマチュア無線無線の1200MHzのGPでも良いかも！13.7dB（1200MHz）5m
送信はしないから、SWRの問題も受信周波数も近接200MHｚ下くらいなので
問題と思われるが！どうでしょうね。利徳が1090MHzのアンテナで9dBなので
アマチュア無線1200MHzのアンテナで1090MHzを受信した場合、利徳が9dBを割っちゃうと
意味が無くなるんで・・・。下記がそのアマチュア無線のGPアンテナの共振周波数を示す
1260MHzでSWR2.0なので、ちょっと1090MHzまで行くとこの感じだとかなりSWR高そうで
いまいちマッチングが厳しそうな気配ですね。
1090MHｚのアンテナおとなしくかって、SWR計測してみて、それらがSWR5とか6とかなら
下記の1200MHｚのGPと交換しても問題無い気はします。

結論

とりあえず、1090Mhzのアンテナをチョイスして設置を行う。
こんな感じで、既にHFアンテナが単管に設置しているのでアンテナを若干下に下げて、
単管を伸ばして、その先に1090Mhzのアンテナを設置する。
下記の図が設置案である。受信機材は防水ボックス内にラズパイやSDRトングルを含めて設置し
Switchbotなどで管理出来る防水型の温湿度計を設置して、外部から内部温度の監視を行う。
場合により、ソーラー発電で日中は5V程度のFANを駆動出来る様に熱対策を講じる事も検討する。

割とちゃんと防水ボックス内の図を書くと下記の感じを想定。
SDRトングルには、M.2SSDのヒートシンクを取り付けて、発熱による水晶の誤差を低減させ
周波数分解比を安定させる作戦！

参考までに

現在、このアンテナでADB-Sを受信している。第一電波工業のD1300AMである。
このアンテナは、25MHz～1300MHz+中波（AMラジオ）を受信出来るアンテナである。
今回のADB-Sの1090MHzも受信範囲に含まれている。専用の物とどちらが遠方のADB-S信号を
受信できるか？検証も出来ると思います。

第2期

978MHzのADB-S信号も追加で受信できる用に、SDR受信機とアンテナを増設し
運用を行おうと思っています。これがほぼ完成形に近いかなと思います。

総括

それでは、今回夏の自由研究テーマとして、ADB－Sを取り上げましたが
いったんは、この検証環境で動作させておいて、本番はアンテナ工事やラズパイの調達等で
また、タイミングができたら、記事にしていこうと思います。
手持ちの機材ではここまでとなります。
ざっと、お盆休みを使って数日で構築してしまいましたが
かなり雑な扱いで構築しておりました。
とりま、きれいに設置して検証環境のままで運用し、本番環境が構築出来そうになったら
再始動いたします。次回もお楽しみにして頂ければと思います。

もし需要があるようなら、ラズパイとアンテナ・同軸ケーブル・SDRトングル・OSを書き込んだSDカードと
構築手順書、あとこの位なら構築用のシェル1本でざっくり構築できそうなので
それも含めて同梱して販売しても良いかも知れません。
需要があればですが　

gitから購入して頂いた方向けに、構築シェルをCloneしてもらって
そのままざっくり構築される感じを想定しました。ECサイトも持っているので
キットとしては、販売はすぐできるかな。物と需要があればですが。

それでは、また、本件何か動きがあり次第記事にしていきたいと思います。
写真後ろに、高いラジオ受信機と化しているDX10Mが鎮座してますね。

The post 本気でADS-B受信環境構築 第3回 #ADSB first appeared on ～下町物語～.

ブログの更新をするときに最近ホワイトアウトして何もできなくなるので、昨日ちょっと調べました。
Webserverであるnginxの書き出すログを見るも、若干エラーもあるものの該当事象にヒットしない。そこを修正しても、やはりホワイトアウトしてしまう。本当にいきなり出来なくなるので、まだ何やらクラックされたりしてたらいやだなぁと思いつつ調査を進める。

おそらく、あやしいのはモジュールだと当たりをつけて、モジュールを全部無効化してテストする。結果、全くホワイトアウトしない。やっぱりなぁ。って、その時点で１つ心あたりがあったんですが、徐々に有効化して絞り込んだ。

最後にそれを抜いて更新してみる。ホワイトアウトしない。やっぱりなぁ。ってことで、更新時にインスタグラムに自動で記事を共有しているモジュールがガンでした。更新時にインスタグラムに情報を送って自動投稿しているところで、インスタAPIの仕様が変わったりなんかして、正常に動かなく鳴ったのだと思います。

それにしても、あまりいいインスタグラムへの投稿モジュールが、今ないんですよね。有料ならあるんですが、無料のはほぼほぼないです。とはいえ、自動では無いけど、昨日別のモジュールを入れたのでもう大丈夫ですね。今日から改めて更新してインスタグラムにも投稿したいと思います。この記事も、この後インスタにアップします。

The post ブログの更新時にホワイトアウト first appeared on ～下町物語～.

Nginxパフォーマンスチューニング

たいした話ではないけど、nginxでphp-famを使ってPHPを処理させる構成は一般的ですが、時々下記の様なエラーが出る事がある。

readv() failed (104: Connection reset by peer) while reading upstream,

ちょっと数が多いわけじゃないけど、この辺りを発生しないようにパフォーマンスチューニングを施したいと思います。発生原因については、下記のホワイトボードの通り簡単な図を書いてみました。Visioとかでかけよって話もあるんだけど、ちょっと色々時間短縮の為、ごめんなさい汚い字でｗ

という事で、Nginxからphp-famの間が指定のDefault値待っても帰ってこない場合、Nginxさんは、タイムアウトとしていったんセッションを切ってしまうのです。その際どのような動きになるか？PHPで処理している画面はまっしろですね。そのサイトを見ている人とシステムの利用者様に取って見ると、あれ？出てこない！ってなるわけです。

要因について

処理を返せない要因は、色々あると思うのです。

1. PHPの複雑な処理によって時間がかかる（PHPコーディングの問題）
2. Access過多により応答を返せていない問題
3. ネットワークセッションに対する問題もあるかも（ただ、今回はNginxとphp-fpmはソケット通信）
4. CPU性能やメモリー不足でSwapなどしている様なスペックの問題
5. DB肥大化によって、query処理に時間がかかっている問題
6. そもそもworkerプロセス数の不足

今回発生した状況を考えて見ると、DBからAccessログを引っ張ってきて、再集計してグラフを書く処理を流したのですが、Accessログの肥大化によりquery処理に時間がかかって、Default値の10秒を超えてしまった為発生した模様です。

対応方針

とりあえず、処理に時間がかかる場合発生しているので、該当のセッションを維持出来る時間を延ばす方向。

設定変更(CentOS7 + Nginx + Php-fpm)

vi /etc/php-fpm.d/www.conf

○下記文字列を検索、Default値はコメントアウトされているが、おそらく10秒がDefault値で設定されている
　;pm.process_idle_timeout = 10s;
　pm.process_idle_timeout = 30s;　　このように修正する

○php.iniの修正
　vi /etc/php.ini
  max_execution_time = 30
  max_execution_time = 60　このように修正する

○php-fpmを再起動する
　systemctl restart php-fpm

動作確認して問題無い事を確認する。

The post ngixn パフォーマンスチューニング first appeared on ～下町物語～.

ブログサーバが、朝４時00分頃からhttp/httpsともにZabbixエージェントも含めてダウンして、リスタートを検知しました。

何かあったのあなか？難しいですね。後でサポートのページ見てみようかな。例のメルトダウン系のパッチ当てたのかもしれませんね。

とりあえず、復帰したことはZabbixで検知しており、さっき目視でも確認しました。こういう時に自動起動入れてないと、全然サービス断になっちゃいますねぇ。気をつけて起きたい設定ポイントですね。

The post 朝４時頃メンテナンス発生？ first appeared on ～下町物語～.

最近、ストリーミングサーバを再構築し始めたのですが、１つの選択肢としてowncloudを入れましたが、５００ＧＢを超えてくるとどうも、もろもろ管理できないようですね。

ストリーミングサーバとしての使用を考えているので、データが増えると、オーバーフローするようでは使えないですね。リソース的に問題なのか？製品の限界なのか？微妙にわからないですが、とりあえず、外部からデータをputした場合、oocコマンドを発行するのですが、そちらもエラーを吐きますし。

結局、subsonic意外選択肢がありません。とりあえず、apacheを止めてnginxでリバプロでしようかなと思ってます。SSLの都合があって、javaにSSL証明書食わせるのもちょっとめんどくさいのと、オートメーション化したいですが、そこができないことは無いかもですが、めんどくさいのでとりま、nginxで何とかしようと思います。

ほぼ、７０％程度設定は終わりました。ただ、今回は自宅意外から使えない仕様にして、外から聞きたければvpnはって聞く感じにしたいと思います。

今日データ整合性が合うと思いますので、後はラジオ録音サーバからｓｃｐする設定をして自動格納する感じにしたら、ほぼ終わりですね。

The post owncloudため込める最大容量 first appeared on ～下町物語～.

まじかよ！！

昨日CentOSのOSアップデートしたら、勢いよくZabbixがBAD requestを返すようになったぜorg

簡単な内部構成図

Zは、Zabbix　Aは、Apache　NXは、Nginx　RPは、ReverseProxy　Jは、Jenkins

数字は、内部はそのPortで通信させて、NginxでReverseProxyでFront側を制御している。そして、ドメインベースのSSL証明書を入れてFront側は完全にSSLで４４３通信させている。

何はともあれ調査

yum logを確認して何がアップデートがかかったかを確認する。その上でZabbixログ確認とsyslogみたり、MariaDBプロセスが上がっているとか、DBにログインしたりして状況を把握する。

状況

今回ログからMariaDBがアップデートされていることは確認したので、今度はプロセスが上がっているかを確認したら、問題無くprocessはあがっていてDBにログインも出来たので、DB自体が壊れた訳ではなさそうです。ただ、ログを見る限りどうも、MariaDBとZabbixが同時にアップデートされた模様。

Zabbixログを確認すると、Zabbixパッケージのアップデートが終わって、DBをアップデートしてる最中に構造が壊れてそこで止まってるようだ。DBにログインしてみるとテーブルが激しく破損している。

原因

状況証拠をもとに考えると、yum updateでZabbixがアップデートしてauto起動でreloadしてDBテーブルをアップデートしてる最中に、MariaDBアップデートは走りアップデート途中でMariaDBプロセスがダウンしたため、もはや動作環境としては破損した状況に陥った。

復旧

もう、とっとと復旧しましょう。今Zabbixが動いてるサーバは１日１回スナップショットをOSまるってとっているので、スナップショットからインスタンスを作成する。

スナップショットを取った時は、もちろん破損してないので何も無く起動してくる。そこからDBdumpを作成し、そのデータをローカル経由で今回壊れたサーバの/tmp位において、DBdumpをインポートする。

DBdump : mysqldump –single-transaction -u zabbix -p qqqqaaaavvv > /tmp/zabbix.db.sql

DBDump import : mysql -u zabbix -p qqqqaaaavvv < /tmp/zabbix.db.sql

その上でZabbixを起動してやると、DBアップデートが走るので正常に完了で動き出す。しかし、まだBADrequestを返す。

こちらで使っているZabbixは、内部を別ポートでフロントをnginxでリバプロ接続している。フロント側が443で通信している関係で、apacheアップデートしたときに、何故かSSLで起動して来て既にnginxが443を掴んでいたので、apacheが上がらずBADrequestを返していたようです。ssl.confをリネームして再起動して問題なく画面出るようになりました。

教訓

yum updateでリストをみて、ZabbixとMariaDBがアップデートが重なる時は、一端Zabbixを除外してアップデートしてから、後でZabbixをアップデートするようにしよう。もしくは、Zabbixを落としてからアップデートを行うと共にアップデート前に、DBdumpをとっておこう。OSごとスナップショットを取って復旧できるようにしておこう。

やれやれ　２時間位かかりましたｗ疲れますね。

The post OSアップデートしたら壊れたZabbix first appeared on ～下町物語～.

Nginx Port:80 unserviceted Oh!No 。。。。

２０１７年１１月１８日にこのサイトのサーバは、ある改修を行った。それは、少しでも高速にこのブログを読んで頂けれる様に設定を施したつもりが・・・。そう、覚えている方もいるだろうか？そう、HTTP/2.0の対応を行った時のことでした。そこで、なんと８０番Portのサービスの設定を漏らしてしまったようで、かなりの数アクセスを拒否してしまったようだ。残念すぎますね。

今日Zabbixのグラフをみてて、http側４００番を返している。むむって感じで気がついた。

昼休みVPNつないで、速攻修正しました。ここから年末にかけて回復させて行ければと思います。がっつりアクセスグラフが減ったのは、そういう事だったんですね。いやはや、残念すぎますね。がんばろぉ。上記グラフが若干回復してきましたねぇ。これで、後は今まで通りばんばんやっていきますよ。

The post しまったぁ！８０番Port first appeared on ～下町物語～.

今は、3コア・メモリー1GBですからね。認識メモリーは2GBなんですが、保証値は1GBで残りの1GBはシェヤードなので、他の仮想serverが一時的にメモリーを食べると、他の仮想serverが引っ張られます。そういう時に、常時1GB以上食っているserverだと、いきなりスワップ枠に逃がされて処理されます。そこから、性能劣化が始まります。storageはSSDなのでマグネットディスクよりは、そこそこ早く出てきますが、とはいえもっさり感は拭えないです。とりあえず、色々な値をいじってちょっとギリギリまでチューニングしてみますか。その他で言うならZabbixエージェントが入っているので、そいつが食っている可能性もありますね。たまにzabbixエージェントがメモリーリークを起こして、大規模にメモリー不足を発生させている時がありますから。いずれにしても一度ちゃんとやらないとなぁと思いつつ、現在チューニングしていったんserverを再起動してリソースを確認している最中です。

uptimeがいったんリセットになりましたｗ

メモリーでいうと、1.5GB程度が割り当たっている感じですね。

今日時点としては、ちょっと様子見ですかね。昨日は普通に499返しまくってましたが、とりあえず今の所php-fpmもエラーを出していないようなので、まあこれでちょっと様子をみていければと思います。とりあえず、今までapacheでやっている時は、全くその辺り苦労した事がないので、nginxとphp-fpmにしてからやたらとシビアな状況を要求されますねぇ。まあ、これはこういう物でしょうかね。少し前に負荷テストしながら大分チューニングしたんですけどねぇ。まだまだ、甘かったって事ですねぇ。がんばらないとですね。

The post ブログserverチューニングが必須 first appeared on ～下町物語～.