ランダムな英字トラックバックスパムをブロックする方法
ブロック方法は主に2つ。1つめはトラックバック用のアドレスを取得するサーバをブロックする方法、もう1つはPOSTに含まれている特徴的なUserAgentをブロックすることです。 今回取り上げるトラックバックスパムは通常のものと違い、リンク先のドメインが存在しません。つまり宣伝目的ではなく、愉快犯かあるいは技術的なスパムの実験ではないかと思われます。例えば、 トラックバック送信元サイト名:myigkqve トラックバック送信元記事名:wwoplazmy トラックバック送信元アドレス:http://www.hlribogxe.com と、以上のような感じで送られてきます。 アドレスなどの文字列はランダムな英字の組み合わせになっているのが特徴で、送信元のIPアドレスは毎回違う海外の匿名プロキシを経由してきます。しかもご丁寧なことに世界中の様々な匿名プロキシサーバリストにまだ載っていないようなもの
GIGAZINE最大の挑戦、LoadAverage「86」から「3」へ
というわけで、再び負荷を下げる方法を模索した、戦いの記録。 1.MySQLの設定を変更して高速化 2.Zend Optimizer 3の導入 3.ionCube PHP Acceleratorの導入 4.テンプレートの見直しでクエリーを減らす 5.robots.txtでクロールする間隔を制御する 6.MySQLの設定を負荷を低くする設定に変更 7.キャッシュを有効化する 前回解説した「GIGAZINEのLoadAverageを「27」から「2」へ下げた方法」から約3週間後、6月20日（火）の夜、気がつくと負荷の15分平均は「25」をコンスタントに吐き出すようになり、さらに訪問者は急増、ついに6月28日（水）12時45分、負荷対策の効果がほとんど出ないまま、LoadAverage15分平均は「86」に…。 何か対策が根本的に間違っているのだろうか？それとも、もうGIGAZINEサーバのハード
GIGAZINE - GIGAZINEのLoadAvarageを「27」から「2」へ下げた方法
ここ3日間ぐらい超絶な重さだったのはサーバに物理的トラブルが発生したからではなく、単純に閲覧者数が満員御礼となり、各時間で倍増したためです。LoadAverageはひどいときで15分間の平均値「27.1」程度。瞬間最大風速だともっと高いです……明らかにまずい。 というわけで、Apacheのデフォルト設定で今までは大丈夫だったのですが、ついに高負荷サイト用の設定に変更せざるを得なくなりました。 そのため、実際に行った対処方法は以下の通り。1日30万PV近い動的サイトの高負荷を緩和させる方法として参考になれば幸いです。 まず大前提として、既にDNS逆引きや.htaccessの余計な読み込みなどは停止させていました。下記ページに書いてあることは実行済み。 ＠IT：Apacheパフォーマンス・チューニングの実践（1/2） この状態で負荷が15分平均で「27」になっていたわけです。 また、LoadA
Linuxサーバのボトルネックを見つける方法
これで見るとやはり専用サーバで正解だったようです。今の2倍程度のアクセスが来てもなんとか耐えられそうです。想像以上にCPUリソースなどもろもろを消費してはいるが、許容範囲内。 サーバやPCのボトルネック箇所の簡単な見分け方(Linux編) : ITpro Watcher http://itpro.nikkeibp.co.jp/article/Watcher/20060404/234528/ 非常にわかりやすく、SSHでログインしてとりあえずコマンドぺちぺち打って、結果を見れば大雑把に理解できるようになりました。わかるのは以下の項目。 1. CPU使用率 2. メモリ使用量 3. ディスクI/O 4. TCPコネクション数 とりあえずGIGAZINEもピークの時間帯で計測してみて、今後のさらなるアクセス増に備えたいと思います。
GIGAZINEが4月18日夕方から新サーバに移転します
上の画像は新しくGIGAZINEを支えるIBMのサーバです。今はもう既に新しいシステムに組み込まれ、ごぅんごぅんとうなりをあげてフル稼働しており、デビューの時を今や遅しと待ちわびています。 というわけで、本当は3月末から4月初めにかけて移転する予定だったのですが、次々といろいろな事態（うれしいことから悲しいことまで）が発生し、今日までずれ込むことになりました。とりあえず、「GIGAZINE、ついに新サーバへ移転完了」という記事が見えたら、それが新サーバです。何か不具合を発見した方はこちらから具体的な内容をできるだけ詳細に連絡していただけると非常に助かります。 今回は何がどう変わったのかという点については以下の通り。主にサーバやハードウェア、新サーバ開始に至るまでの裏話などに興味のある人向けです。 ■新サーバの構成 IBM System x3200/Quad Core Intel Xeon
GIGAZINE、ついに新サーバへ移転完了
というわけで、ここが新サーバ群による新生GIGAZINE.NETです。この記事が見えているということは、新しいサーバへのDNS浸透が済んだということです。見た目上は特に何かの変化があるわけではないのですが、サーバが物理的にトラブルを起こさない限りは重くなったりはしない……はず。 というわけで、前回の記事に引き続き、裏話第2弾です。詳細は以下から。 ・MySQLのDNSルックアップを無効化 新サーバ構成でテスト中に最大の問題となったのがコレ。ルータが落ちまくるので一体何が起きているのかがわからず、延々と1週間も悩み続け、GIGAZINE編集部を恐怖のどん底にたたき込んだものです。結論から言うと、外部のDNSサーバを利用していたため、ローカルでのテスト環境においてもMySQLに接続が発生するごとに、DNSの参照が発生していたのが原因。 MySQL :: MySQL 4.1 リファレンスマニュア
GIGAZINEが新サーバに移転完了しました
というわけで、ここが新サーバです。これで平日昼間の発狂したかのような重さが改善されればよいのですが……。次の段階は複数台による負荷分散ですね。 というわけで、やたら重い状況を多少改善してくれた各種設定などは以下から。 あまりにもスロークエリが発生するのでこれを軽減できないかと思い、下記のページを読んでみました。 【MySQLウォッチ】第14回 サーバー設定を見直してMySQLの性能を引き出す：ITpro [ThinkIT] 第4回：ベンチマークツールを使った負荷テスト (2/3) テーブルキャッシュ（table_cache）とスレッドキャッシュ（thread_cache）を設定したところ、飛躍的に負荷が軽くなりました。朝の9時から夜中の0時までひっきりなしに発生し続けていたスロークエリが、アクセスの集中する正午頃以外はほとんどなくなりました。キャッシュってのはうまく使えば非常にお役立ちです
GIGAZINE、新サーバに移転完了 - GIGAZINE
というわけで、ついに新サーバに移転完了しました。これで負荷が軽減される……はず。予想される負荷に対応するため、カウント数は必要最小限のもののみにとどめました。そのほかにもデータベースの構造を一新しました。これに伴い、トラックバックなどは全リセットされてます、すいません……。 何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向け記事第2弾。今度は最も難航したMySQLの設定です。 ◆MySQL メモリをたくさん使えば使うほど高速にレスポンスは返ってくることになるが、GIGAZINEのようにMySQLの中に記事本文しか入っていない場合、つまり非常にコンパクトな場合はメモリをたくさん使ったからと言って反応速度が劇的にアップするわけではない。むしろメモリを極限まで
GIGAZINEが20日（土）から21日（日）にかけて新サーバに移転します
サーバのカスタマイズで乗り切る限界を突破してしまったため、GIGAZINEは今から新サーバに移転します。新サーバ移転後、何か不具合などがある場合には臨時用のこちらのメールフォームからご連絡いただければ助かります。 というわけで以下、旧サーバと新サーバの設定などについて。サーバのカスタマイズに興味のある人向けです。 まず旧サーバは「Dell PowerEdge 850」を利用しており、以下のようなスペックです。よくありがちな構成。 ◆旧GIGAZINE.NETサーバ CPU：Intel PentiumD 930 HDD：73GB(SCSI RAID1) メモリ：2GB ネットワーク：2Mbps OS：Red Hat Enterprise Linux ES3 これが以下のようなスペックの「NEC Express5800 120GR-1c」になります。これもありがちな構成。 ◆新GIGAZINE
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
